[ 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 failure
happens leaving big.net with an incomplete routing table, thus
breaking
traceroute 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