Security and Exchanges
Hi (part two of the security and pathfinding) We are currently treating exchange points like switches (which is not really that weird, as that is what they are). Specifically, we are treating them as an independent domain, which does not reflect that the ports on exchange is leased by the connecting network, and hence be under control of the NSA of that network. Allowing a third party NSA to create circuits on an exchange to another networks port violoates the simple principle that an NSA should be in charge of the networks resources. This means that a network can no longer decicde how it wants to allocate its resources, which is pretty bad. There are some potential solutions to this like allocating a static vlan range to a certain network-network combination, but it is inefficient resource-wise. Requiring a token is another possiblity, but adds much complexity, as the token must be aquired apriori. As there is no standard mechanism in place for acquiring these, it would often end up being a long-lived token with wide permissions, which is less than ideal security-wise. The following presents a scheme that keeps the port under control by their respective NSA, doesn't require any static pre-allocation, and does not require any out-of-band token distribution. It can be seen as a standard mechanism for acquiring a token for setup. It does change the path setup flow somewhat, and requires special behavior for the exchange NSA, and the pathfinders using it. Finally it requires a control-level peering between the two NSAs responsible for the networks connecting to the exchange. We have the following scenario: Two networks: A & B One exchange: X The networks connect to the exchange on port X.A and X.B. NSA for network A, wants to setup a circuit from A to B over the exchange. The NSA for the exchange knows the identities of the NSAs for Network A & B, but will only allow them to allocate resource on their port. Having an exchange NSA operate in this manner is essential, as networks should only be able to allocate resources on their own ports (I don't consider the exchange backplane to be an issue here, usally congestion happens on the links). The circuit is setup on the following way: NSA for Network A, requests a circuit on the exchange from port X.A to a logical/virtual STP, named X.IC (for interconnect) in this example. The NSA for X recognizes that NSA A has the right to allocate resouces on port X.A, and grants the request. The STP returned for X.IC, is not X.IC, but instead X.A with a label (or token) on it. This label is randomly generated, and cannot be guessed (it could be a UUID, but it doesn't matter). Hereafter NSA A, makes a request to NSA B, with the newly created STP (with token), to create a circuit (could be tree or chain, doesn't matter), lets say it connect to B.P. NSA B will split this request up into two requests: One to NSA X for X.A to X.B (using the token, NSA X allow using X.A, and the NSA B is allowed to use X.B), and an internal link from X.B to B.P. When both requests have completed, a reply is send to NSA A. A perhaps more comprehensible version of the example: 1: Request from NSA A to NSA X: Reserve: X.A -> X.IC Response: X.A -> X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 2. Reserve from NSA A to NSA B: Reserve: X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 -> B.P 2A: Request from NSA B to NSA X: Reserve: X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 -> X.B Response: X.A - X.B 2B: NSA B Interal Reserve: Reserve: X.B -> X.P Response: X.B -> X.P Response: X.A -> B.P Using this schema we avoid the situation where third party NSAs can allocate resource on networks without going through the NSA of the network. For the scheme to work, NSAs operating exchange points need to change the behavior of what they allow and how links are set up. Furthermore, they need to advertise this behaviour through their discovery service. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Comments in-line. On 2014-12-10, at 5:18 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
(part two of the security and pathfinding)
We are currently treating exchange points like switches (which is not really that weird, as that is what they are).
They are actually a really big blocking cross-connect matrix :-)
Specifically, we are treating them as an independent domain, which does not reflect that the ports on exchange is leased by the connecting network, and hence be under control of the NSA of that network.
So you are saying that a port in an exchange point is not owned by the exchange point, but the network on the far end of the port? This reminds me of the never ending "who owns the link" discussion between John V and Jerry back when I first start working on NSI. Every time I remember that conversation I think of the classic 1977 movie "Slap Shot" and this scene: https://www.youtube.com/watch?v=x5Xp9hvTvPk The argument was that each link (SDP) was owned by a single network, even though it interconnected two networks. If we believe this is true, and it sounds like you have a good example of where it is, then we need to consider this in our NML modelling which we do not at the moment. Did we start this discussion in Uppsala which ended up with us needing people to describe their policies?
Allowing a third party NSA to create circuits on an exchange to another networks port violoates the simple principle that an NSA should be in charge of the networks resources.
I think we need to clarify this statement. The uPA is always permitted to reject any request it receives so is in total control of its own resources. All NSA are are third-party NSA to the uPA, even a directly connected peer NSA, so I am not sure if you mean non-peer NSA.
This means that a network can no longer decicde how it wants to allocate its resources, which is pretty bad. There are some potential solutions to this like allocating a static vlan range to a certain network-network combination, but it is inefficient resource-wise.
How does this exchange point decide to connect two ports together if each is owned by a different network? Is this a phone call to each network operator asking if it is okay to make the connection?
Requiring a token is another possiblity, but adds much complexity, as the token must be aquired apriori. As there is no standard mechanism in place for acquiring these, it would often end up being a long-lived token with wide permissions, which is less than ideal security-wise.
There are a number of standard access control solutions for authorizing access to resources, including protocols for acquiring said permissions (tokens, authorization certificates, etc.). The problem is we need to understand the types of policies that will need to be enforced so we can determine an kind of solution. I remember the discussion in Uppsala where someone had a policy decision based on a transit network three times removed from the current network.
The following presents a scheme that keeps the port under control by their respective NSA, doesn't require any static pre-allocation, and does not require any out-of-band token distribution. It can be seen as a standard mechanism for acquiring a token for setup. It does change the path setup flow somewhat, and requires special behavior for the exchange NSA, and the pathfinders using it. Finally it requires a control-level peering between the two NSAs responsible for the networks connecting to the exchange.
We have the following scenario:
Two networks: A & B One exchange: X
The networks connect to the exchange on port X.A and X.B.
NSA for network A, wants to setup a circuit from A to B over the exchange.
The NSA for the exchange knows the identities of the NSAs for Network A & B, but will only allow them to allocate resource on their port. Having an exchange NSA operate in this manner is essential, as networks should only be able to allocate resources on their own ports (I don't consider the exchange backplane to be an issue here, usally congestion happens on the links).
The circuit is setup on the following way:
NSA for Network A, requests a circuit on the exchange from port X.A to a logical/virtual STP, named X.IC (for interconnect) in this example. The NSA for X recognizes that NSA A has the right to allocate resouces on port X.A, and grants the request. The STP returned for X.IC, is not X.IC, but instead X.A with a label (or token) on it. This label is randomly generated, and cannot be guessed (it could be a UUID, but it doesn't matter).
Hereafter NSA A, makes a request to NSA B, with the newly created STP (with token), to create a circuit (could be tree or chain, doesn't matter), lets say it connect to B.P. NSA B will split this request up into two requests: One to NSA X for X.A to X.B (using the token, NSA X allow using X.A, and the NSA B is allowed to use X.B), and an internal link from X.B to B.P. When both requests have completed, a reply is send to NSA A.
OMG - this is exactly like the Network Element "Gun rack" I designed and applied for a patent on back in the days of the Pacific Bell purchase by SBC. I love it. Now that I see it I realized we had the exact same problem in Optical back in the good old Nortel days. Pacific Bell had a ton of four fibre BLSR rings and 1:n systems deployed in California but CO space was extremely limited, and like all RBOCs they were also extremely cheap. As a cost cutting measure they started sharing single Network Elements with their peering partners instead of back-to-back configurations. They had been manually doing all the cross-connects on these shared Network Elements for years, but finally wanted to be able to automate the procedure through their ordering and provisioning system (Telcordia's OSS). The problem was that each of the two OSS instances had to approve the cross-connect before the time-slots where interconnected, and it had to be through the NE the exact same way a cross-connect was created or they have to pay Telcorida millions of dollars to modify their OSS. In face-to-face meetings in Texas we gather the detailed requirements and proposed "The Gun Rack" (everyone in Texas has a pickup truck with a gun rack in the back so we felt it appropriate). The whole idea was one peer would create a virtual cross-connect using their real port (rate + timeslots) as the source and a virtual port (or slot in the gun rack) as the destination. They would also specify as part of the connection who could complete the connection as an access control mechanism to avoid unwanted mis-connections. The NE would see the destination was a virtual port and hold off making the cross-connect until such a point in time as the second segment arrived. The second peer would then specify their cross connect using their real port (rate + timeslots) as the source and the virtual port supplied by the other peer as the destination. The NE would see the destination was a virtual port already in the gun rack, verify the requesting user had permission to complete the connection,, take it out of the gun rack, and complete the real NE cross-connect. This resulted in a complete physical separation of ports on the Network Element, but all common facilities (including switching matrix) were still shared. Good walk down memory lane…
A perhaps more comprehensible version of the example:
1: Request from NSA A to NSA X: Reserve: X.A -> X.IC Response: X.A -> X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43
2. Reserve from NSA A to NSA B: Reserve: X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 -> B.P
2A: Request from NSA B to NSA X: Reserve: X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 -> X.B Response: X.A - X.B
2B: NSA B Interal Reserve: Reserve: X.B -> X.P Response: X.B -> X.P
Response: X.A -> B.P
So the assumption here is that NSA X has port A and port B defined with a special policy indicating that the special two step reservation must be performed? Also, NSA A talks directly to NSA B in step 2?
Using this schema we avoid the situation where third party NSAs can allocate resource on networks without going through the NSA of the network.
For the scheme to work, NSAs operating exchange points need to change the behavior of what they allow and how links are set up. Furthermore, they need to advertise this behaviour through their discovery service.
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
Hey On Wed, 10 Dec 2014, John MacAuley wrote:
Specifically, we are treating them as an independent domain, which does not reflect that the ports on exchange is leased by the connecting network, and hence be under control of the NSA of that network.
So you are saying that a port in an exchange point is not owned by the exchange point, but the network on the far end of the port?
Well, I reckon the exchange owns the port/switch, but it is leased to the network, so it is (or should be) theirs to administrate.
The argument was that each link (SDP) was owned by a single network, even though it interconnected two networks.
There are lot of options here: Links can be owned by a single entity and connect the network internally (these are faily easy). Links can be owner by a single entity but connect to another network in one end (typical for customer connects). Links can be co-owned (e.g. the ANA links), and have various policies for them. E.g. a static allocation for each network, and a best effort queue on top of those. AFAIK Cross-connects in data centers are often shared cost-wise, but can of course also be payed by a single entity (there are places where we would happily pay for a cross-connect if the other network would peer with us). Add link AUPs on top of all that.
If we believe this is true, and it sounds like you have a good example of where it is, then we need to consider this in our NML modelling which we do not at the moment.
NML more or less left policy as an exercise for the user. The domain/node-first approach makes policies very difficult to model in it.
Did we start this discussion in Uppsala which ended up with us needing people to describe their policies?
I have already described most of ours in my presentation at Uppsala. I think one of the issues is that most NRENs don't have very complex policies, so it has limited attention.
Allowing a third party NSA to create circuits on an exchange to another networks port violoates the simple principle that an NSA should be in charge of the networks resources.
I think we need to clarify this statement. The uPA is always permitted to reject any request it receives so is in total control of its own resources.
The point here, is that another NSA is controlling its resources. When you lease a port on an exchange your NSA should control it. That is not the situation we have today.
How does this exchange point decide to connect two ports together if each is owned by a different network? Is this a phone call to each network operator asking if it is okay to make the connection?
Typically phone or email is involved to ensure that both customers want the cross-link setup. But it is bilateral agreement, with the link being set up by a third party.
There are a number of standard access control solutions for authorizing access to resources, including protocols for acquiring said permissions (tokens, authorization certificates, etc.). The problem is we need to understand the types of policies that will need to be enforced so we can determine an kind of solution. I remember the discussion in Uppsala where someone had a policy decision based on a transit network three times removed from the current network.
Yeah, we have those. They are typically related to link AUPs. I can make arbitrary long ones though. The switching node mechanism in NML cannot describe these cases. Blocking upstream networks is not that uncommon in BGP. Juniper even has some examples with it, e.g.: http://www.juniper.net/documentation/en_US/junos13.3/topics/example/policy-a...
The following presents a scheme that keeps the port under control by their respective NSA, doesn't require any static pre-allocation, and does not require any out-of-band token distribution. [snip]
OMG - this is exactly like the Network Element "Gun rack" I designed and applied for a patent on back in the days of the Pacific Bell purchase by SBC. I love it. Now that I see it I realized we had the exact same problem in Optical back in the good old Nortel days.
[snip]
As a cost cutting measure they started sharing single Network Elements with their peering partners instead of back-to-back configurations.
We have started doing something like this several places for the exact same cost-cutting reason. A lot of this also aligns up quite well with the GNA. [snip]
So the assumption here is that NSA X has port A and port B defined with a special policy indicating that the special two step reservation must be performed?
Yes. My idea was that the NSA should announce something else than UPA role, but maybe it needs to be per port (but I am not happy about that complexity). It also possible to have the networks present direct links in their topology and have the entire thing encapsulated. This makes the exchange points disappear from the topology :-)
Also, NSA A talks directly to NSA B in step 2?
Yes (though technically it could be forwarded, but I dislike request forwarding, as NSA access revocation becomes a pain = bad security design). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi Henrik- I have some thoughts about this issue and possible solution... I think we quibble about who "owns" the interface at an open exchange point. As JohnM suggests, this is an artifact from the old days (some early days of the OXP discussions) that far predate even JV and I - this was a GLIF issue as far back as 2002 or 2003 (the UvA guys did a lot of early work on the OXP concept) Today, the generalized "model" of an interface or a Port, is somewhat dimensionless - it is simply a place where two domains meet and exchange data across a shared boundary. ...neither side "owns" the actual interface itself - they *share* the use of "interface" between their domains. (We are not talking about a physical electronic component here, rather the notion of an boundary portal that links two adjacent domains.) Even OXPs got past the ownership issue and recognize now that the issue is really about /policy - a joint policy - /but still just policy. I.e. the underlying mechanisms for signaling and authorizing segments must be symetric and scalable - you cannot place some domains at an advantage or disadvantage. So, first, I think the the issue seems to be that NSI allows the NSAs on each side of the SDP full unilateral control over their respective domains. This reflects reality and is fundamentally a good required thing. But this does not recognize the "shared" nature of the SDP itself. And regardless of any specific policy implemented by the domains, the fact that the interface affects both parties means (IMO) that we should have a generalized behavior of NSI protocol that reflects this and involves both parties - thus giving both NSAs the chance to coordinate their activites. By "generalized" I mean it is a common behavior that applies for *all* SDP boundary interfaces so that it eliminates special case processing (and thus keeps the protocol as simple as possible.) Second, your token solution asks permision to establish, but does not deal with notification of removal - which must also be considered. I.e. any mechanism that must coordinate the set up of a segment must also coordinate the tear down of that segment so that both parties can maintain a consistent state. And anything/everything you do that affects the shared state of the interface must be so coordinated. Third, any mechanism that relies on "unguessable" secret tokens is suspect. If you need secure mechanisms, make sure they are secure. If you don't use actual secure mechanisms, then someone *WILL* exploit them in ways that will negatively affect your interests. Fourth, your example seems to treat Exchange Points like they are different from other networks. I assert they are not functionally or architecturally different from a service model or protocol perspective. In your example, you worry about the prospect that the OXP service X may establish a connection that terminates on X.b without informing B that it has done so. What you don't seem to worry about is that B could do likewise... B could also be an OXP service and terminate a segment on B.x and not inform X that it has done so. Why treat these as different situations? All three domains (A,B, and X) could be acting as open transit domains or exchange points for a much larger set of connected neighbors...(e.g. AutoGOLE) Exchange domains should not be treated specially - they only have a different policy. The more important question is: If it is important that a adjacecnt NSA be notified of activities on the SDP by the neighbor NSA, does NSI have a means of doing so? And given a mechansim for doing so, can you verify that it is actually being done and being done properly? What we need is a /general/ means of insuring that both sides of an adjacency are part of the confirmation process - and each may have a differenent policy to apply to segments that terminate on the other side of a shared SDP. One member of the SDP is the transit domain in the middle, and the other member is the respective upstream or downstream domain forming the other side of the SDP. And any domain may be a "transit" domain on any given reservation request. We discussed this very issue in Delft a couple years ago - how do we notify an end domain of a circuit terminating at its upstream edge but which does not actually transit the end domain? (ESnet brought it up as I recall.) The OXP issue is exactly the same issue. So we now have two separate use cases for this "cross-SDP" confirmation. In Delft, I proposed a "null segment" approach - I.e. we send a segment Reserve() request to the NSA on the far side (downstream side) of the SDP - even though the original [transit] segment terminated only at the STP on the upstream (transit) side of the SDP. In the OXP example, the [original] transit segment request would be (X.a>X.b) - If this segment is sent to X, the exchange will expand the request into three sub-segments: (null>A.x) (X.a>X.b) (B.x>null) The first and last segments are "null segments" because they have no actual segment path :-) The first "null" segment is sent to A for reservation and confirmation, the second [normal] segment is processed locally by X, and the third segment is sent to B for reservation. If either A or B reject the null segments, the original transit segment fails and the whole transit connection cranks back normally. In null segment processing, Domains A and B only accept null segments from their direct SDP neighbors. Domains A and B mark their respective STPs as allocated to this null segment, and just like any other segment, a confirmation is returned with a Cid. -->Just like any other circuit. Null segment reservtions just consume no actual transport resources inside the domain - only at the SDP. Thus the domains A and B both now know of a circuit that terminated on their SDP - and they know the particulars such as the label used or the bw assigned etc. And they have both had the chance to reject it. And it was done using the same NSI Reserve() primitive any other request would use. (Note: Henrik's X.IC suggestion is simply a twist on EROs. Instead of the X.IC, one could also submit (A.x>[X.a,X.b]>B.x) to X which gets decomposed into (A.x>X.a), (X.a>X.b), (X.b>B.x ). I would assert that since A.x and X.a are a pair that define an SDP, that they are also "null segments". But the reservation process cannot effectively process these SDP bound requests, it must be further refined by the original segmentation process to reflect segments residing completely in the remote domain(s) - i.e. my "null segments" (<null>A.x). So I assert we do not have to change the existing segmentation functions we have now - just have a reserve() recognize a null segment as legitimate. If we tweek the NSI protocol rules to state that segments terminating on an SDP _/must/_ send a null segment to the NSA on the other side, this will cause all NSAs to be notified whenever a segment lands on their front porch. Any subsequent segment request to the downstream NSA asking for a real [non-null] segment simply builds a normal segment across the downstream domain just as it would have normally. And similarly, because the normal downstream segment terminated on an SDP, another null segment is sent upstream to the neighbor NSA. Now both NSAs were informed of the circuits landing on their shared SDP. Its a symetric solution, and all Reserve() functions are the same. Note: IMO, a null segment should not allow traffic to transit the SDP interface unless there is a normal connection established on the SDP to carry the data. Null segments do not go anywhere. This NSI change requires only: a) the NSI standard is changed to send null segments across SDPs for a Reserve() and also for a Terminate() (Cancel()?) primitives. (Remember we need to notify of any/all changes on the SDP so that both sides can keep track.) But wait! There's more! The null segment Reservation Id (CID?) when returned form the downstream NSA provides linkage information from the local transit Resv ID to a Reservation in the immediate downstream network of the concatenated circuit. These reservation ids of the null segments can be saved in the service tree. /This creates an end to end concatenation chain that follows the data plane/ rather than the NSI service tree. Thus we have a means of acquiring an authorized list of segments end to end without traversing the whole control plane segmentation tree. The one problem in all of these cross-SDP neighbor authorization schemes is that we can never control what another autonomous domain may *actually* do - we can only rely on those characteristics that we can test and verify them. So we have a problem: even though we may require certain things be done in/by the remote domain, if we do not have a means of independently verifying that these requirements are in fact being performed, then we are essentially saying that we cannot tell if they are being performed.... so... why require them in the first place??? Some things we can verify - like creation of the circuit...we can throw data through the circuit and measure it. But some things we cannot indepedently verify... e.g. there is no way to *independently* assess what is actually happening inside the remote domain. Short of this verifiable evidence, we can only hope and trust that the remote domain will do the right thing... If we trust the remote domain, then we send or receive null segments as we see fit and act on the presumption that our neighbor sees fit to send null segments to us on the basis of a similar policy. For instance, even if we *require* SDP null segment notification, if the transit domain does *not* notify the downstream domain of segments terminating on the upstream side of the SDP, there is nothing the downstream agent can do. The downstream agent will not even know it. The only way I believe you can detect unauthorized upstream segments is to try to reserve your own segment - if it is rejected, it *may* be due to "STP in use" collision (it may be rejected for many possible reasons.) And there are legitimate reasons that one domain or the other may provision circuits to an SDP that may totally confuse and baffle the other side - but which do not fundamentally affect the interface functionality. Finally, this null segment proposal mechanism allows both NSAs on the SDP to confirm or reject a request landing on the SDP. But it does not address the actual policy issues allowing authorization or not: First - not all activities in the neighbor's yard are your business despite the fact that they may change the status quo between you. Second - the authorization decision may need to be based upon information not currently carried in the segment request (e.g. who at the far end wants to land the circuit on the SDP?) The latter question is probably a good place for tokens to be carried end to end - but even this is unreliable.) The former issue is just something outside of your control... So, it comes down to trust. How much do you trust your chain of providers to look out for your best interests? ... particularly since these providers are either profit oriented commercial operations, or government funded projects... ? So I propose we consider implementing a "null segment" process for SDP authorization coordination. I believe it minimizes added complexity to the protocol, and does not impose/assume any domain specific special cases. Thoughts? Jerry On 12/10/14, 5:18 AM, Henrik Thostrup Jensen wrote:
Hi
(part two of the security and pathfinding)
We are currently treating exchange points like switches (which is not really that weird, as that is what they are). Specifically, we are treating them as an independent domain, which does not reflect that the ports on exchange is leased by the connecting network, and hence be under control of the NSA of that network.
Allowing a third party NSA to create circuits on an exchange to another networks port violoates the simple principle that an NSA should be in charge of the networks resources. This means that a network can no longer decicde how it wants to allocate its resources, which is pretty bad. There are some potential solutions to this like allocating a static vlan range to a certain network-network combination, but it is inefficient resource-wise.
Requiring a token is another possiblity, but adds much complexity, as the token must be aquired apriori. As there is no standard mechanism in place for acquiring these, it would often end up being a long-lived token with wide permissions, which is less than ideal security-wise.
The following presents a scheme that keeps the port under control by their respective NSA, doesn't require any static pre-allocation, and does not require any out-of-band token distribution. It can be seen as a standard mechanism for acquiring a token for setup. It does change the path setup flow somewhat, and requires special behavior for the exchange NSA, and the pathfinders using it. Finally it requires a control-level peering between the two NSAs responsible for the networks connecting to the exchange.
We have the following scenario:
Two networks: A & B One exchange: X
The networks connect to the exchange on port X.A and X.B.
NSA for network A, wants to setup a circuit from A to B over the exchange.
The NSA for the exchange knows the identities of the NSAs for Network A & B, but will only allow them to allocate resource on their port. Having an exchange NSA operate in this manner is essential, as networks should only be able to allocate resources on their own ports (I don't consider the exchange backplane to be an issue here, usally congestion happens on the links).
The circuit is setup on the following way:
NSA for Network A, requests a circuit on the exchange from port X.A to a logical/virtual STP, named X.IC (for interconnect) in this example. The NSA for X recognizes that NSA A has the right to allocate resouces on port X.A, and grants the request. The STP returned for X.IC, is not X.IC, but instead X.A with a label (or token) on it. This label is randomly generated, and cannot be guessed (it could be a UUID, but it doesn't matter).
Hereafter NSA A, makes a request to NSA B, with the newly created STP (with token), to create a circuit (could be tree or chain, doesn't matter), lets say it connect to B.P. NSA B will split this request up into two requests: One to NSA X for X.A to X.B (using the token, NSA X allow using X.A, and the NSA B is allowed to use X.B), and an internal link from X.B to B.P. When both requests have completed, a reply is send to NSA A.
A perhaps more comprehensible version of the example:
1: Request from NSA A to NSA X: Reserve: X.A -> X.IC Response: X.A -> X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43
2. Reserve from NSA A to NSA B: Reserve: X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 -> B.P
2A: Request from NSA B to NSA X: Reserve: X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 -> X.B Response: X.A - X.B
2B: NSA B Interal Reserve: Reserve: X.B -> X.P Response: X.B -> X.P
Response: X.A -> B.P
Using this schema we avoid the situation where third party NSAs can allocate resource on networks without going through the NSA of the network.
For the scheme to work, NSAs operating exchange points need to change the behavior of what they allow and how links are set up. Furthermore, they need to advertise this behaviour through their discovery service.
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 On Fri, 12 Dec 2014, Jerry Sobieski wrote:
I think we quibble about who "owns" the interface at an open exchange point. As JohnM suggests, this is an artifact from the old days (some early days of the OXP discussions) that far predate even JV and I - this was a GLIF issue as far back as 2002 or 2003 (the UvA guys did a lot of early work on the OXP concept) Today, the generalized "model" of an interface or a Port, is somewhat dimensionless - it is simply a place where two domains meet and exchange data across a shared boundary. ...neither side "owns" the actual interface itself - they *share* the use of "interface" between their domains. (We are not talking about a physical electronic component here, rather the notion of an boundary portal that links two adjacent domains.) Even OXPs got past the ownership issue and recognize now that the issue is really about policy - a joint policy - but still just policy. I.e. the underlying mechanisms for signaling and authorizing segments must be symetric and scalable - you cannot place some domains at an advantage or disadvantage.
I agree that at the end it comes down to policy. However we have been shying away from that subject for years and now it comes back to bites us. In order to for an NSA to be able to adminstrate policy there are some givens: * The NSA must be in control of it resources. This is actually not the case at exchanges. And some resources require bilateral agreements to reserve. * The NSA knows the nature of the request That means it know who makes it (maybe not user, but role), and how the path is made. Chain implicitely solves a part of this problem. Tree makes it worse, as I don't know if the request actually comes from a customer or has approved. It puts the NSAs in an information vacuum.
So, first, I think the the issue seems to be that NSI allows the NSAs on each side of the SDP full unilateral control over their respective domains. This reflects reality and is fundamentally a good required thing. But this does not recognize the "shared" nature of the SDP itself. And regardless of any specific policy implemented by the domains, the fact that the interface affects both parties means (IMO) that we should have a generalized behavior of NSI protocol that reflects this and involves both parties - thus giving both NSAs the chance to coordinate their activites. By "generalized" I mean it is a common behavior that applies for *all* SDP boundary interfaces so that it eliminates special case processing (and thus keeps the protocol as simple as possible.)
Links with different domain in each end does indeed have this problem. Chain actually solves this by asking the other end if the allocation is ok before setup can continue. Tree makes However the case I am making here is for exchanges. Here it is not links, but ports (I guess we can consider the exchange backplane a link, but no one tends to care about that as there is generally enough bandwidth there) and that they are controlled by a third party. Further an NSA can no longer decide who they connect two.
Second, your token solution asks permision to establish, but does not deal with notification of removal - which must also be considered. I.e. any mechanism that must coordinate the set up of a segment must also coordinate the tear down of that segment so that both parties can maintain a consistent state. And anything/everything you do that affects the shared state of the interface must be so coordinated.
The workflow must also be used for all subsequent operations, and provision/forcedEnd, etc. should all work with it.
Third, any mechanism that relies on "unguessable" secret tokens is suspect. If you need secure mechanisms, make sure they are secure. If you don't use actual secure mechanisms, then someone *WILL* exploit them in ways that will negatively affect your interests.
I am pretty sure the scheme is secure. I intentionally designed the STPs such that they could be passed around. The tokens can easily by generated in such a way that they are by all practical means unguessable. Do you have an actual attack / weakness here? Vague speculation about security mechanisms doesn't do any good.
Fourth, your example seems to treat Exchange Points like they are different from other networks.
Yes.
I assert they are not functionally or architecturally different from a service model or protocol perspective.
I argue that they are adminstratively different.
In your example, you worry about the prospect that the OXP service X may establish a connection that terminates on X.b without informing B that it has done so. What you don't seem to worry about is that B could do likewise... B could also be an OXP service and terminate a segment on B.x and not inform X that it has done so.
That is the problem. You are allocating resources on someone elses equipment without them knowing.
Why treat these as different situations?
How did you get the idea that I am? One of the sides have to initiate the request, but the problem is the same from both sides.
All three domains (A,B, and X) could be acting as open transit domains or exchange points for a much larger set of connected neighbors...(e.g. AutoGOLE)
While I think open transit domains are pipe dream, I do see the issue. But we have no way to advertise this today (but stay tuned for part 3 :-)).
Exchange domains should not be treated specially - they only have a different policy.
I disagree :-). In particular because the exchange self does not know about the connecting networks policy.
The more important question is: If it is important that a adjacecnt NSA be notified of activities on the SDP by the neighbor NSA,
I believe it answer is, most certainly. It should also be given the opertunity to yes or no.
does NSI have a means of doing so?
With the scheme I presented, yes.
And given a mechansim for doing so, can you verify that it is actually being done and being done properly?
That is what the scheme I propose does.
What we need is a general means of insuring that both sides of an adjacency are part of the confirmation process - and each may have a differenent policy to apply to segments that terminate on the other side of a shared SDP.
That is what the scheme I propose does.
One member of the SDP is the transit domain in the middle, and the other member is the respective upstream or downstream domain forming the other side of the SDP. And any domain may be a "transit" domain on any given reservation request.
I believe the scheme can be extended to an arbitrary number of NSAs, but not sure that is practical (Chin already asked about this on the previous call).
We discussed this very issue in Delft a couple years ago - how do we notify an end domain of a circuit terminating at its upstream edge but which does not actually transit the end domain? (ESnet brought it up as I recall.)
I have the same problem when I get a tree request from a peer: How do I know my customer actually wants this link.
The OXP issue is exactly the same issue. So we now have two separate use cases for this "cross-SDP" confirmation. In Delft, I proposed a "null segment" approach - I.e. we send a segment Reserve() request to the NSA on the far side (downstream side) of the SDP - even though the original [transit] segment terminated only at the STP on the upstream (transit) side of the SDP. In the OXP example, the [original] transit segment request would be (X.a>X.b) - If this segment is sent to X, the exchange will expand the request into three sub-segments: (null>A.x) (X.a>X.b) (B.x>null) The first and last segments are "null segments" because they have no actual segment path :-) The first "null" segment is sent to A for reservation and confirmation, the second [normal] segment is processed locally by X, and the third segment is sent to B for reservation. If either A or B reject the null segments, the original transit segment fails and the whole transit connection cranks back normally.
I believe that approach achieves the exact same thing as what I am proposing. Just in a slightly different way. Both have problems fitting into classical NSI workflow. Have you checked (or though about) that the null approach doesn't end up in weird situations with concurrent requests? I wasn't in Delft, so I was not aware of the proposal. I gave up reading all of it. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (3)
-
Henrik Thostrup Jensen -
Jerry Sobieski -
John MacAuley