- Test - lists.nanog.org

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

03 May '02

That would come under the heading of a virus or trojan I believe. And sure there is no reason a NAT'd cell phone couldnt participate in this type of attack. The DDOS discussion is specifically referring to a "live" syn or syn/ack attack from hosts that respond to connection requests. A NAT'd cell phone wont, cant ever, respond to an unsolicited connection request. jm > -----Original Message----- > From: Gary E. Miller [mailto:gem@rellim.com] > Sent: Thursday, May 02, 2002 11:00 AM > To: Mansey, Jon > Cc: nanog(a)merit.edu > Subject: RE: DDOS attacks and Large ISPs doing NAT? > > > Yo Jon! > > On Thu, 2 May 2002, Mansey, Jon wrote: > > > 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" > > Who says a NATed host can not be a zombie? Get the NATed > host to read an email virus. The virus then coonects to an > IRC channel that tells the zombie when to spew. > > Each phone would not spew much, but imagine you got 100M > phones to do your DDoS for you... > > RGDS > GARY > -------------------------------------------------------------- > ------------- > Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 > gem(a)rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 > >

6 5

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

03 May '02

do you think fufme (http://www.fu-fme.com/) would work well over nat? :)))) -- 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: Scott Francis [mailto:darkuncle@darkuncle.net] > Sent: 3. mája 2002 9:13 > To: Dan Hollis > Cc: nanog(a)merit.edu > Subject: Re: Large ISPs doing NAT? > > > On Thu, May 02, 2002 at 04:56:40PM -0700, goemon(a)anime.net > said: [snip] > > > I'm not buying a phone I can't run ssh from. End of story. My > > > current phone > > > does all that and more. Why step back into the dark ages > of analog-type > > > services? > > > > The average customer doesn't even know what telnet is, let > alone ssh. > > All they care about is browsing pr0n. > > Your phone can surf porn? Maybe the technology revolution has > finally arrived after all ... > > > -Dan > > -- > > [-] Omae no subete no kichi wa ore no mono da. [-] > > -- > Scott Francis darkuncle@ [home:] d a r k u > n c l e . n e t > Systems/Network Manager sfrancis@ [work:] t > o n o s . c o m > GPG public key 0xCB33CCA7 illum oportet crescere > me autem minui >

1 0

RE: Large ISPs doing NAT?
by Mansey, Jon 03 May '02

03 May '02

Why do you need a public IP to do ssh? jm > -----Original Message----- > From: Simon Higgs [mailto:simon@higgs.com] > Sent: Thursday, May 02, 2002 4:44 PM > To: Scott Francis > Cc: Peter Bierman; nanog(a)merit.edu > Subject: Re: Large ISPs doing NAT? > > > > At 01:20 AM 5/2/2002 -0700, Scott Francis wrote: > > >The average customer buying a "web-enabled" phone doesn't need a > >publicly-routeable IP. I challenge anybody to demonstrate why a cell > >phone needs a public IP. It's a PHONE, not a server. > > I'm not buying a phone I can't run ssh from. End of story. My > current phone > does all that and more. Why step back into the dark ages of > analog-type > services? > > > > Best Regards, > > Simon > > -- > ### >

2 1

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

02 May '02

> -----Original Message----- > From: Tony Rall [mailto:trall@almaden.ibm.com] > Sent: 30. apríla 2002 19:59 > To: nanog(a)merit.edu > Subject: Re: Large ISPs doing NAT? > > > > > On Monday, 2002-04-29 at 08:43 MST, Beckmeyer > <beck(a)pacbell.net> wrote: > > Is anybody here doing NAT for their customers? > > I hope not. > > If you're NATing your customers you're no longer an ISP. > You're a sort-of-tcp-service-provider (maybe a little udp > too). NAT (PAT even more > so) breaks so many things that it would be unconscionable to > advertise as an ISP. Even some tcp apps fail under NAT. The > NAT box may include a number of "fix-ups" but such will never > be equivalent to giving the customer a public address. well.. yes and no. depends on definition and how you set the services. i don't know how you treat this in u.s. but in europe gprs is mostly considered being a value-added service to gsm instead of a real internet connectivity replacement. if you think of gprs a bit it will never have enough capabilities to serve as a full-time inet service. it's a great solution for accessing your data remotely but it's very limited in means of capacity and then you have those 'pdp-contexts' or how they call it. it's just another acronym for a vpn... if a corporate user requires full ip connectivity then why not give him a vpn uplink directly to their hq and the users can safely use private addresses according to corporate policy. in this way gprs is very similar to mpls. i have worked on gprs-mpls vpn integration and it works just fine. > An Internet Service Provider gives the customer a full > connection to the Internet. All IP protocols should work. you also may give the [common] user an opportunity to have 'limited' service set (so you can use private addresses + nat/pat) for lower price or pay a bit more for 'full' service. i think the 'limited' in real life can safely cover requirements of 95% of the customers. do you think they will download mp3's and avi's via gprs? how? :)) from my point of view if you cover http, e-mail and various similar services you will provide most user with more than they ever would expect, wouldn't you? > I'm in favor of using NAT only where there is a good argument > for it and the customers are given the straight story about > what they're buying and what it won't be able to do. Don't > call yourself an ISP. ... > Tony Rall > > 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.

6 6

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

02 May '02

Unless Im mistaken (entirely possible), an IP enabled phone has 2 distinct and separate "stacks", the IP stack and the "phone" stack. As I said, in a NAT'd scenario the IP stack will never see an unsolicited request and hence not respond to it. The phone side of course will ring when called. Duh. GPRS <> VoIP (yet) Jm > -----Original Message----- > From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Thursday, May 02, 2002 11:26 AM > To: Mansey, Jon > Cc: nanog(a)merit.edu > Subject: Re: DDOS attacks and Large ISPs doing NAT? > > > On Thu, 02 May 2002 11:06:33 PDT, "Mansey, Jon" said: > > > The DDOS discussion is specifically referring to a "live" syn or > > syn/ack attack from hosts that respond to connection > requests. A NAT'd > > cell phone wont, cant ever, respond to an unsolicited connection > > request. > > *RING*!! *RING*!! Oh, I'm sorry, that was the clue phone > ringing - it couldn't be your phone, since it wouldn't answer > an unsolicited connection request.... > > You were saying? > > (To fill in the blanks - get a trojan loaded into the > cellphone/PDA combo, and then send it a page telling it > who/what to attack). > > -- > Valdis Kletnieks > Computer Systems Senior Engineer > Virginia Tech > >

2 1

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

02 May '02

Wasn't trying to make you mad, just looking for clarity. =) -----Original Message----- From: Mark Turpin [mailto:mark@gomez.charter.com] Sent: Thursday, May 02, 2002 11:25 AM To: nanog(a)merit.edu Subject: Re: Effective ways to deal with DDoS attacks? On Thu, May 02, 2002 at 10:16:55AM -0700, LeBlanc, Jason wrote something like this: > Thats how it we understood it to work (CEF lookup). It checks for a route > in the table, obviously any real route would be in the CEF table. I may be > wrong, but it doesn't actually send a packet to verify, the logical way to > check would be by checking CEF, as anything the router knows about that is > valid would be in CEF. If I'm misunderstanding, please do send more info. I think a typo on my part has led to misunderstanding even more. However, the thread's getting hot, so I'm about ready to part ways with it. Regarding my statements, I was not inferring a packet be sent off to a host, or anything of that nature. What I'm referring to is a simple lookup [we now agree by CEF] to verify that the interface a packet was received on was actually the interface CEF would use to go back to the source of that packet. (I forgot source last time) If you can tweak rpf now to support multihoming, woohoo. And yes, depending on where you implement rpf the routing table comes into play. big woop. Earlier LeBlanc, Jason wrote something like this: > There are some limitations as to where uRPF works, SONET only on GSRs for > example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I > think) regardless of interface type. Impact should be minimal, as it simply > does a lookup in the CEF table, if the route isn't there it discards. That's what prompted me to even reply in the first place was noticing the fact you stated rpf only worked on pos interfaces on gsrs and that it did a simple route lookup. Both of which I disagree with. I've already stated what its looking for in the fib, and its *not* whether its 'there or not'. i'm over it, so have a good day... -mark -- Why is it considered necessary to nail down the lid of a coffin?

1 0

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

02 May '02

> -----Original Message----- > From: Gary E. Miller [mailto:gem@rellim.com] > Sent: 2. mája 2002 20:00 > To: Mansey, Jon > Cc: nanog(a)merit.edu > Subject: RE: DDOS attacks and Large ISPs doing NAT? > > > > > Who says a NATed host can not be a zombie? Get the NATed > host to read an email virus. The virus then coonects to an > IRC channel that tells the zombie when to spew. recursion again. the point was just about minimizing, not about completely avoiding. for every solution you do a new exploit will be invented in a short time, no matter how great the patch is > Each phone would not spew much, but imagine you got 100M > phones to do your DDoS for you... it's not about the number of phones but about capacity of the network even if you have 1k phones on one gsm sector they still only can generate as much as the radio allows for. how many channels you suppose to be available for gprs for the whole sector? three? four? several? maybe if you're optimistic enough. i definitely would not consider gprs being a broadband service. then - there are loads of different portable device on the market now and the diversity will increase. how would you manage to load your ddos clients to all these kinds of devices? in the end you maybe will get a few % (if lucky and tricky enough) of the portables. compare it to the aggregate traffic the whole gprs network could generate (not that much) and i don't think you can talk about a ddos in scale we are used to today -- 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.

1 0

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

02 May '02

Thats how it we understood it to work (CEF lookup). It checks for a route in the table, obviously any real route would be in the CEF table. I may be wrong, but it doesn't actually send a packet to verify, the logical way to check would be by checking CEF, as anything the router knows about that is valid would be in CEF. If I'm misunderstanding, please do send more info. -----Original Message----- From: Mark Turpin [mailto:mark-nanog@gomez.charter.com] Sent: Thursday, May 02, 2002 10:05 AM To: LeBlanc, Jason Cc: nanog(a)merit.edu Subject: Re: Effective ways to deal with DDoS attacks? On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this: <snip> > > There are some limitations as to where uRPF works, SONET only on GSRs for > example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I > think) regardless of interface type. Impact should be minimal, as it simply > does a lookup in the CEF table, if the route isn't there it discards. Keep > in mind this is NOT a filter, so the impact is much less, it is simply a CEF > lookup, much more efficient than a filter. This will get rid of a HUGE > percentage of spoofed packets that hit your network, and would also work > pretty well if you are the source of an attack. There is some debate as to > whether you must not have ANY RFC1918 space for this to work. We're trying > to find this out (not a priority), if I get info I'll post. > hmm... either you're being extremely vague, or you misunderstand how RPF works. http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secu r_c/scprt5/scdrpf.htm Its not checking cef to see if a route is there.... its making sure that a packet received on an interface came in on an interface that is the best return path to reach that packet. thereby explaining why multihomed customers will get borked in the event of using rpf. enjoy, -mark -- Support your local medical examiner--die strangely.

3 2

Re: Large ISPs doing NAT?
by Scott Francis 02 May '02

02 May '02

On Thu, May 02, 2002 at 06:22:23AM -0700, msa(a)samurai.sfo.dead-dog.com said: > > [-- PGP output follows (current time: Thu May 2 06:21:09 2002) --] > gpg: Signature made Thu May 2 01:20:39 2002 PDT using ELG key ID CB33CCA7 > gpg: Good signature from "Scott Francis <darkuncle(a)darkuncle.net>" > gpg: key CB33CCA7.920: expired at Tue Mar 19 12:37:04 2002 PST > gpg: Note: This key has expired! > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ please re-fetch the key from wwwkeys.us.pgp.net or your nearest mirror. I updated this key a couple of months back, but it seems that many still have the old one cached. Sorry about that. -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui

1 0

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

02 May '02

Perhaps I should s/zombie/reflector in my orginal post. Jm > -----Original Message----- > From: Ian Cooper [mailto:ian@the-coopers.org] > Sent: Thursday, May 02, 2002 11:04 AM > To: nanog(a)merit.edu > Cc: Mansey, Jon > Subject: RE: DDOS attacks and Large ISPs doing NAT? > > > --On Thursday, May 2, 2002 10:30 -0700 "Mansey, Jon" > <Jon_Mansey(a)verestar.com> wrote: > > > > > 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" > > And NAT helps you stop zombie software being installed on the > always-on > device (phone) precisely how? What's to say that an infected > system (or > vandal's system) isn't going to be connected inside the NATed space? > > > I still maintain, since the last time this was on Nanog, > that real IP > > addresses should not be entrusted to the great unwashed. > > The problem isn't that they're unwashed, the problem is that > they're being > pushed software that has bugs and holes that can be exploited > (oh look, the > "bash Microsoft" thread...) > > > And as for NAT breaking applications, I think its time the > > applications wised up and worked around the NAT issues. > > And what about those applications (protocols) that already > exist and break > when NAT exists? Or applications that simply don't scale > well when NAT > exists? > > > 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. > > Right, and as you move toward HTTP you end up with a stream > that becomes > more and more expensive to deliver (and receive) and it > frequently becomes > harder and harder (and takes longer) to develop that application. > > > When you look at the economics of usability of your app, I > think your > > going to want to make it work through firewalls. > > Depends where the firewall is being run as to whether you > want it to break > the application or not, but if it's possible for all great > apps to run > through firewalls how long is it going to be before "nasty" > apps do that > well? >

1 0