nanog mailing list archives
Re: icmp rpf
From: Ian Mason <nanog () ian co uk>
Date: Mon, 25 Sep 2006 14:06:54 +0100
[ Quotations have been reordered for clarity in the reply ] On 24 Sep 2006, at 22:59, Mark Kent wrote:
If so, which of these two nets is unreasonable in their actions/ policies?
I don't think either are *unreasonable* in what they've done. Both actions are prima facie reasonable but have an unforeseen synthesis that is undesirable.
One of the largest North American network providers filters/drops ICMP messages so that they only pass those with a source IP address that appears in their routing table.
This is clearly reasonable as part of an effort to mitigate ICMP based network abuse. In fact, I'd argue that it would probably be reasonable to drop any packet, not just ICMP, based on its absence from the routing table - conditioned on having a full, stable routing table.
A smaller North American network provider, with a modest North American backbone, numbers their internal routers on public IP space that they do not announce to the world.
Several people have mooted this as good practice on the basis routers do not need to be reachable (as an end system) except by legitimate managers of those routers (i.e. within the AS in question).
As a result, traceroutes from big.net into small.net have numerous hops that time out. Traceroutes from elsewhere that go into small.net but return on big.net also have numerous hops that time out. We do all still think that traceroute is important, don't we?
On balance, it's small.net that will have to change to rectify this. My argument would be:
1) Big.net's approach is wholly legitimate - deny spoofed packets transit.
2) Small.net's intentions are good, but they are pseudo-spoofing packets.
ICMP packets will, by design, originate from the incoming interface used by the packet that triggers the ICMP packet. Thus giving an interface an address is implicitly giving that interface the ability to source packets with that address to potential anywhere in the Internet. If you don't legitimately announce address space then sourcing packets with addresses in that space is (one definition of) spoofing.
On balance both are acting with good intent, but small.net haven't fully seen the consequences for ICMP in their scheme.
Please note that we're not talking about RFC1918 space, or reserved IP space of any kind. Also, think about the scenario where some failurehappens leaving big.net with an incomplete routing table, thus breakingtraceroute when it is perhaps most needed.
Filtering ICMP is always dangerous. If you are going to do it you *must* understand the consequences both to yourself and to others, and also understand the consequences in both normal situations and all possible failure modes. (If I had a penny for every broken PMTU detection I'd seen because of someone's over eager filtering of ICMP...)
Thanks, -mark
Current thread:
- Re: icmp rpf, (continued)
- Re: icmp rpf Roland Dobbins (Sep 24)
- Re: icmp rpf virendra rode // (Sep 24)
- Re: icmp rpf Mark Smith (Sep 25)
- Re: icmp rpf Mark Kent (Sep 25)
- Re: icmp rpf Chris Adams (Sep 25)
- Re: icmp rpf william(at)elan.net (Sep 25)
- Re: icmp rpf Tony Rall (Sep 26)
- Re: icmp rpf Jared Mauch (Sep 26)
- Re: icmp rpf Bill Stewart (Sep 27)
- Re: icmp rpf Adrian Chadd (Sep 25)
- New router feature - icmp error source-interface [was: icmp rpf] Patrick W. Gilmore (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Joe Maimon (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Mark Smith (Sep 25)
- RE: New router feature - icmp error source-interface [was: icmp rpf] Berkman, Scott (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Patrick W. Gilmore (Sep 25)
- RE: New router feature - icmp error source-interface [was: icmp rpf] David Temkin (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Richard A Steenbergen (Sep 25)