[Nsi-wg] Policy use cases

[John MacAuley]

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.

In CHAIN each path segment is added to the header as it proceeds down the chain.  When the end uPA is reached it resolves its local segment, validates the complete path against local policies, and if approved, returns the full path in the reserveConfirmed for each uPA along the return path to approve as well.

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.

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

I will go into more detail in Washington in a couple of weeks.

Thanks,
John

On 2015-03-09, at 6:43 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:

> On Mon, 9 Mar 2015, Henrik Thostrup Jensen wrote:
> 
>> I am aware of the possibility of including source/destination STPs as proposed elsewhere, but that is flawed too (but I will answer that in another email replying to that slideset, as there are multiple issue with that).
> 
> I cannot find the suggestion for this, so I'll just add it here.
> 
> Adding source/destination STPs to the request was suggested (I think) as a way for UPAs to check if transit policy was kept. However:
> 
> 1. I cannot actually convince my self it is enough. While it will certainly catch some cases that cannot be cought from looking at the cross-connect there might be some situations where it is not enough. I don't have a counter-example, but I haven't seen an argument for why it should be correct.
> 
> 2. The data is informational only. I.e., all one have to abuse the system, is to craft a request with some other source/destination than what is planned. That is, the mechanism is practially trivial to bypass. It should be difficult - not easy - to abuse the system.
> 
> 
>    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