On Sun, Feb 13, 2011 at 2:13 PM, Russ White <[email protected]> wrote: > >>>> I think, that today you receive a route in BGP, you believe it's >>>> proper and pass it on. you have no real way to tell if the route was >>> >>> Isn't this what NO_EXPORT is for? Is the entire point of this exercise >>> to encrypt one community? >> >> huh? no, the first (right-most) asn in the path, is that who actually >> originated the route? Are they permitted to originate that route by >> the netblock 'owner'? >> >> these are the questions, I think, origin validation should solve. > > Okay, first, this document isn't about origin validation, it's about
yes, coffee failure. > path validation. So, when you say, "you believe it's proper and you pass > it on," in the context of this document, specifically, you can't be > talking about the origin, but only the _other_ AS numbers listed in the > AS Path. sure, they signed it, the previous as's signed their copy as it passed through. if there's an unsigned as in the path, or a miss-signed one... the path fails validity checks and I can decide something from that. >> I thought it was ... req 3.12 covers what you'd want to do with the >> as-path security information. (or really says you can influence the >> addition to the RIB of a route based on it's security >> information/state) > > No, it just says you can use this information to influence what you put > in your local RIB. That doesn't tell me what question you're trying to > answer. It only says, "my requirement is that the path be signed, and > that I can decide what I want to with that signature." yes. >> sure, 'tell me if the path I see is a lie' (in rough terms)... in more >> complex terms: "verify, with a high degree of certainty, that each hop >> on the supposed path actually saw this copy of this route. > > Why do you care if they're lying? Explain what the problem is if they > are. Don't say, "I don't want you to lie to me." Say, "when someone lies > to me, this is what happens, and I need to be able to prevent that from > happening." that's said below. 'do not accept the affected routes' You want: "Because sending traffic off on a false path causes pain/suffering/unhappy-packets" added to the reqs doc? >> if something like: >> <http://www.renesys.com/tech/presentations/pdf/blackhat-09.pdf> >> >> happens, do not accept the affected routes. Sure, if the provider(s) >> to the customer doing this all did prefix and as-path filtering we >> wouldn't require much else... except that almost no 'Tier-1' to >> 'tier-1' isp peerings are filtered in a meaningful way. > > Then you want to know what the policy is in this diagram: perhaps 'policy' is overloaded here... I don't care what the bgp policy is inside someone else's network. they can choose to accept/deny/up|down-pref announcements to their hearts content. I do care that, as I said below/before, someone can't invent paths in the routing table. >>> A---------B >>> | | >>> +---C-----+ > > Even though you say you don't. Whether a peering relationship is tier 1 > to 2, or the other way around, _is_ a policy --because the specific I knew using the moniker 'tier-1' was going to bite me... "large settlement-free peers". > question here is --should C be transiting traffic to A? actually even in the case of your 3 ASN picture, I don't think we can meaningfully limit route leaks with JUST protocol fixes. We could, however, use the rpki infrastructure to put in proper prefix-filters on the peers in question. > In other words, you're contradicting yourself --you're saying, "I don't > want to infer or enforce policy," but then you go on to say, "this > specific violation of policy is what I'm trying to prevent from happening." > >> The point is to see if along the path a-b-c if the routes C originates >> C is supposed to be able to originate (rpki helps here), and if B has >> changed the basic data about the prefixes C sent it, and to make sure >> that we don't suddenly start accepting routes with paths like: >> >> a-b-d-c >> a-b-d-e-f-c > > In other words, you want to be certain that it's within C's policy to > advertise the route to D, and it's not within C's policy to advertise > the route to F. nope. I want to (for the 2 example paths above, applied to the diagram you created) be certain that in case 1: B is not injecting routes with origin-C and as-path that includes fictional-ASN-D case 2: B is not injecting a path with origin-C and as-path that includes the fictional ASNs D, E, F I didn't speculate on the policy of B nor C here, just that the path I see isn't signed by asn's D E nor F, so they shouldn't be used in this network. >> I don't think it's helpful to tell people what your policy is, nor to >> control external entities by hoping to infer their policy. I do think >> there is some sense in knowing that the route I see is originated by >> an authorized party and that no unauthorized parties are showing up in >> the paths I see. > > But that's precisely what you're trying to do... nope. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
