> So far the only scalable mitigation mechanism seems to be for IX operators to > issue ROAs and IX participants to apply ROV filtering.
> Leveraging the RPKI for this particular case is helpful because it leaves the > IX operator in full control whether the peering LAN prefix should be globally > visible or not (e.g. the IX operator can set the ROA’s origin AS to 0, or > originate the prefix in BGP from a designated ASN). This should be recommended as the default (this is also the practice we follow, by the way). In addition, there should be a discussion of the risks of making a peering LAN prefix globally visible. Any IXP wishing to deviate from the recommendation can still do so. The “do not accept more specifics” part is at least not harmful, but I consider it highly unlikely that a sufficiently large share of the member base of any larger IXP will implement this correctly. It’s simply not their top priority. Kind regards, Matthias On 07.01.25, 18:07, "Job Snijders" <j...@sobornost.net> wrote: On Tue, 7 Jan 2025 at 17:39, Gert Doering <g...@space.net<mailto:g...@space.net> <mailto:g...@space.net<mailto:g...@space.net>>> wrote: On Tue, Jan 07, 2025 at 03:55:00PM +0000, Nick Hilliard wrote: > I'd prefer the section to be dropped completely, and to leave it to > individual IXPs to make their own minds up about what their routing policy > should be for their address space. I think the section "do not (never ever) accept more specifics for any IXP lan you're connected to" is a good one, and should be kept. We've seen accidents where peers did... whatever, and announced more-specifics out of the DECIX FRA peering LAN, leading to interesting outages at those ISPs who accepted the prefix. Needless waste of time to debug that. The existence of a Peering LAN prefix more-specific is one the worst things that can happen to an IX community. So far the only scalable mitigation mechanism seems to be for IX operators to issue ROAs and IX participants to apply ROV filtering. Leveraging the RPKI for this particular case is helpful because it leaves the IX operator in full control whether the peering LAN prefix should be globally visible or not (e.g. the IX operator can set the ROA’s origin AS to 0, or originate the prefix in BGP from a designated ASN). The NIST recommendation seems to somewhat tip-toe around how to actually get things properly done. Kind regards, Job
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
