[Nsi-wg] Security and Exchanges

[Henrik Thostrup Jensen]

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