[47352] in North American Network Operators' Group
RE: DDOS attacks and Large ISPs doing NAT?
daemon@ATHENA.MIT.EDU (Daniska Tomas)
Thu May 2 13:54:03 2002
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 2 May 2002 19:53:13 +0200
Message-ID: <A44DA7EDD8262343B02C64AF7E063A0712848B@kenya.ba.tronet.sk>
From: "Daniska Tomas" <tomas@tronet.com>
To: <nanog@merit.edu>
Errors-To: owner-nanog-outgoing@merit.edu
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
--
=20
Tomas Daniska
systems engineer
Tronet Computer Networks
Plynarenska 5, 829 75 Bratislava, Slovakia
tel: +421 2 58224111, fax: +421 2 58224199
=20
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]=20
> Sent: 2. m=E1ja 2002 19:31
> To: nanog@merit.edu
> Subject: RE: DDOS attacks and Large ISPs doing NAT?=20
>=20
>=20
>=20
> To merge these 2 great threads, it is the case is it not that=20
> NAT is a great way to avoid DDOS problems. I don't even want=20
> to imagine what the billing/credit issues would be like if=20
> your always-on phone with a real IP is used as a zombie in a=20
> DDOS. "Hey I didn't use all that traffic last month....etc etc"
>=20
> I still maintain, since the last time this was on Nanog, that=20
> real IP addresses should not be entrusted to the great unwashed.
>=20
> And as for NAT breaking applications, I think its time the=20
> applications wised up and worked around the NAT issues. Look,=20
> if your application is important enough to you as the=20
> developer, you are going to want it to penetrate and work for=20
> as many ppl as possible right? Office workers, home users=20
> with gateways, GPRS/GSM/3G cell users etc etc. So you make it=20
> use protocols that traverse NAT without breaking. Look at the=20
> streaming media players out there, they try to use, in order,=20
> multicast (the most effcient and best quality), UDP,TCP then=20
> HTTP. If it cant get a connection with any of the first=20
> protocols, it falls back to http, and you get your stream.
>=20
> When you look at the economics of usability of your app, I=20
> think your going to want to make it work through firewalls.
>=20
> Jm
