Addressing connections across requesters
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
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
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
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
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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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
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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi John On Fri, 24 Aug 2012, John MacAuley wrote:
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.
Yes, that is the main problem. However with solution A, we get into the issue that if a requester chooses the id, it does not know if the connection id is actually available (of course this can be reduced to a probability of essentially 0 - as long as everybody plays nice).
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?
I think this is good (I'm still not a fan of the RPC callback), but for what we have I think this is good. Do we still need to have these as UUIDs? I am not against UUIDs, but I still do not see the point of forcing them at protocol level. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Just to be clear in my head: 1. In the ACK to the reservation request the Provider NSA will return the reservation ID it has associated with the new reservation. 2. The reservation confirm will still return the result of the reservation. 3. I will relax all requirements around UUID for those who hate to conform ;-) Sound correct? John. ----- Original Message -----
From: "Henrik Thostrup Jensen" <htj@nordu.net> To: "NSI Working Group" <nsi-wg@ogf.org> Sent: Wednesday, August 29, 2012 10:36:15 AM Subject: Re: [Nsi-wg] Addressing connections across requesters
Hi John
On Fri, 24 Aug 2012, John MacAuley wrote:
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.
Yes, that is the main problem. However with solution A, we get into the issue that if a requester chooses the id, it does not know if the connection id is actually available (of course this can be reduced to a probability of essentially 0 - as long as everybody plays nice).
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?
I think this is good (I'm still not a fan of the RPC callback), but for what we have I think this is good.
Do we still need to have these as UUIDs? I am not against UUIDs, but I still do not see the point of forcing them at protocol level.
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
On Wed, 29 Aug 2012, John MacAuley wrote:
Just to be clear in my head:
1. In the ACK to the reservation request the Provider NSA will return the reservation ID it has associated with the new reservation.
Yes.
2. The reservation confirm will still return the result of the reservation.
Aye.
3. I will relax all requirements around UUID for those who hate to conform ;-)
:-)
Sound correct?
Yes. The fear of lost reservation references still nags me a bit, but running it through my head, I realised that unless we switch to a conscenceus-based approach for creating connection (which we should not) that will always be able to happen. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Global ID is currently optional, and is specified by the client, so it cannot be used for anything in this.
Why cannot Global ID be used? If people want monitoring, they can make it mandatory to populate that . In fact we wanted to make this non-optional and mandatory. Inder
On Wed, 22 Aug 2012, Inder Monga wrote:
Why cannot Global ID be used? If people want monitoring, they can make it mandatory to populate that . In fact we wanted to make this non-optional and mandatory.
Still would not work. In fact that would just make the situation the same is it presently is for global id. I still have not understood why a client needs to specify two identifiers for a connection (i know global id is supposed to be the same across segments, but the question still holds). PS. Is there a difference between non-optional and mandatory? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi all- Just a point of reference: Prior protocols addressed this by having each agent (the user and network) assign their own ID as part of the request signalling. Thus you always had unique ids because they only needed to be unique for the agent creating them. The other agent in the protocol would simply assign a mapping from their unique ID to the neighbor's unique ID. Since an agent always new who it was speaking to, it would also know which id to use when speaking to that agent. So essentially this amounts to a two level ID a globally uniq part (the NSA ID) and a localy unique part. These can be munged together, or kept as two separate data elements in a compound object. This sounds a bit convoluted, but it is really quite simple and solves the problems of maliciously chosen duplicate IDs, and allows third party agents to reference the ID without confusion. To use this method, the RA assigns a locally (RA) unique ID and send the reservation request to the PA, who will assign a local (PA) unique ID to the connection and return that with the reservation response. As long as the formal connection ID includes the NSA ID and the local part, you know deterministically that the CID is globally unique and that it won't conflict at any NSA. Jerry On 8/22/12 4:42 PM, Inder Monga wrote:
Global ID is currently optional, and is specified by the client, so it cannot be used for anything in this.
Why cannot Global ID be used? If people want monitoring, they can make it mandatory to populate that . In fact we wanted to make this non-optional and mandatory.
Inder
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (5)
-
Henrik Thostrup Jensen -
Inder Monga -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley