[Nsi-wg] Addressing connections across requesters
Henrik Thostrup Jensen
htj at nordu.net
Thu Aug 23 08:20:54 EDT 2012
On Thu, 23 Aug 2012, John MacAuley wrote:
> Wiki UUID. Is discusses the algorithm's ability to generate uniqueness.
But, there is a perfectly good RFC that I've already read :-).
> Chances of a clash are worse than being hit by a meteorite.
Did you read the note about trying to consider it as a format :-).
> Of course, someone with malicious intent could continue to send the same
> identifier over and over again, but you should be checking if it already
> exists anyways. Today I will reject a reservation request with and
> identifier already in use. I guess the question then is, do we feel
> that letting someone know a connection ID already exists is a security
> breach?
Right. And you actually have to perform this check for requests than
cannot be fulfilled due to other matters (well you can try and guest the
least cpu intensive check order). Having the provider assign the
connection id also means that only connections which are created actually
get one. Thought I'm not sure we have actually discussed if an NSA should
keep information about failed reservation requests.
Anyway, we are three in favor with B. Can we do this? It would mean
removing the connection id from the reservation request, and a slight
behavioural change. Should be easy, though you may get into some schema
juggling with the wsdl. Since it is the provider assigning the connection
ids, we could also go away with the uuid requirement (though
implementations are perfectly free to use it).
Of course, we could also make a huge slide set, and spend several hours
discussing it on the phone :-).
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet
More information about the nsi-wg
mailing list