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)
"Richard A. Steenbergen" wrote:
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.
No, it is guaranted to be unique only when it is never connected to the Internet. We don't have ARIN allocating private addrs, and that's half the problem: you can easily get two clowns using the same 10.0.0.x block and they will gladly whizz themselves when they start trying to chat.
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).
Or until you try to communicate with another ISP who also thinks they're at the center of the universe and is using the same block to send ICMP messages back to you. The only time you can use private addresses is when you can guarantee that those systems will not try to communicate with the rest of the Internet using those addrs. Do any of your dial-up systems use the addresses? Do any of your border routers? If any of them will ever send any messages whatsoever, they are in violation. It's really that simple. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
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 <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)
-- 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 <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)
-- Rick Allan Chief Technical Officer Vice President of Engineering Monmouth Internet Corporation http://www.monmouth.com 1-877-MONMOUTH option 6 (1-877-6666688)
On Fri, 14 Jul 2000, Rick wrote:
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).
I absolutily do not agree with this. I have never seen this behavior yet, know of no hackers who would bother, and they gain nothing from it. If they can spoof the attack effectively, they'll either do it random sourced, pick an IP out of their err head, or pick an IP they know, perhaps someone they don't like.
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
Thats utterly rediculous. A single non-connection orientied response which cannot generate more responses leaving the 1918 restricted space will have no impact on traffic levels. I'm also supprised by the number of people who live in the dream world that all networks are as small and easily filterable as theirs. Don't even attempt to complain about a backbone provider carrying 1918-sourced traffic. The only real reason to filter 1918 space is if you are afraid there will be an IP conflict between something you have numbered in your 1918 space, and the responses which could be generated by someone elses 1918 space (for example, a dest unreachable coming from someone's 1918 P-t-P sourced to something you have an IP for as well). -- 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)
On Fri, 14 Jul 2000, Richard A. Steenbergen wrote:
On Fri, 14 Jul 2000, Rick wrote:
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). I absolutily do not agree with this. I have never seen this behavior yet,
I have seen it many times I have also seen DOS attacks which consisted primarily of 127.x.x.x addresses -Dan
[ On Friday, July 14, 2000 at 23:54:11 (-0400), Richard A. Steenbergen wrote: ]
Subject: Re: RFC 1918
The only real reason to filter 1918 space is if you are afraid there will be an IP conflict between something you have numbered in your 1918 space, and the responses which could be generated by someone elses 1918 space (for example, a dest unreachable coming from someone's 1918 P-t-P sourced to something you have an IP for as well).
Though technically you're right, this kind of attitude is exactly the problem. Everyone should filter all RFC1918 usage on public links, regardless of whether they themselves use is, or their customers use it, or not. To not do such filtering is to be a bad neighbour. Of course the same "good neighbour" policy would suggest that everyone should *mutually* filter any addresses (src or dst) that are not their own or their neighbours. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (5)
-
Dan Hollis -
Eric A. Hall -
Richard A. Steenbergen -
Rick -
woods＠weird.com