[Nsi-wg] Addressing connections across requesters

John MacAuley john.macauley at surfnet.nl
Thu Aug 23 07:53:05 EDT 2012


Wiki UUID.  Is discusses the algorithm's ability to generate uniqueness.  Chances of a clash are worse than being hit by a meteorite.  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?

Thank you,
John

Thumb typed on my iPad.

On 2012-08-23, at 4:25 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:

> On Wed, 22 Aug 2012, John MacAuley wrote:
> 
>> LOL - I argued endlessly about this and gave up.
>> 
>> I would rather have the provider return the new connectionId
> 
> So, 3 for solution B :-).
> 
>> So how does the UUID not work?  You just need it to. E unique within the provider NSA to solve your problem do you not?
> 
> If you let the client generate the connection id, you have two choices:
> 
> 1. Scope the connection id within the identity of requester nsa
> 
> This guaranties that the connection id is not taken, assuming the client have not specified the connection id before (something might have gone wrong and it tried to reserve again). This is what we have today. Unfortunately referencing to connections created by other NSAs are rather tricky / messy.
> 
> 2. Let the client use its specified connections id if it is not taken (solution A).
> 
> In theory, UUIDs should work here assuming everything uses them correctly. However as we have a protocol, I just see the UUID as a format, and not as a way of generating non-clashing identifiers. There are some slighly tricky problems concerning if it is allowed to reuse connection ids for re-reservation with this, but nothing major.
> 
> 
>    Best regards, Henrik
> 
> Henrik Thostrup Jensen <htj at nordu.net>
> Software Developer, NORDUnet
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg


More information about the nsi-wg mailing list