On Tue, Nov 8, 2022 at 5:28 AM Douglas Fischer <fischerdoug...@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/
