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