[Nsi-wg] Security and Exchanges

Wed Dec 10 21:31:01 EST 2014

Comments in-line.

On 2014-12-10, at 5:18 AM, Henrik Thostrup Jensen <htj at 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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1626 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20141210/e5bf8625/attachment.bin>