means that packets with source addresses from RFC 1918 space should not be permitted on the global internet. While I agree that RFC 1918 addresses should not be used on internet visible interfaces, I'm unaware of anywhere in the RFC's where it says that "routers should be configured to reject packets coming from RFC 1918 space."
As others have pointed out, there are indeed RFC sections which seem to imply that packets coming from RFC 1918 space should not be visible on the global Internet. Furthermore, whether the RFC says so or not, I'm going to block these packets at *my* border routers, because: - I have absolutely *no* idea of where these packets might be coming from, - and I have no possibility of generating sensible replies to packets with RFC 1918 source addresses. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Furthermore, whether the RFC [1918] says so or not, I'm going to block
these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address filtering on all packets in the context of cost-benfit analysis. Regards, John Leong -- --------------------------------------------------------- Bell Labs Research johnleong@research.bell-labs.com 4995 Patrick Henry Dr. Tel: 408-567-4459 Santa Clara, CA 95054 Fax: 408-567-4448
John Leong wrote:
Furthermore, whether the RFC [1918] says so or not, I'm going to block
these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address filtering on all packets in the context of cost-benfit analysis.
The cost is dependent on the quality of the filtering implementation of your routers. It's quite possible to implement source address filtering as a part of ASIC-assisted routing, resulting in wire-speed filtering. Whether any given vendor has or has not implemented their equipment to allow wire speed filtering is something you might want to ask salesmen. As it's something which network providers should be doing, its a capability that should be demanded of the hardware vendors. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
Furthermore, whether the RFC [1918] says so or not, I'm going to block these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address filtering on all packets in the context of cost-benfit analysis.
The cost is dependent on the quality of the filtering implementation of your routers. It's quite possible to implement source address filtering as a part of ASIC-assisted routing, resulting in wire-speed filtering. Whether any given vendor has or has not implemented their equipment to allow wire speed filtering is something you might want to ask salesmen.
As it's something which network providers should be doing, its a capability that should be demanded of the hardware vendors.
-- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
Well, that will eventually get somebody into trouble. Long ago & far away, Dave Mills greated a list of "forbidden" network prefixes in the fuzzball routers. The Martian list consisted of the "zero & all-ones" /24 networks at the edges of the old classfull boundaries. Many router vendors hardcoded those as well. Ate my lunch a few years ago w/ ciscos. It seems to be fixed (again) in the latest 12.0 codebase. Tossing six /24s is one thing. Tossing twohundred seventy /16s is something else again... --bill
Furthermore, whether the RFC [1918] says so or not, I'm going to block these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address filtering on all packets in the context of cost-benfit analysis.
on a router that's not doing filtering, it's going to be a small hit. i'm going to infer, however, that any router that's not doing filtering is probably not doing much traffic. and any router that is doing a lot of traffic, is already doing filtering. so it's less of a hit. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
on a router that's not doing filtering, it's going to be a small hit. i'm going to infer, however, that any router that's not doing filtering is probably not doing much traffic. and any router that is doing a lot of traffic, is already doing filtering. so it's less of a hit.
huh? for packet filtering, which is what we've been discussing, my experience is quite the opposite. one can't really afford packet filters on routers with oc12s. and in a multi-path universe, filtering for source address spoofing is best done at the edges anyway. randy
On Fri, 23 Apr 1999, Randy Bush wrote:
huh? for packet filtering, which is what we've been discussing, my experience is quite the opposite. one can't really afford packet filters on routers with oc12s. and in a multi-path universe, filtering for source address spoofing is best done at the edges anyway.
Wonder if its too much to ask the backbones to do sanity checks on their customers T1 lines etc. Eg they arent smurf amplifiers, they have spoof filters, yadda yadda. If this happened perhaps the rate of DoS attacks would go down -Dan
[ On Friday, April 23, 1999 at 16:15:30 (-0700), John Leong wrote: ]
Subject: Re: address spoofing
Furthermore, whether the RFC [1918] says so or not, I'm going to block these packets at *my* border routers, because:
Curious as to the cost (added latency) in doing RFC 1918 source address filtering on all packets in the context of cost-benfit analysis.
Well, there's no question as to the benefit if you actually use any of those networks internally -- I for one never want to see a packet on a public interface that appears to have come from one of my management networks, and conversely I'm going to be extremely careful not to let packets slip out from my management networks onto a public network, especially in the case of internal misconfigurations. It seems to me that if you're going to filter for one or two of your own internal management networks then there's zero added cost to simply increase the prefix to match the entire larger RFC 1918 group since your private management networks are obviously going to be a part of *some* RFC 1918 prefix, right! It also seems that if you're going to filter for one prefix then you probably won't lose much additional latency or router cycles if filter the whole works, not to mention that you'll have additional piece of mind in knowing that if someone internally starts using one of the other RFC 1918 prefixes, or the test net, or whatever, you'll still be protecting them too. In fact I run filters on each server, with separate physical interfaces for public and internal "management" traffic; as well as on the routers with interfaces on the border in order to protect things even if some wire gets plugged into the wrong port. Such configurations are far less forgiving of sloppy configuration, of course, but that's the idea. -- 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 (8)
-
Andrew Brown -
bmanning＠vacation.karoshi.com -
Dan Hollis -
Daniel Senie -
John Leong -
Randy Bush -
sthaug＠nethelp.no -
woods＠most.weird.com