-----BEGIN PGP SIGNED MESSAGE----- Hi all, <rant> If were reading this list on a professional basis, we should be a little clued, or at least attempting to get there. We're in the big leagues now, read up on CIDR, figure out classless subnetting. To advocate breaking legitimate routing because we, as an industry, don't want to put in the time and effort to educate our end users is just a little lame. </rant> Had to get that off my chest. Anyway, it's been said here several times before, but I'll say it again. To end the smurf type exploits, we need to do 2 things. 1. Routers/Gateways should be configured to prevent the transmission of echo-request packets, out an interface, to a destination address identical to the broadcast address of that interface, except in those cases where specifically required. This means getting vendors to give us a knob, and having it default to off. This is the easy one folks, figuring out net-masks aren't that hard. The transit providers might have problems with implementing this due to hardware meltdown, but that's not where it needs to be implemented. !!Educate your (our) users!! 2. Routers/Gateways should be configured to drop all packets with invalid source addresses. This is a little bit more difficult, particularly if your multi-homed, but again, it's not the transit providers that are need to implement this, its the end user. once more !!Educate your (our) users!! No. 2 has the benefit of fixing all manner of ills. The problem is us. This isn't a research network run and maintained by the knowledgable. This is a business. We're selling a product, and if we expect it to operate as advertised, it's up to us to educate those we sell it to. This is Mr. Pot, saying so long to all you kettles out there. - -- Rusty Zickefoose | The most exciting phrase to hear in science, rusty@mci.net | the one that heralds new discoveries, is not | "Eureka!", but "That's funny ..." | -- Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNUDlvu4+ch/bGDylAQGktAQAolKXogM3Gyr/Wp/AE1h6jZo6QQOTtOIU ZkFUI+Dk7tKCoc6BPZ4VrsiPF1zslnQoIWwdceubl7kK+GwIyH4CTWtAyXGP+wr3 6EHKiYfZ19P/Wvhi0Cjxo2buxYgpLCEHeKR4GUKwnJI66HlInemlUp4zDpMQFy8R mNIdSK/Pw1k= =/Dxy -----END PGP SIGNATURE-----
On Fri, Apr 24, 1998 at 03:19:23PM -0400, Rusty Zickefoose wrote:
2. Routers/Gateways should be configured to drop all packets with invalid source addresses.
The problem is us. This isn't a research network run and maintained by the knowledgable. This is a business. We're selling a product, and if we expect it to operate as advertised, it's up to us to educate those we sell it to.
The problem isn't us. It's cicso, and Bay, and Ascend, and... everyone who won't put an anti-forging filter on their border routers so we _can_ turn it on. The first time someone co-sues cisco, it'll get fixed with 30 days. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
At 5:03 PM -0400 4/24/98, Jay R. Ashworth wrote:
The problem is us. This isn't a research network run and maintained by the knowledgable. This is a business. We're selling a product, and if we expect it to operate as advertised, it's up to us to educate those we sell it to.
The problem isn't us. It's cicso, and Bay, and Ascend, and... everyone who won't put an anti-forging filter on their border routers so we _can_ turn it on. The first time someone co-sues cisco, it'll get fixed with 30 days.
They put the software in. "We" just won't turn them on. We have seen the enemy and they is us. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Fri, Apr 24, 1998 at 05:51:06PM -0400, Dean Anderson wrote:
At 5:03 PM -0400 4/24/98, Jay R. Ashworth wrote:
The problem is us. This isn't a research network run and maintained by the knowledgable. This is a business. We're selling a product, and if we expect it to operate as advertised, it's up to us to educate those we sell it to.
The problem isn't us. It's cicso, and Bay, and Ascend, and... everyone who won't put an anti-forging filter on their border routers so we _can_ turn it on. The first time someone co-sues cisco, it'll get fixed with 30 days.
They put the software in. "We" just won't turn them on. We have seen the enemy and they is us.
Off-line survey: if you operate a border router or dialup access server (Livingston, Ascend, USR TC, etc), please mail me directly and tell me 1) whether your device has a know to llow you to drop incoming packets with forged source addreses, 2) what it defaults to, and 3) how well it's called out in the documentation. Please include specific model numbers, and software release numbers if possible. Do _not_ reply to the list; I'll summarize. It's been my understanding that the knobs are in fact _not_ there, Dean, but I'd be happy to be proven wrong. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
At 5:53 PM -0400 4/24/98, Jay R. Ashworth wrote:
It's been my understanding that the knobs are in fact _not_ there, Dean, but I'd be happy to be proven wrong.
There isn't a simple knob, but then it isn't simple to know what a forgery is. You to have tell the router. The router doesn't know what you and other people "own", but you can tell it. I'd say there isn't a way to make a simple on/off knob for that, because there isn't any way to tell who you will transit for and who you won't. On your outbound interface(s): access-list 101 permit ip <yournet-1> any out access-list 101 permit ip <yournet-2> any out ... access-list 101 deny ip any any out This allows only packets sourced from your networks to be sent. Or, another perhaps better way is to only accept packets from your customer networks which are sourced from those networks. Each customer interface then has an inbound filter the blocks everything not sourced from your customers network. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Fri, Apr 24, 1998 at 06:39:28PM -0400, Dean Anderson wrote:
Dean, but I'd be happy to be proven wrong.
There isn't a simple knob, but then it isn't simple to know what a forgery is. You to have tell the router. The router doesn't know what you and other people "own", but you can tell it. I'd say there isn't a way to make a simple on/off knob for that, because there isn't any way to tell who you will transit for and who you won't.
Or, another perhaps better way is to only accept packets from your customer networks which are sourced from those networks. Each customer interface then has an inbound filter the blocks everything not sourced from your customers network.
That was the idea. I was, as noted, mostly talking about router interfaces with only one network (block) behind it. I gather a large part of it comes from dialups, where the remote network is a /32. in any event, I'm not sure I made the query explicit enough, from a couple of replies I got: the knob I'm specifically interested in says "don't forward packets with source addresses that can't be routed back out this port". Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Fri, Apr 24, 1998 at 06:39:28PM -0400, Dean Anderson wrote:
At 5:53 PM -0400 4/24/98, Jay R. Ashworth wrote:
It's been my understanding that the knobs are in fact _not_ there, Dean, but I'd be happy to be proven wrong.
There isn't a simple knob, but then it isn't simple to know what a forgery is. You to have tell the router. The router doesn't know what you and other people "own", but you can tell it. I'd say there isn't a way to make a simple on/off knob for that, because there isn't any way to tell who you will transit for and who you won't.
On your outbound interface(s):
access-list 101 permit ip <yournet-1> any out access-list 101 permit ip <yournet-2> any out ... access-list 101 deny ip any any out
This allows only packets sourced from your networks to be sent.
Or, another perhaps better way is to only accept packets from your customer networks which are sourced from those networks. Each customer interface then has an inbound filter the blocks everything not sourced from your customers network.
--Dean
Well, there is a simple knob for this: If the Knob is turned "ON", then any packet from a source address which is not routed to the interface it came in on is dropped. This works for static, dynamic, and all other kinds of routing. It will solve the problem and is trivial to implement - if any of the vendors care. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
On Fri, Apr 24, 1998 at 05:59:29PM -0500, Karl Denninger wrote:
Well, there is a simple knob for this: If the Knob is turned "ON", then any packet from a source address which is not routed to the interface it came in on is dropped. This works for static, dynamic, and all other kinds of routing. It will solve the problem and is trivial to implement - if any of the vendors care.
Thanks, Karl. Precisely the precis I was looking for. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Fri, 24 Apr 1998, Karl Denninger wrote:
Well, there is a simple knob for this:
If the Knob is turned "ON", then any packet from a source address which is not routed to the interface it came in on is dropped.
This works for static, dynamic, and all other kinds of routing. It will solve the problem and is trivial to implement - if any of the vendors care.
It doesn't work for asymmetric routing as you describe it above. If you modify your criteria to be that there are no valid routes out that interface, you would only break transient routing conditions, but depending on how the router stores routes it may not be possible (or desirable due to memory requirements) to implement. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
On Fri, Apr 24, 1998 at 06:06:50PM -0500, John A. Tamplin wrote:
On Fri, 24 Apr 1998, Karl Denninger wrote:
Well, there is a simple knob for this: If the Knob is turned "ON", then any packet from a source address which is not routed to the interface it came in on is dropped. This works for static, dynamic, and all other kinds of routing. It will solve the problem and is trivial to implement - if any of the vendors care.
It doesn't work for asymmetric routing as you describe it above. If you modify your criteria to be that there are no valid routes out that interface, you would only break transient routing conditions, but depending on how the router stores routes it may not be possible (or desirable due to memory requirements) to implement.
Yeah, John, we know that. But I've rarely seen a /32 with asymmetric routing. The vast majority (I speculate) of these problems happen on the far side of border routers which are unlikely to be participating in ASR, are they not? How far down is it being used? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Fri, Apr 24, 1998 at 06:06:50PM -0500, John A. Tamplin wrote:
On Fri, 24 Apr 1998, Karl Denninger wrote:
Well, there is a simple knob for this:
If the Knob is turned "ON", then any packet from a source address which is not routed to the interface it came in on is dropped.
This works for static, dynamic, and all other kinds of routing. It will solve the problem and is trivial to implement - if any of the vendors care.
It doesn't work for asymmetric routing as you describe it above. If you modify your criteria to be that there are no valid routes out that interface, you would only break transient routing conditions, but depending on how the router stores routes it may not be possible (or desirable due to memory requirements) to implement.
John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
Balderdash. That a route is *valid* doesn't mean its the best path or the one that the router will use. It means that the path is *valid*. You're confusing "valid" with "best". Besides, the issue here isn't transport level circuits (where such things matter); it is end-customer attachments, which are typically not multihomed and even if they are, they're also typically static routed. Someone running BGP4 with you isn't going to have this enabled on either end of that interface. I don't expect this to be usable on a backbone circuit. Then again, that's not where the problems are originating. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
That a route is *valid* doesn't mean its the best path or the one that the router will use. It means that the path is *valid*. You're confusing "valid" with "best".
Balderdash. :-) "Strict" asymmetry, exemplified in the Hughes DirecPC satellite service which provides no dialin pool of its own, as well as in some telco return cable modem setups, means that all downstream traffic will take one path and all upstream traffic the other. For that to happen, the *only* paths which can exist are those pointing to the downstream path. This can be addressed with not-real-soon-now technology or it can be ignored as a special case that's somebody else's problem, but when a customer is paying our full rates yet moving the vast majority of his traffic through somebody else, I would prefer to keep that customer happy. regards, -- Robert
Well, there is a simple knob for this:
If the Knob is turned "ON", then any packet from a source address which is not routed to the interface it came in on is dropped.
This works for static, dynamic, and all other kinds of routing. It will solve the problem and is trivial to implement - if any of the vendors care.
Doesn't work for asymetric networks, like satellites. But I agree, it might be a good knob for the 80% solution. The rest of the problems must still rely on access lists. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Fri, Apr 24, 1998 at 06:39:28PM -0400, Dean Anderson wrote:
At 5:53 PM -0400 4/24/98, Jay R. Ashworth wrote:
It's been my understanding that the knobs are in fact _not_ there, Dean, but I'd be happy to be proven wrong.
On your outbound interface(s):
access-list 101 permit ip <yournet-1> any out access-list 101 permit ip <yournet-2> any out ... access-list 101 deny ip any any out
This allows only packets sourced from your networks to be sent.
Or, another perhaps better way is to only accept packets from your customer networks which are sourced from those networks. Each customer interface then has an inbound filter the blocks everything not sourced from your customers network.
--Dean
And conversely, ..: acce 102 deny ip <yournet> any acce 102 perm ip any any in s0 ip access-g 102 in -- Christopher M Neill -- Network Operations QualNet - We Make the Internet Work for Your Business.(sm) DID: 216-902-5460, Office: 800-466-0088, Fax: 216-623-3566 http://www.qual.net
There isn't a simple knob, but then it isn't simple to know what a forgery is. You to have tell the router.
That's what routing protocols are for, right? :-) I thought I had read on cisco-nsp that 11.1CC implemented the long-discussed feature of not accepting packets from an interface unless the router held a route for the source address of that packet back out that interface, but I can't find that message now. I wonder what that does to forwarding rates on VIP2s and 12000s.
Or, another perhaps better way is to only accept packets from your customer networks which are sourced from those networks. Each customer interface then has an inbound filter the blocks everything not sourced from your customers network.
As I told Jay, we have modified our RADIUS server to do exactly this on the fly for 3com NETservers, 3com HiPer ARCs, and Bay 5399/8000s (and probably any other Annexish box with RADIUS support). This is great until you accept routing information from one of your downstreams. One might argue that you shouldn't peer (or listen to RIP or OSPF) from a network that'll carry spoofed packets, but I don't think that's practicable for the Internet of today. Not all the equipment is capable, not all the operators are clueful, and there aren't enough incentives to change that overnight. I won't even touch the issue of "legitimate spoofing" which rears its ugly head in the telco return satellite and cable modem scenarios. Strict asymmetry does make things more complicated. regards, -- Robert
Dean Anderson writes...
There isn't a simple knob, but then it isn't simple to know what a forgery is. You to have tell the router. The router doesn't know what you and other people "own", but you can tell it. I'd say there isn't a way to make a simple on/off knob for that, because there isn't any way to tell who you will transit for and who you won't.
[access list example not included] It could be simple knob, and I believe it is simple to know what a forgery is. If the source address, when treated as a destination and used to look up the routing entries (all of them), indicates a return path scope that includes the actual interface or interface:gateway that the packet did arrive from, then it is most likely not a forgery, whereas if the arrival interface or interface:gateway is not in the list, it most likely is a forgery. While this might break some extreme cases of asymmetric routing, it does appear to me to be sufficiently able to filter enough source forgeries as to seriously discourge the practice. Unlike access lists, this would be very easy to configure. Unlike access lists, it could default to enabled, which I think it should be. Its costs in CPU time (mostly the route lookup) could be made up for to some degree be not having to have so many access list entries to accomplish the same effect. And you won't have to go update all your configurations when a new network block is acquired, or a customer comes online with portable address space or dual-homes (a serious situation for backbone providers). -- Phil Howard | die0spam@spammer1.net no3way64@no6place.edu suck4it4@dumb3ads.net phil | stop2ads@spammer8.net no00ads0@spammer0.edu eat20me0@dumb5ads.org at | no28ads4@noplace3.edu die6spam@spam3mer.edu eat4this@no7where.com ipal | blow1me7@dumbads3.com eat4this@anyplace.edu ads8suck@spam8mer.com dot | eat0this@no7place.org blow7me6@spammer1.org blow6me3@nowhere3.edu com | ads1suck@no5where.com a1b3c3d2@anyplace.edu no0way56@no2place.org
99% of the people know that but how do you propose to relay that message to every NOC on the Internet. THAT is the problem. On Fri, 24 Apr 1998, Rusty Zickefoose wrote: :-----BEGIN PGP SIGNED MESSAGE----- : :Hi all, : :<rant> : If were reading this list on a professional basis, we should be a :little clued, or at least attempting to get there. We're in the big :leagues now, read up on CIDR, figure out classless subnetting. To :advocate breaking legitimate routing because we, as an industry, don't want :to put in the time and effort to educate our end users is just a little :lame. :</rant> : : Had to get that off my chest. : : Anyway, it's been said here several times before, but I'll say it :again. : : To end the smurf type exploits, we need to do 2 things. : :1. Routers/Gateways should be configured to prevent the transmission of :echo-request packets, out an interface, to a destination address identical :to the broadcast address of that interface, except in those cases where :specifically required. : : This means getting vendors to give us a knob, and having it :default to off. : :This is the easy one folks, figuring out net-masks aren't that hard. The :transit providers might have problems with implementing this due to :hardware meltdown, but that's not where it needs to be implemented. : : !!Educate your (our) users!! : : :2. Routers/Gateways should be configured to drop all packets with :invalid source addresses. : : This is a little bit more difficult, particularly if your :multi-homed, but again, it's not the transit providers that are need to :implement this, its the end user. : : once more : : !!Educate your (our) users!! : :No. 2 has the benefit of fixing all manner of ills. : :The problem is us. This isn't a research network run and maintained by :the knowledgable. This is a business. We're selling a product, and if we :expect it to operate as advertised, it's up to us to educate those we sell :it to. : : :This is Mr. Pot, saying so long to all you kettles out there. : :- -- :Rusty Zickefoose | The most exciting phrase to hear in science, :rusty@mci.net | the one that heralds new discoveries, is not : | "Eureka!", but "That's funny ..." : | -- Isaac Asimov : :-----BEGIN PGP SIGNATURE----- :Version: 2.6.2 : :iQCVAwUBNUDlvu4+ch/bGDylAQGktAQAolKXogM3Gyr/Wp/AE1h6jZo6QQOTtOIU :ZkFUI+Dk7tKCoc6BPZ4VrsiPF1zslnQoIWwdceubl7kK+GwIyH4CTWtAyXGP+wr3 :6EHKiYfZ19P/Wvhi0Cjxo2buxYgpLCEHeKR4GUKwnJI66HlInemlUp4zDpMQFy8R :mNIdSK/Pw1k= :=/Dxy :-----END PGP SIGNATURE----- : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
participants (9)
-
Christopher Neill -
Dean Anderson -
Jason Lixfeld -
Jay R. Ashworth -
John A. Tamplin -
Karl Denninger -
Phil Howard -
Robert Sanders -
Rusty Zickefoose