[Nsi-wg] Security and Exchanges
Jerry Sobieski
jerry at nordu.net
Fri Dec 12 13:46:32 EST 2014
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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20141212/aa7a080c/attachment-0001.html>
More information about the nsi-wg
mailing list