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 > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
