[169409] in North American Network Operators' Group
RE: Filter NTP traffic by packet size?
daemon@ATHENA.MIT.EDU (James Braunegg)
Sun Feb 23 16:39:39 2014
From: James Braunegg <james.braunegg@micron21.com>
To: joel jaeggli <joelja@bogus.com>, Royce Williams <royce@techsolvency.com>,
"nanog@nanog.org" <nanog@nanog.org>
Date: Sun, 23 Feb 2014 21:39:08 +0000
In-Reply-To: <530A5A94.7000408@bogus.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Dear All
I released a bit of a blog article last week about filtering NTP request tr=
affic via packet size which might be of interest !
So far I known of an unknown tool makes a default request packet of 50 byte=
s in size
ntpdos.py makes a default request packet of 60 bytes in size
ntp_monlist.py makes a default request packet of 234 bytes in size
monlist from ntpdc makes a default request packet of 234 bytes in size
In contrast a normal NTP request for a time sync is about 90 bytes in size
More information and some graphs can be found here http://www.micron21.com=
/ddos-ntp.php
Kindest Regards
=09
James Braunegg
P:=A0 1300 769 972=A0 |=A0 M:=A0 0488 997 207 |=A0 D:=A0 (03) 9751 7616
E:=A0=A0 james.braunegg@micron21.com=A0 |=A0 ABN:=A0 12 109 977 666=A0=A0=20
W:=A0=A0www.micron21.com/ddos-protection T:=A0@micron21
This message is intended for the addressee named above. It may contain priv=
ileged or confidential information. If you are not the intended recipient o=
f this message you must not use, copy, distribute or disclose it to anyone =
other than the addressee. If you have received this message in error please=
return the message to the sender by replying to it and then delete the mes=
sage from your computer.
-----Original Message-----
From: joel jaeggli [mailto:joelja@bogus.com]=20
Sent: Monday, February 24, 2014 7:31 AM
To: Royce Williams; nanog@nanog.org
Subject: Re: Filter NTP traffic by packet size?
On 2/23/14, 12:11 PM, Royce Williams wrote:
> On Sun, Feb 23, 2014 at 10:48 AM, Royce Williams <royce@techsolvency.com>=
wrote:
>> Newb question ... other than retrofitting, what stands in the way of=20
>> making BCP38 a condition of peering?
Peering is frequently but harldy exclusively on a best effort basis, e.g. y=
ou agree to exchange traffic, but also agree to hold each other harmless if=
something bad happens. that's any easy enough contract for most entities t=
o enter into
> In other words ... if it's a problem of awareness, could upstreams=20
> automate warning their downstreams? What about teaching RADb to=20
> periodically test for BCP38 compliance, send soft warnings (with links=20
> to relevant pages on www.bcp38.info), and publish stats?
>=20
> Continuing my na=EFvet=E9 ...what if upstreams required BCP38 compliance=
=20
> before updating BGP filters?
my upstreams adjust their filters when I update radb.
> This would require a soft rollout --
> we'd have to give them a few months' warning to not interfere with=20
> revenue streams -- but it sounds like nothing's going to change until=20
> it starts hitting the pocketbooks.
>=20
> Royce
>=20
>=20
