BCP38 For BGP Customers

Tue Nov 8 22:54:57 UTC 2022

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