Joel Jaeggli and I had an off-list email discussion. It was a follow up to Joel's earlier post on the sidr list: http://www.ietf.org/mail-archive/web/sidr/current/msg05560.html
With his permission, I am forwarding the email exchange between us here. It is mainly about setting up a BGP session quickly (under the emergency scenario) between a DoS mitigator and the victim. Joel's inputs/insights follow. Sriram -----Original Message----- From: joel jaeggli [mailto:[email protected]] Sent: Saturday, December 29, 2012 8:14 PM So, I'd say first off that I come at this as a consumer of these services (I have used them) rather than as a provider of them. On 12/28/12 6:51 AM, Sriram, Kotikalapudi wrote: > Hi Joel, > > Thanks for your comments. > >> The alternative approach assuming you've planned ahead is to originate >> a more specific with the same origin but Verisign as the transit AS... >> therefore the origin validation works fine. if you do the same with >> the covering prefix you're going to have to either make your other >> providers less desirable, or withdraw the prefix. the backhaul from >> your dos protection provider is done with a tunnel or ideally with a >> private interconnect. > > The ideas you mention above were initiated with these two posts: > > http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html > http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html > > Shane and I have since been discussing various scenarios and nuances > as you might have seen on the sidr list. > > Let me ask a question that perhaps you can offer some help with. > When you have path validation (BGPSEC) in the future, the DDoS > mitigator cannot generate a *signed update* on behalf of the victim. yeah the approach described doesn't solve the path validation problem at least without coordination. > Because in order to do so the mitigator needs the victim's private > key. But sidr wg generally seems to discourage Org A from sharing > private keys with another Org B. > And we are discussing an emergency situation where the victim and > mitigator have had no prior relationship. yeah when you're under duress things are somewhat exciting. > In this case, how easy or difficult is it to set up a BGP peering > session on the fly between from the victim's CE to mitigator's PE? so in the case of mitigation through prefix re-advertisement, typically a tunnel is required from the ddos mitigation provider back to the customers equipment - because you're announcing a prefix from the dos mitigation provider big enough to be accepted on the internet. In general the tunnel needs to be terminated using other address space, so either the block they're announcing is de-aggregated from the victim's address space or the dos provider announces the victim's whole address space and a provider assigned address is used for tunnel termination. There's a design problem here in ipv4 land about deploying your services such that they're separable in the event that you need to move one but not all of them.. > There is no prior connection between them. > Can they set up the BGP session over a TCP session that may span multiple > physical hops? So yes, because you need to backhaul (good) traffic from the ddos mitigation provider to the victims servers over a tunnel or a newly established direct connection, it does not seem infeasible to me to establish a bgp session at the same time that the tunnel is brought up. In fact it probably makes sense to encapsulate the bgp session in the tunnel. Bringing up a session at that time is clearly more complex than not doing it, but if you need it to make it work then it's probably worth it. we did maintain BGP sessions with Verisign for this dos mitigation service for example so that we could among other things signal them as to which prefixes we wanted them to take. > ** How fast can this be done? ** Fundamentally, this is like turning up any other peer, joint coordination is required, if no additional infrastructure has to be provisioned then it's something that can be done rather quickly by two people that know what they're doing. > If the BGP session (BGPSEC in this case) is set up quickly, then the > victim can provide a signed announcement (with an appropriate more > specific prefix) directly to the mitigator and then the mitigator can > propagate it, and intercept the DDoS data traffic for scrubbing and > re-channeling back to the victim's server. So, today when I change my published RADB policy by adding a prefix to my existing providers it can take as long as 24 hours for my upstreams to adjust their RADB generated filters. so there are other considerations that today impact the speed at which some changes can be made, that can be accelerated by calling them and nicely asking to regenerate those objects but does imply some level of planning ahead / confusion occurs when changes are made under duress. Joel _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
