Just to reiterate and expand upon my comments on the presentation John gave on this draft in SIDR today..
In short, I like the idea as it seems like a viable stepping stone to employ the work SIDR has been doing for a while now. I look forward to newer versions of this work, and believe it should be adopted under the SIDR WG, with charter update if need be. -danny --- A few specific things: 1) AS path origin-based policies alone are insufficient, as any targeted attack could most easily spoof the origin AS. 2) When I brought up the issue about targeted attacks John said this is meant to accommodate the 80/20 rule with route leaks, etc. When routes are leaked, which appears to be the most common 'hijack' case today, the origin is preserved. This wouldn't necessarily protect against that. 3) No inherent ability in the current validation modes to prefer shorter validated prefixes over longer non- validated ones means that most hijacks would still prefer the hijacked more-specific prefix. Most actual hijacks, and even leaks such as the YouTube incident, are from more specific prefixes and given preference. 4) Requiring implementations to store prefixes in their respective Adj-RIB-In, even if they've been filtered, such that they're available if policies changes, is a bad idea. Instead, as Jeff suggested at the microphone, employing route refresh in these scenarios would be much more scalable. E.g., in the case of CTBC last week there were like 267k prefixes leaked that would have been stored and filtered, were these capabilities in place. This could easily become a DOS vector itself. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
