[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