DDOS attacks and Large ISPs doing NAT?
Mansey, Jon
Jon_Mansey at verestar.com
Thu May 2 18:10:08 UTC 2002
Perhaps I should s/zombie/reflector in my orginal post.
Jm
> -----Original Message-----
> From: Ian Cooper [mailto:ian at the-coopers.org]
> Sent: Thursday, May 02, 2002 11:04 AM
> To: nanog at 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 at 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?
>
More information about the NANOG
mailing list