One solution here is that the mitigator either prepends the victims AS (works with "origin only") including the downside that the path is one hop longer. But hey, better than nothing. For origin + path validation the victim creates a bgpsec peering with the mitigator and signs the path. This can be done pretty easily I guess. This might not be the most effective solution but IMHO it works ;-)
Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology -----Original Message----- From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy Bush Sent: Tuesday, December 18, 2012 2:48 PM To: sidr wg list Subject: [sidr] the need for speed I am trying to understand why our fellow engineers at Verisign are obsessed with global propagation of RPKI data on the order of a few minutes. Then a friend hit me with the clue by four. It's about third party DDoS (and other attack) mitigation. When an NTT (just an example) customer is attacked, the customer can request that their upstream sink and scrub the traffic as it naturally passes through NTT. NTT passes the scrubbed traffic on to the customer, and that's that. But, when the customer's upstream does not provide such services, or the customer has other reasons for not using the upstream service, they can buy the scrubbing service from a third party, e.g. Verisign. Verisign will announce the customer's prefix(es) from a Verisign AS, receive the traffic, scrub it clean, and send the cleaned traffic to the customer, often via a tunnel. Well and good, except Verisign is announcing someone else's prefix, a basic violation of BGP origination validation. Naturally, the customer who contracts to Verisign for this service issues a ROA for the prefix(es) to the Verisign AS, and it is not a violation, all is serene. But what if Verisign wants to take on a new customer in panic "Help, I am being attacked and will pay you a lot of money to fix this?" The time for the fix is dependent on how quickly a new ROA for the victim's prefix(es) can propagate. Alternatively, the victim could pull their normal ROA(s) for their prefix(es) and the world would get NotFound and believe Verisign's announcement(s). But this too relies on quick propagation of RPKI data. Observe that this is a problem in origin validation, i.e. what is being deployed today. The RFCs are published, the code is in the routers, ... the horse has left the barn. Yet another item to go into the display case of security vs. utility. Ah well. But I sympathize with Verisign's business case and have no desire to whack it. And I assume others think similarly. There is this little problem. Today, the Internet has no technology for reliable global fast distribution of a database. No, DNS is not the answer. But please have that argument on a different thread. The only thing of which I am aware is Google's Spanner [0], which is a brilliant piece of work. But it is not lightweight (e.g. True Time), is proprietary, is likely considered very secret sauce, and even Google lists it as research as opposed to beta :) IMIHO, this is a *really* interesting area for research, though I suspect sidr is not the place to conduct it. But it's research, not something we can paint on today. So we are left with propagation on the order of a very few hours, AKA 'human time', and our discussions of how to reduce load on CAs so we can query them more frequently. randy --- [0] - http://research.google.com/archive/spanner.html _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
