>>> 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 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. > 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." It's like your customer comes to you and says, "I want you to build me a 10,000 node L2VPN." You could just say, "sure, it'll cost you x." But if you're intelligent, you'll have a design person on staff who works will sales who understands, from the outset, that this is a disaster going someplace to happen --so you ask, "what is the problem you're trying to solve?" If the customer comes back with, "I'm trying to build a 10,000 switch layer 2 network," have they answered your question? > 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." > 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: >> 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 question here is --should C be transiting traffic to A? 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 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 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. > 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... :-) Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
