- Test - lists.nanog.org

RE: DDOS attacks and Large ISPs doing NAT?
by Mansey, Jon 02 May '02

02 May '02

To merge these 2 great threads, it is the case is it not that NAT is a great way to avoid DDOS problems. I don't even want to imagine what the billing/credit issues would be like if your always-on phone with a real IP is used as a zombie in a DDOS. "Hey I didn't use all that traffic last month....etc etc" I still maintain, since the last time this was on Nanog, that real IP addresses should not be entrusted to the great unwashed. And as for NAT breaking applications, I think its time the applications wised up and worked around the NAT issues. Look, if your application is important enough to you as the developer, you are going to want it to penetrate and work for as many ppl as possible right? Office workers, home users with gateways, GPRS/GSM/3G cell users etc etc. So you make it use protocols that traverse NAT without breaking. Look at the streaming media players out there, they try to use, in order, multicast (the most effcient and best quality), UDP,TCP then HTTP. If it cant get a connection with any of the first protocols, it falls back to http, and you get your stream. When you look at the economics of usability of your app, I think your going to want to make it work through firewalls. Jm > -----Original Message----- > From: Jake Khuon [mailto:khuon@NEEBU.Net] > Sent: Thursday, May 02, 2002 1:51 AM > To: nanog(a)merit.edu > Subject: Re: Large ISPs doing NAT? > > > > ### On Thu, 2 May 2002 10:42:01 +0200, "Daniska Tomas" > <tomas(a)tronet.com> ### casually decided to expound upon > <nanog(a)merit.edu> the following ### thoughts about "RE: Large > ISPs doing NAT? ": > > DT> and what if one of the devices behind that phone would also be a > DT> personal "ip gateway router" (or how you call that)... you could > DT> recursively iterate as deep as your mail size allows you to... > > It's possible. Could it get ugly? Yes. Do we just want to > shut our eyes and say "let's not go there."... well... maybe. > I just don't think the solution is to say, "this can never > happen... we must limit all handheld devices to sitting > behind a NAT gateway." > > > DT> hope this thread will not end in a router behind a router that > DT> serves as a router seving as a router to another router which has > DT> some other routers connected... > > God forbid! We might have a network on our hands! > > > -- > /*===================[ Jake Khuon <khuon(a)NEEBU.Net> > ]======================+ > | Packet Plumber, Network Engineers /| / [~ [~ |) | | > --------------- | > | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N > E T W O R K S | > +============================================================= > ============*/ >

4 3

RE: Effective ways to deal with DDoS attacks?
by LeBlanc, Jason 02 May '02

02 May '02

Try a compiled ACL on a 3 port gigE for some fun. -----Original Message----- From: Christopher L. Morrow [mailto:chris@UU.NET] Sent: Thursday, May 02, 2002 9:48 AM To: Vincent Gillet Cc: Christopher L. Morrow; measl(a)mfn.org; Pete Kruckenberg; nanog(a)merit.edu Subject: Re: Effective ways to deal with DDoS attacks? On Thu, 2 May 2002, Vincent Gillet wrote: > chris(a)UU.NET disait : > > > > have been on the receiving end of, the first was generating a little over > > > 300mbit/sec (steady for a prolonged time), and the second went over that by a > > > fair bit. In both cases, we had core equipment (M20's and BSN5000's) fall > > > over and die trying to "work" the events. Additionally, our upstream peers > > > > Your M20 tipped over?? What were you doing? We regularly stop large > > (+100Mb->800Mb) attacks with less horsepower than this. Truthfully, a > > cisco is even capable of filtering (done right) at +200kpps... > > On Cisco boxes, it depends too much on Interface type, LC Engine, IOS, ... > etc ... In this you have my whole-hearted agreement :( But, this goes back to 'know you systems, know their boundaries'. All of the people that work here (on our team) know what you can and can't do, we are effective in our jobs because of this. Sure your random NOC worker or even level3/4 NOC worker isn't going to know all the ins and outs of security thingy's on your backbone equipemt, that's why you pay 5-7 people to learn it :) > > Beside, some features cannot run concurently (i remumber an ACL on GSR > that make my netflow export stop .... it tooks days to figure this out !!!) > Ha! :) try acl's on engine-2 cards with sub-interfaces! (like the triton gig card... cause no one would ever sub-interface a gig interface, right?) > ACL Implement on GSR is too a nightmare. > We are operating more than 70 GSRs with very different interface, LC engine and IOS ... > Just 70? your live is easy then :) Really though, this is, in my opinion, the larges problem Cisco has to over come. They need to have the 'luxury' that Juniper has: One IOS, One implementation of commands, same commands everywhere... consistency I believe its called. Its not, obviously, going to happen overnight, but to their credit folks at cisco ARE working to make the security problem less of a problem. If you are having trouble getting your sales folk from cisco to listen/understand/pass-along-input you can look for their 'ISP Group' which I'm sure Barry Greene will be happy to properly name and provide contacts for, or perhaps they are in the sites he posted here before?

2 1

RE: Global view increase (was:BGP route explosion)
by James Spenceley 02 May '02

02 May '02

Around 15mins ago an additional ~5,000 routes entered the global view, sadly they appear to be hanging around. Last Tuesday had an increase of 2,000 routes. +7000 routes in a week is significant de-aggregation or leak, any ideas on where these routes are flowing ? I've not seen an increase on any of our peers, so I can only assume its coming from a network who doesn't peer particularly "openly". -- James

4 4

Re: Global view increase (was:BGP route explosion)
by David G. Andersen 02 May '02

02 May '02

On Thu, May 02, 2002 at 12:55:45PM -0500, Gerardo Gregory mooed: > <SNIP> > > http://ginseng/bgpview.cgi?time=between&start=2002-05-01+06%3A00%3A00&end=20 > 02-05-01+07%3A00%3A00&bins=100&prefix=&rel=eq&aspath=&asrel=contain&origin_a > s=17676&scale=linear&table=updates_new&action=plot&View=View > > <END SNIP> > > URL Seems unreachable (might be because there was a top level domain omitted > from the URL?) Sorry, not enough sleep last night. Here's the corrected URL, with the added bonus of stripping out some of the unnecessary goo: http://ginseng.lcs.mit.edu/bgpview.cgi?time=between&start=2002-05-01+06%3A0… -Dave -- work: dga(a)lcs.mit.edu me: dga(a)pobox.com MIT Laboratory for Computer Science http://www.angio.net/

1 0

RE: DDOS attacks and Large ISPs doing NAT?
by Daniska Tomas 02 May '02

02 May '02

jon, 1000x ack and for all: i think this MOTD is something very close to the isp nat thread :) "There are only 10 types of people in this world: those who understand binary, and those who don't." (Credits to Theodore Tzevelekis/Cisco) deejay -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -----Original Message----- > From: Mansey, Jon [mailto:Jon_Mansey@verestar.com] > Sent: 2. mája 2002 19:31 > To: nanog(a)merit.edu > Subject: RE: DDOS attacks and Large ISPs doing NAT? > > > > To merge these 2 great threads, it is the case is it not that > NAT is a great way to avoid DDOS problems. I don't even want > to imagine what the billing/credit issues would be like if > your always-on phone with a real IP is used as a zombie in a > DDOS. "Hey I didn't use all that traffic last month....etc etc" > > I still maintain, since the last time this was on Nanog, that > real IP addresses should not be entrusted to the great unwashed. > > And as for NAT breaking applications, I think its time the > applications wised up and worked around the NAT issues. Look, > if your application is important enough to you as the > developer, you are going to want it to penetrate and work for > as many ppl as possible right? Office workers, home users > with gateways, GPRS/GSM/3G cell users etc etc. So you make it > use protocols that traverse NAT without breaking. Look at the > streaming media players out there, they try to use, in order, > multicast (the most effcient and best quality), UDP,TCP then > HTTP. If it cant get a connection with any of the first > protocols, it falls back to http, and you get your stream. > > When you look at the economics of usability of your app, I > think your going to want to make it work through firewalls. > > Jm

1 0

RE: Effective ways to deal with DDoS attacks?
by LeBlanc, Jason 02 May '02

02 May '02

I'm with Richard. Often the attacker is stupid enough to have something in the header that doesn't change that you can filter on. Looking at the payload would be a tough job with the size of some of these attacks. -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Thursday, May 02, 2002 10:19 AM To: Hank Nussbacher Cc: LeBlanc, Jason; 'Pete Kruckenberg'; nanog(a)merit.edu Subject: Re: Effective ways to deal with DDoS attacks? On Thu, May 02, 2002 at 08:07:31PM +0200, Hank Nussbacher wrote: > > At 12:23 PM 02-05-02 -0400, Richard A Steenbergen wrote: > > >Thats what the IP2 does, match bytes in the headers and come back with a > >thumbs down or a thumbs up and a destination interface. It's really not > >that much harder to match the bytes for a dest port against a compiled > >ruleset and decide yes or no then it is to match the dest address against > >a forwarding table and decide which nexthop. > > Looking into the IP header is not enough. In order to filter DDOS packets > one has to look into the payload as well. I don't think routers are > suitable for that level of filtering (think advanced NBAR). I disagree. There are a world of things you can do when you look at the entire payload, from IDS to playing Big Brother. But stopping DDoS does not require it, in almost every case layer 3+4 headers is sufficient. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

as 22934
by Scott Granados 02 May '02

02 May '02

Just a note. I've been getting telephone calls on my home number concerning route flapping and other issues originating from as 22934 <Ebroadbandnow>. Just wanted to pass on that I no longer work there or have any contacts in the company. I'd suggest noc(a)ebroadbandnow.com or peering(a)ebroadbandnow.com but it appears their web, mail and dns servers are off line and have been now for almost a month. I don't have any valid telephone numbers to refer people to but I'm no longer able to effect changes or even contact anyone there. Thanks. Scott

1 0

RE: Effective ways to deal with DDoS attacks?
by LeBlanc, Jason 02 May '02

02 May '02

It (rpf) can't stop a DoS, but it does cut down on some of the spoofed packets, any reduction in the number of packets hitting whatever has to filter or deal with the attack packets helps. I don't have the stats in front of me, but our findings were than urpf would cut enough out to be worthwhile. -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Thursday, May 02, 2002 9:58 AM To: LeBlanc, Jason Cc: nanog(a)merit.edu Subject: RE: Effective ways to deal with DDoS attacks? If you just filter out anything that's not in the routing table, that's about half the address space and it only works if the spoofers are stupid. When you're looking at pure bandwidth that's still helpful, but it doesn't really solve anything. However, You can use unicast RPF as a very efficient source address filter, by routing addresses to the null interface. This way you can get rid of huge amounts of unwanted sources in a very clean way. As long as we're asking for features: what I would like is a unicast RPF check that allows everything that isn't routed to the null interface. And of course unicast RPF period for all vendors who aren't Cisco.

1 0

RE: Large ISPs doing NAT?
by Daniska Tomas 02 May '02

02 May '02

> -----Original Message----- > From: Jake Khuon [mailto:khuon@NEEBU.Net] > Sent: 2. mája 2002 10:32 > To: nanog(a)merit.edu > Subject: Re: Large ISPs doing NAT? > > > > > Time to start thinking a little further down the line. What > if the phone actually becomes an wireless IP gateway router? > It routes packets from a PAN (personal area network) riding > on top of Bluetooth or 802.11{a,b} to the 3G network for > transit. NAT would certainly become very messy. > greeeeat and what if one of the devices behind that phone would also be a personal "ip gateway router" (or how you call that)... you could recursively iterate as deep as your mail size allows you to... hope this thread will not end in a router behind a router that serves as a router seving as a router to another router which has some other routers connected... > > -- > /*===================[ Jake Khuon <khuon(a)NEEBU.Net> > ]======================+ > | Packet Plumber, Network Engineers /| / [~ [~ |) | | > --------------- | > | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N > E T W O R K S | > +============================================================= > ============*/ > -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.

3 2

Joint NANOG/ARIN Meetings
by Susan Harris 02 May '02

02 May '02

Hi everyone - NANOG and ARIN are pleased to announce our first joint meetings, to be held October 27-November 1 in Eugene, Oregon. Our host will be the University of Oregon. NANOG will meet as usual from Sunday - Tuesday, and ARIN from Wednesday - Friday. We hope you'll plan on staying the whole week - it's a great opportunity for operators to participate in ARIN policy discussions.

1 0