nanog mailing list archives
Re: BCP38 For BGP Customers
From: William Herrin <bill () herrin us>
Date: Tue, 8 Nov 2022 14:54:57 -0800
On Tue, Nov 8, 2022 at 5:28 AM Douglas Fischer <fischerdouglas () gmail com> wrote:
Another important point to note is that you MUST NOT drop everything else that doesn't match this Prefix-List. But put a bandwidth and PPS control on what doesn't match the prefix-list, and block what exceeds. Among other reasons, it is very common that Exceeded TTL responses come with source IPs for private use, or IP blocks that are for public use but not announced to the DFZ.
Hi Douglas, TTL exceeded messages are not important. They're useful to diagnostics but nothing breaks if they're lost. There's no need to broadly allow misconfigured customers to originate packets from RFC1918 space nor to allow them to originate ICMP type 11 (time exceeded) messages from RFC1918 space. You should not do so. The packets you're worried about here are fragmentation needed: ICMP type 3 code 4. Fragmentation needed messages are used for Path MTU discovery. When PMTUD breaks, TCP fails. Path MTU discovery is the one place in the core TCP/IP protocol stack where the end-to-end principle was abandoned. TCP requires the ability to receive this notification from any midpoint node in order to shrink packets too large for that midpoint node's next hop. It's the most broken part of the TCP/IP design. Unfortunately, your solution of allowing ICMP type 3 messages from RFC1918 space is dysfunctional. Even if you accept the packets (and tailor your acceptance so that it only applies to ICMP type 3 messages with a source address in RFC1918 space) the packets are highly likely to be discarded elsewhere in the path. In the past, I've suggested that vendors implement a feature allowing destination unreachables generated from a privately addressed interface to be originated from a different, user-configured public IP address. So far I haven't seen any takers. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Current thread:
- Re: BCP38 For BGP Customers, (continued)
- Re: BCP38 For BGP Customers Mike Hammett (Nov 08)
- Re: BCP38 For BGP Customers William Herrin (Nov 08)
- RE: BCP38 For BGP Customers Adam Thompson (Nov 22)
- Re: BCP38 For BGP Customers Grant Taylor via NANOG (Nov 08)
- Re: BCP38 For BGP Customers William Herrin (Nov 08)
- Re: BCP38 For BGP Customers Grant Taylor via NANOG (Nov 10)
- Re: BCP38 For BGP Customers William Herrin (Nov 10)
- Re: BCP38 For BGP Customers Jared Mauch (Nov 10)
- Re: BCP38 For BGP Customers Matthew Petach (Nov 08)
- Re: BCP38 For BGP Customers Grant Taylor via NANOG (Nov 08)