[Nsi-wg] Addressing connections across requesters

John MacAuley john.macauley at surfnet.nl
Fri Aug 24 09:13:34 EDT 2012


The only issue we have is that the RA will not know the connection ID so will not be able the query the reservation in its "reserving" state, or to see if it missed a confirmation message.

Perhaps, and I am just throwing it out there, we might consider reworking the ACK to the reserve.rq to return the allocated connection Id?  Maybe a new mechanism?

Thanks,
John

On 2012-08-23, at 8:20 AM, Henrik Thostrup Jensen wrote:

> 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
> 
> _______________________________________________
> 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