RE: DDOS attacks and Large ISPs doing NAT?

["Mansey, Jon" <Jon_Mansey () verestar com>]

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 () 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 () 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?