[Nsi-wg] Security and Exchanges

[Henrik Thostrup Jensen]

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