LOL - I argued endlessly about this and gave up. I would rather have the provider return the new connectionId 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? Sent from my iPhone On 2012-08-22, at 9:10 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
I've been trying to address this for some time as well, ever since I started monitoring requests and came up against this problem :).
Since GLIF already has a best practice stating that the source network of a connection request gets to define the global identifier of that connection, I would vote for B.
Jeroen.
On 22 Aug 2012, at 12:32, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
I was trying do add authorization support to OpenNSA, but came up short on a lot of rather simple things involving third party. I've raised some of these issues before, but we never really get around to doing actually solving them.
Description of the problem:
Currently the connection id is specified by the requester, meaning that is has to be scoped within the requester identity, as there is no way to ensure that client chooses a unique one (no UUIDs does not solve this problem as it only covers accidental clashes, not malicious).
This means that if A creates a connection at B. There is no way for a third party (C), to address the connection at B. I think this is a problem.
Global ID is currently optional, and is specified by the client, so it cannot be used for anything in this.
Possible solutions:
A: Letting connection id to be scoped within the provider.
This means rejecting requests which has an already specified connection id. This is fairly straighforward and simple, and is unlikely to cause havoc in the real world.
B: Letting the provider choose the connection id
The connection id would then have to be returned in the response. This is very simple, but somewhat opposite of what we have done so far. This has problems with crashes/message loss (the requester does not know the connection id until it gets the reply). This can be worked around though.
C: Including the requesterNSA in the connection.
The essentially means that a connection is specified with identity of the requesterNSA and the connection id, maning that a connection id, cannot identify a connection :-).
B is actually my favorite, but I can certainly live with A, and that is probably the easiest to implement. I dislike C due to the complex adressing. A & B means that the address of a connection will be providerNSA + connection id. For C, the address becomes providerNSA + requesterNSA (creator) + connection id.
Someone might have assumed one of these as a solution (especially A), but AFAIK we have never really decided on anything here.
Observations:
The requsterNSA and providerNSA fields seems completely superflorouros (at message level, NSA identity is necessary in topology (I think), but at message level it just seems silly. An NSA identity and endpoint is also more or less the same to me, but this might be HTTP braindamage :-).
In fact, it just confuses things. I can count at least three ways to identity an NSA:
1. Their NSA identity (requesterNSA / providerNSA). 2. Their endpoint. 3. Their security identity.
2 and 3 are pretty much neeeded, but I am not so sure about 1.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg