Hi all, Doug Montgomery and I are authors of the NIST SP 800-189r1 draft. We are long term IETFers as well. I just read all the messages in this thread. Thank you all for this discussion about LAN prefixes and Security Recommendation 27 (SR #27) in the draft. We will review all your comments and are following the emerging work on BGP opsec update(s) in GROW. We'll update our document accordingly. We are open to revising or dropping SR #27.
The email for public comments on the draft is sp800-...@nist.gov<mailto:sp800-...@nist.gov> ; comment period is open until Feb 25th, 2025. (Announcement: https://csrc.nist.gov/pubs/sp/800/189/r1/ipd ) Regards, Sriram From: Matthias Wichtlhuber <matthias.wichtlhuber=40de-cix....@dmarc.ietf.org> Sent: Tuesday, January 7, 2025 3:26 PM To: Job Snijders <j...@sobornost.net>; Gert Doering <g...@space.net> Cc: Matthias Wichtlhuber <matthias.wichtlhuber=40de-cix....@dmarc.ietf.org>; grow@ietf.org Subject: [GROW] Re: Initial Publication Draft: NIST SP 800-189r1 ipd > 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<mailto: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
