[Nsi-wg] Policy use cases

[Henrik Thostrup Jensen]

Hi

On Mon, 9 Mar 2015, John MacAuley wrote:

> The proposal was to add the complete path so all the transit cases could 
> be determined.  In TREE the root aggregator would resolve the path and 
> place it in the header.  Each uPA would then validate the full path 
> against their local policies.  If the path violates their policy then 
> they reject it, and the overall reservation fails.  If they accept it, 
> then they return a reserveConfirmed for their segment and wait to see if 
> the remaining uPA approve.

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.

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.

> 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.

> 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.

> 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.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet