[Nsi-wg] Policy use cases

Tue Mar 17 13:38:21 EDT 2015

On 2015-03-17, at 9:25 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:
> 
> So this is still vulnerable to the attack where an NSA claims that it does one thing, but does another. Somtimes trust is enough. Sometimes verification is needed.

If I look specifically at CHAIN, then both my unsigned solution and your solution we are vulnerable to this problem.  We can only trust the directly connected peers.  By exchanging the path header with our direct peers we achieve a solution similar to your additional protocol, but it occurs on the reserveConfirm path back, whereas yours occurs on the reserve path out.

The digitally signed solution is the only one allowing a uPA to verify everyone it cares about approved the message.  If we want something that does not involve this additional signing, then we need to expand the protocol as you suggest to get approvals from any uPA in the path (not just adjacent). However, once we do this we are implicitly signing anyways since TLS will be used to encrypt the protocol to the other uPA.

> 
> Also: This means that if a single circuit allocation fails, the whole thing has to be terminated and started over. And this goes all the way down to label assignment, as it cannot be assume that vlan/labels are policy-free.

Looking specifically at the unsigned CHAIN case the answer is no.  There is early failure on the reserve path out allowing an uPA not liking the path so far to reject it.  This can either be failed back to the headend, or another route can be chosen at any preceding uPA on the path.  On the reserveConfirmed path back any uPA failing approval can automatically terminate downstream, and send a reserveFailed back to the upstream uPA allowing it to attempt a new path.  Obviously, the easiest way is to fail back to the start and let the uRA handle it.

There is the question of how far a reservation has to fail back before it can get a successful path.  Your policy example where networks decisions are made based on uPA twice removed from the enforcement point means the the preceding uPA might not be able to get a viable path, and need to fail back further.  This is an issue with both our proposals.

>> This works because we trust NSA that are members of the control plane. We trust they will not make a fraudulent request, and we trust a reserveFailed will be handled properly.  Within the context of the existing NSI CS definition this solution will give the correct and desired behaviours for policy enforcement, as well as not require any changes to the standard messaging.
> 
> Except for the protocol extensions needed for this.

Yes, we need to put the path in the header similar to the extensions for security attributes and the Gof3 path trace.

> 
>> Now, if you do not trust the NSA connected to the control plane we have a completely different issue which opens up a new can of worms.
> 
> Indeed it does. Trusting the entire control plane makes administration very backwards. Each time a new organization wants to join, everyone in the system has to give an ok. What is the process for removal? A single control plane of trust is not really a multi-domain system.
> 
> Allowing everyone to request anything at everyone is a very tricky situation. Especially since we do not have a good security model for transit networks. Leaf networks (the ones with endpoints) can do token verification or similar. Transit networks don't have that option.
> 
> The only reasonable security model for transit networks I have been able to come up with, is where they chain the request to the customer, and the customers says yay or nay (if the request contains a valid credential for the endpoint everything is probably ok). Treating transit networks as UPAs doesn't work as it doesn't give them any method of verifying the request.
> 

I am a little muddled by this statement as I thought the proposals supported this in CHAIN mode.  Let's use the diagram B-X-C

On the reserve out B approves the local segment so far (given a local uRA initiated the connection not much to approve).  X gets the request from B and sees it wants to go to C.  It knows it needs C's approval before allowing the reservation, so it holds local resources associated with the reservation and passed it to C.  C gets the request from X, sees the path so far is B-X which is can trust because it trusts X and X is directly connected to B so it must be correct.  C approves the reservation, and returns the full path and a reserveConfirmed to X.  X sees C has approved the reservation so it can now approve the local reservation segment, and passes back to B.  B gets the reserveConfirmed with an approved path B-X-C and is happy so issues the reserveConfirmed back to the uRA.

Does this not do exactly what you want without the need for an additional overlay protocol?  Are you worried about temporarily holding the resources between B and C within X on the reserve path out?  I think that the window for timeout is small enough that this is not an issue.

The issue of X gets much more complicated with the diagram A-B-X-C, where X is once removed from A so it must trust B is correctly reporting A as the ingress path, and that A is in fact, properly reporting itself as the originator of the reservation.  But who do we not trust?

You trust B and C because they are direct peerings.  You trust that they follow the proper working order of the protocol otherwise you would not have peered with them.  Asking them directly through an overlay protocol provides no additional trust beyond what you already have with the direct CS peering.  If we dismiss the temporary holding of resources issue, then there is no additional value in a new overlay protocol for asserting policy for B and C.

Now X is once removed from A, so perhaps it does not trust A to properly report itself as the originator of the reservation request (it really came from Canada and we know how we hate the Canadians).  Now here is the problem… How do we get to the point where X can trust A?  Is transitive trust not enough?  X trusts B and B trusts A so X trusts A?  Obviously, this sounds like as socialist plot and could not possibly work.

So as a solution to the problem X sets up an out-of-band peering with A to validate the connection segment for proper policy enforcement.  In our connection example it asks A if it did indeed make a connection from the uRA to B that will terminate on C.  A politely says responds "Yes".

We have now verified that A did issues the reservation in question.  Hmmm… but what if A is lying?  But how could it possibly be lying?  From the simple fact we set up the direct "policy verification peering" to make sure it was not originally lying does in no way mean it will not be lying now.  We have boxed ourselves into a corner.  I do not trust A not to lie to me in the CS protocol, but I do trust it not to lie to me in this new Policy protocol because I am talking directly to it?

But maybe you were really trying to catch B in a lie because you know B is directly connected to the Canadians and he might try to pass it off as traffic from the US (A).  Unfortunately, this is the only situation where you can really find something is amiss.  X absolutely trusts no one and will talk to each network along the path (A, B and C) to see if that are all telling a similar story, and only when you are comfortable everyone thinks they are doing the same thing and are happy with it will you approve the connection.  Of course, the edges can still be lying and there is nothing you can do about it.

Oh we are going to have so much fun in Washington!

>> However, if we want to go down this path and remove trust from the control plane, then I have a proposal that works for both TREE and CHAIN within the existing messaging framework.  In this case we use the reserve/reserveConfirm messaging sequence to have the uPA digitally sign the full path as an approval, then the reserveCommit messaging sequence as a verification phase, where each uPA can validate the approvals of any needed remote uPA by verifying the digitally signed the segment. In the Exchange case the uPA would only need to verify the signature of adjacent networks, but it is generic enough to be any network in the path.
>> 
>> The digital signature method absolutely guarantees that a uPA has signed the same path you did so any trickery is removed.  The only additional administration overhead is requiring access to the public certificate of any peer network you would like to verify signed the message, but since you would have probably already provisioned those certificates as part of a peering agreement, there would be no additional work.
>> 
>> The big difference between the signed and unsigned proposal is that the signed proposal requires all uPA to hold onto the reservation resources until it can verify the peer signatures in the reserveCommit message. This is not so bad as any policy violating paths will have already been rejected in the reserve/reserveConfirmed phase, and we are only looking for trickery in the reserveCommit phase.
> 
> You are missing the point. Signing only gives repudiation. It does not give a transit network anything regarding if the circuit is actually allowed to transit. There can be cases where the same entity should be allowed to create circuits and cases where it should not.

I must be missing the point.  I am using signing to communicate a network's approval of their connection segment in the overall path, or more specifically, their authorization allowing the path to be created based on their local policies.  It sounds like you are talking about the communication of policy such that a pathfinder can make proper routing decisions in either a source or hop-by-hop configuration.  These are actually two separate but related issues.

> 
> 
>    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/20150317/f0968996/attachment.bin>