That's path validation. Anyway, the diameter of the Internet is only about 4 to 5 AS hops. Tier 1's only care about the radius, which is mostly 1, 2 or 3 AS hops.
Given such short AS paths, RPKI can provide a good level of protection already. If the attacker originates a route prepended by the legitimate AS, then his AS-PATH will be longer than that of the legitimate route in the large majority of the Internet. But only if each AS that registers a ROA advertises every prefix matched by the ROA. If it does not, then another AS can easily steal the prefix like you said. If you need to protect a prefix that you don't advertise then put ASN 0 into the ROA for it. Then nobody can advertise it. Thanks, Jakob. From: Sidrops [mailto:[email protected]] On Behalf Of Christopher Morrow Sent: Friday, January 13, 2017 2:05 PM To: Marco Marzetti <[email protected]> Cc: Randy Bush <[email protected]>; [email protected]; GMO Crops <[email protected]>; Job Snijders <[email protected]> Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti <[email protected]<mailto:[email protected]>> wrote: <rant> Every time one suggests a change related to the IXPs world we spend days arguing if it affects the neutrality and how. Do we really need that? </rant> Anyway, i can't see why IXPs can blackhole traffic (if the destination requests it), but cannot do the same with prefixes. After all if a prefix is invalid the owner requested it to be verified by the other parties. I think part of job's point (and randy's in a way) is that you actually don't know if: 192.168.0.0/23<http://192.168.0.0/23> AS1 AS3 AS8 is valid, even if you see a ROA: 192.168.0.0/16<http://192.168.0.0/16> AS8 max-len /23 ... because there's nothing that keeps AS-ME from sending AS-JOB a route with AS8 prepended on the as-path. I suggest to default to drop and, if possible, to switch to announce with community if the peer requests it (for instance someone may want to collect invalid routes for analysis). i think you are describing implementations that the IXP may choose... I don't know that this draft needs to specify that at all. -chris On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush <[email protected]<mailto:[email protected]>> wrote: >> Adding [email protected]<mailto:[email protected]> for reality check. > > no comment :) > > when you choose to use a route server [0], you have out-sourced much of > your policy and operational responsibilities. seems to me that whether > this includes security decisions is a contract between the user and the > route server. > > so i might tell the server to drop invalids. if i do not take that > (configurable, i presume) option, having the server mark them seems > helpful. > > randy > > -- > > 0 - i suspect none of job, carlos, or i do. so this is the experts > telling other people what they should do. :) > > _______________________________________________ > GROW mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/grow -- Marco _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
