On Sun, Feb 13, 2011 at 7:49 AM, 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. > >> originated by the ASN in the first (last? right-most) AS hop, you have >> no real assurance that the prefix-list you used to fllter the route is >> actually correct, and you have no understanding of the path seen in >> the as-path aside from what the text says. (see pilosov/kopella) > > What sort of policy do you want to infer from the as path beyond the > first hop? This is what needs to be in the requirements draft. 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) > Come'on, you're a provider! Don't think about what you want the protocol > to look like, think about what you want the protocol to accomplish! You 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. Verify, with a high degree of certainty, that the origin of this route is authorized to make this announcement." Ideally, with that information I should be able to better inform my route selection process. > stated one thing above, but that really needs some clarity around it > --what policies do you think you can infer from the AS Path? 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. > For instance, given this: > > A---------B > | | > +---C-----+ > > Is the point for B to be able to control whether or not A accepts routes > from C? In other words, is the point to control A's policy towards C, or nope. > to inform A of your policy towards C? Can you actually inform A of your > policy towards C without telling A what your policy towards C is? > nope. 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 basica 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 since d, e, f can't sign the paths... unless of course they suddenly do appear in the path and are properly signing things. 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. I may chose to do nothing with the information as I receive it, or I may chose to prefer 'valid' routes over 'invalid' (or even 'unknown') routes... that's purely a local operator decision. -Chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
