On Dec 18, 2012, at 3:03 PM, "Sriram, Kotikalapudi" <kotikalapudi.sri...@nist.gov> 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.
Sound fine in theory, but will not work in practice. *When* the original announcement is a (IPv4) /24 and all providers filter on announcements > /24 ... you're, umm, up a creek without a paddle if you don't have an ability to [immediately] originate the same /24 from a "proxy" AS. Remember, there's a *lot* of "legitimate" more specifics out there already, primarily for the purposes of Traffic Engineering (TE). -shane > 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: sidr-boun...@ietf.org [sidr-boun...@ietf.org] On Behalf Of Borchert, >> Oliver [oliver.borch...@nist.gov] >> 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 > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
