On Wed, Nov 2, 2011 at 1:41 PM, Russ White <[email protected]> wrote: > 1. Most providers apparently want to enforce policy without telling > anyone what their policy actually is. That this is a logical > contradiction doesn't seem to disturb anyone. > > 2. You can't "enforce" your policy --all you can do is signal to someone > else what that policy is, and ask them nicely to enforce it for you. > > 2a. If you have a business relationship with this other party, then you > already have an enforcement mechanism at hand --signatures and other > sorts of things won't provide anything additional.
Actually, this is not strictly true. Let's consider the smallest case where there are more than two parties, where route leaks cause problems (whether malicious or accidental). Parties: A, B, C. Relationships, all formalized via contracts (whether for transit or peering). C is a customer of A. C is a customer of B. B and A are peers. For sake of argument, presume that A and B also have upstream transit providers. The intended policies have A and B exchanging routes of only their customers, and their internal routes. C receives the full Internet routing table from both A and B. The agreements between A and C, and between B and C, prohibit C sending anything other than C's own routes to A and B. Then consider what happens in the case of C sending B's routes (and B's upstream routes) to A. A prefers routes learned from customers over peer or transit routes. A now prefers the path via C to the entire Internet, including traffic from A to B. There is no _technological_ mechanism for B to stop this, short of turning down C's BGP session. And, this also presumes that B has some definitive way of discovering this, which is not necessarily the case. When we add in D, a transit customer of C, we can see the challenging nature of the problem. How to we distinguish C sending B's routes to D (which is good and expected and allowed), from C sending B's routes to A (not good/unexpected/not "allowed" by contracts)? If there isn't some easy way for A to see that their customer is sending routes which are not their own or their customers', by way of "marking" in the middle of the AS path, then the scale of the problem is huge (having prefix filters and AS-path filters built on ... the IRR). With marking, we gain easy filtering to honor the senders' intentions, and the ability to authenticate things and still limit the information on a need-to-know basis. Observe the following - information about relationships encoded within the path will be visible only to those who receive the path. If the path signals "block me", the relationship information is also blocked. This may be an acceptable degree of information leakage - which happens to coincide with path information, which necessarily must be leaked. Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
