[169432] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Filter NTP traffic by packet size?

daemon@ATHENA.MIT.EDU (Keegan Holley)
Wed Feb 26 11:18:57 2014

From: Keegan Holley <no.spam@comcast.net>
In-Reply-To: <d0225d3a502a436e9bbb22d75c219aad@EDGMBXV06.marvel.elnk.net>
Date: Wed, 26 Feb 2014 07:56:04 -0500
To: "Staudinger, Malcolm" <mstaudinger@corp.earthlink.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Feb 25, 2014, at 12:22 PM, Staudinger, Malcolm =
<mstaudinger@corp.earthlink.com> wrote:

> Why wouldn't you just block chargen entirely? Is it actually still =
being used these days for anything legitimate?
>=20

More politely stated, it=92s not the responsibility of the operator to =
decide what belongs on the network and what doesn=92t.  Users can run =
any services that=92s not illegal or even reuse ports for other =
applications.  That being said commonly exploited ports (TCP 25 for =
example) are often blocked.  This is usually done to block or protect an =
application though not to single out a particular port number.

> Malcolm Staudinger
> Information Security Analyst | EIS
> EarthLink
>=20
> E: mstaudinger@corp.earthlink.com
>=20
> -----Original Message-----
> From: Blake Hudson [mailto:blake@ispn.net]=20
> Sent: Tuesday, February 25, 2014 8:58 AM
> To: nanog@nanog.org
> Subject: Re: Filter NTP traffic by packet size?
>=20
> I talked to one of our upstream IP transit providers and was able to =
negotiate individual policing levels on NTP, DNS, SNMP, and Chargen by =
UDP port within our aggregate policer. As mentioned, the legitimate =
traffic levels of these services are near 0. We gave each service many =
times the amount to satisfy subscribers, but not enough to overwhelm =
network links during an attack.
>=20
> --Blake
>=20
> Chris Laffin wrote the following on 2/23/2014 8:58 AM:
>> Ive talked to some major peering exchanges and they refuse to take =
any action. Possibly if the requests come from many peering participants =
it will be taken more seriously?
>>=20
>>> On Feb 22, 2014, at 19:23, "Peter Phaal" <peter.phaal@gmail.com> =
wrote:
>>>=20
>>> Brocade demonstrated how peering exchanges can selectively filter=20
>>> large NTP reflection flows using the sFlow monitoring and hybrid =
port=20
>>> OpenFlow capabilities of their MLXe switches at last week's Network=20=

>>> Field Day event.
>>>=20
>>> =
http://blog.sflow.com/2014/02/nfd7-real-time-sdn-and-nfv-analytics_19
>>> 86.html
>>>=20
>>>> On Sat, Feb 22, 2014 at 4:43 PM, Chris Laffin <claffin@peer1.com> =
wrote:
>>>> Has anyone talked about policing ntp everywhere. Normal traffic =
levels are extremely low but the ddos traffic is very high. It would be =
really cool if peering exchanges could police ntp on their connected =
members.
>>>>=20
>>>>> On Feb 22, 2014, at 8:05, "Paul Ferguson" =
<fergdawgster@mykolab.com> wrote:
>>>>>=20
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>=20
>>>>>>> On 2/22/2014 7:06 AM, Nick Hilliard wrote:
>>>>>>>=20
>>>>>>> On 22/02/2014 09:07, Cb B wrote:
>>>>>>> Summary IETF response:  The problem i described is already =
solved=20
>>>>>>> by bcp38, nothing to see here, carry on with UDP
>>>>>> udp is here to stay.  Denying this is no more useful than trying=20=

>>>>>> to push the tide back with a teaspoon.
>>>>> Yes, udp is here to stay, and I quote Randy Bush on this, "I=20
>>>>> encourage my competitors to block udp."  :-p
>>>>>=20
>>>>> - - ferg
>>>>>=20
>>>>>=20
>>>>> - --
>>>>> Paul Ferguson
>>>>> VP Threat Intelligence, IID
>>>>> PGP Public Key ID: 0x54DC85B2
>>>>>=20
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v2.0.22 (MingW32)
>>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>>=20
>>>>> iF4EAREIAAYFAlMIynoACgkQKJasdVTchbJsqQD/ZVz5vYaIAEv/z2kbU6kEM+KS
>>>>> OQx2XcSkU7r02wNDytoBANVkgZQalF40vhQED+6KyKv7xL1VfxQg1W8T4drh+6/M
>>>>> =3DFTxg
>>>>> -----END PGP SIGNATURE-----
>=20
>=20



home help back first fref pref prev next nref lref last post