|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: RFC 1918
Richard I think you MISS two points which are at the center of this thread. First every sub-hacker (ie, those who do NOT write their own source) will usually use RFC1918 for any type of DOS attack as it is the recommended source of attack (if you do not agree with this then this thread is pointless). Second as others have pointed out the RFC1918 was created with the primary purpose to not only help limit the allocation of globally routeable IP's but also limit the amount of traffic on the Internet as a whole. By applying filters at the border routers it helps to reinforce these standards. IMHO "Richard A. Steenbergen" wrote: > 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) -- Rick Allan Chief Technical Officer Vice President of Engineering Monmouth Internet Corporation http://www.monmouth.com 1-877-MONMOUTH option 6 (1-877-6666688) "Richard A. Steenbergen" wrote: > 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) -- Rick Allan Chief Technical Officer Vice President of Engineering Monmouth Internet Corporation http://www.monmouth.com 1-877-MONMOUTH option 6 (1-877-6666688)
|