Re: RFC 1918

["Richard A. Steenbergen" <ras () e-gerbil net>]

On Fri, 14 Jul 2000, Bennett Todd wrote:

> 2000-07-14-15:47:22 Steven M. Bellovin:
> > No -- 1918 addresses would only break PMTU if folks did ingress or
> > egress filtering for 1918 addresses.
>
> Wouldn't RFC 1918 addrs on router links only threaten to break
> PMTU --- even in the face of 1918 addr filtering --- if one of
> the routers with an rfc 1918 interface addr did routing between
> interfaces with different MTUs? As best I can see, PMTU discovery
> should work fine traversing RFC 1918 links, and the only addrs
> that need to be passed on out are those of routers where the MTU
> decreases along the path, which would only be routers with different
> MTUs on different interfaces.
 
I still have not seen a single compelling arguement which says you gain
one bit more security by filtering RFC1918-source'd packets. It is useless
at best, and disruptive at worst. For the longest time, the solution to
SYN floods and other random sourced attacks published on Cisco's CCO was
"filter ingress RFC1918 space". This is utterly useless. Would someone
please tell me what you really expect to gain from filtering RFC1918 space
at your borders, because its plainly obvious what you can expect to lose.

PMTU-D does not really care about WHO couldn't fragment the packet, only
that it couldn't, and the degree to which it couldn't. PMTU-D is also
acknowledged as a very bad hack which often has problems, though there are
effective methods to detect PMTU-D blackholing.

The goal of RFC1918 is to create private address space which is not
guarenteed to be unique and therefore can not be routed between ASs. It
really doesn't matter if you have a 1918-space sourced packet on your
network (any more then any other packet you might wish to filter), as long
as you don't tell others how to reach it (or let yourself be told).

In this respect, RFC1918 needs updating. There is absolutily no reason why
you cannot have 1918-space sourced packets on your network. I have found
this to be the current best operating practice of most everyone in the
modern internet, except for a few who are confused by things like
standards. :P You pay the price in unreachability (which for P-t-P links
is not necessarily a bad thing) and DNS (which for P-t-P links is quite
possibly a very bad thing for traceroute purposes), but that is the choice
the network admin makes. Except for traceroute responses, there is little
to no compelling reason why non-connection orientied responses to which
there should be no reply (ex: ICMP errors) can not be sourced from 1918
space. If you really don't like this, you should be able to source such
things from a loopback address. If you can't, pester your vendor (some
things you can do this with, some you can't, like domain-lookup
source-interface on Cisco).

IMHO.

-- 
Richard A Steenbergen <ras () e-gerbil net>   http://www.e-gerbil.net/humble
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)