Hi Hans On Tue, 2 Dec 2014, Hans Trompert wrote:
Consider the following setup (excuse my ascii art):
A / \ B C \ / D
If D wants to revoke access from A it has to isolate itself by revoking access from B and C.
No, D would ask both B and C to revoke their peers with A. Remember the transitive trust principle here, it is not only true that I trust what others send me but it is also true that I trust that my peers will take corrective measures against an upstream NSA when I ask them to do so.
In the above case that would be relatively easy. The problem occurs when the control plane starts to become highly connected with lots of cliques and a lot of potential forwarding routes. The above schema will work fine with 5-10 NSAs, but I think it will start to have trouble if/when we go over 20. Further, the transit NSA may not wish to do a full revoke (though I think that would be best in many cases), but instead should just stop forwarding requests between the two domains. AFAIK no one has implemented such a feature. This would also be useful, as I would probably be okay with my peer forwarding request from their customers, but not from their peers.
The fundemental problem here is really that we don't have a good security model for transit. BGP has similar conceptual issues, but the source and destination IPs are known, and filters are in place along with limitation such as max prefixes.
It is a pity that my connection trace got voted down during the last f2f NSI meeting. The connection trace could be very helpful here, it will show you how the message reached you and allows all NSAs along the way to verify the correctness of the NSA ID of the sending NSA. This would even allow you to implement a NSA blacklist if you want to protect your NSA.
I agree that it was a shame we lost the connection trace, and agree that it is useful. The usefulness does however fall significantly in tree mode.
I don't have a ready made solution to the issue. Proxy request forwarding has been an integral way in how we think about an NSI system for a long time. I do think the issue is moderately serious, and we should do something about it. In particular, I think we should try to leave the "setup the circuit with all possible means" and instead focussing on providing them in way that is responsible security wise.
We already have a way of authorizing STPs, currently this is only used to authorize endpoint STPs, but as I have been advocating for some time I believe that we will end up with some kind of authorization of intermediate STPs as well. If a reservation request fails because of lack of STP authorization then the message forwarding will stop at that point.
So this fails somewhat into practices of how to forward request as well. But yeah, some form of authZ may happen; I certainly hope so, but have a difficult time seeing how it should work. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet