North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: DDOS attacks and Large ISPs doing NAT?
Perhaps I should s/zombie/reflector in my orginal post. Jm > -----Original Message----- > From: Ian Cooper [mailto:[email protected]] > Sent: Thursday, May 02, 2002 11:04 AM > To: [email protected] > Cc: Mansey, Jon > Subject: RE: DDOS attacks and Large ISPs doing NAT? > > > --On Thursday, May 2, 2002 10:30 -0700 "Mansey, Jon" > <[email protected]> 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? >
|