Since the intent is good, it is not an “attack” (at least as far as the mitigator and the victim are concerned). In BGPSEC (i.e. the path validation case), the proposed solution (below) is clearly not even an apparent attack. The victim (customer) is intentionally propagating a signed update to a service provider (the mitigator). The DDoS mitigation works (continues to work like it does today) without having to create/propagate new RPKI objects. Sriram ________________________________________ From: [email protected] [[email protected]] On Behalf Of Ross Anderson [[email protected]] Sent: Tuesday, December 18, 2012 5:10 PM To: Sriram, Kotikalapudi Cc: Borchert, Oliver; Randy Bush; sidr wg list Subject: Re: [sidr] the need for speed
So to mitigate an attack you conduct another one ... Ross On 18/12/2012, Sriram, Kotikalapudi <[email protected]> wrote: > Adding to Oliver's suggestion, it will be even more effective if, in the > "origin only" case, > the mitigator announces a slightly more specific (e.g., two /17s for a /16) > > if the maxlength of the victim's existing ROA permits it (of course, > victim’s AS is inserted > as the origin AS as suggested). > More specific wins, so the downside of one hop longer path length goes away. > > > And in the full path validation case, the victim forward signs a more > specific > (if permissible by existing ROA) to the mitigator. The victim also sets > pCount = 0 for this update. > > Sriram > >> From: [email protected] [[email protected]] On Behalf Of Borchert, >> Oliver [[email protected]] >> 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. > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
