> In your example where AS_A buys transit from AS_B and AS_B buy transit / > Peers with AS_X, AS)Y, and AS_Z... > > When AS_B announces AS_A's prefix to its upstreams, it is asserting two > things: > > 1. AS_B learned the prefix from AS_A, choose it as best, and does not have > policy to limit the distribution of the route.
Who's policy? I think this is where the problem really lies, isn't it? Are you trying to prove that AS_B has not restricted AS_A from sending these routes along to its peers? If so, why should AS_A's peers pay any attention to what AS_B's policy is? IE, the only person who should enforce AS_B's policy with AS_A is AS_B itself --or am I missing something? Further, is the _only_ policy anyone really cares about whether or not AS_B "authorizes" AS_A to send routes on to its peers? Are there no other policies in play here? In other words, we're going to build an entire security system around one policy that's not really contained within the protocol today? This is why I really, really, want the requirements clarified. > 2. That network represented as AS_B has the right to use the ASN value > AS_B. This has nothing to do with signing updates, to be honest --in fact, this is something that I've been bothered about for a long long time. Do the RIR's really want to get into the "you're really who you say you are," business? If someone can fool the RIR into thinking they're Banco Rio, and get a corresponding AS claiming such through a validated certification, and I put my account information into a web site based on this information, and I lose my identity, can I sue the RIR for not doing a good job of being certain who people really are? If not, then what have I gained here? This is the larger problem we've kind-of just left under the covers, but it's bound to come popping out at some point or another. I would prefer it not come out in a court case, honestly. :-) At any rate, this second piece is well outside the scope of path validation, I think. :-) Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
