|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: RFC 1918
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 <[email protected]> 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)
|