Filter NTP traffic by packet size?
james.braunegg at micron21.com
Sun Feb 23 21:39:08 UTC 2014
I released a bit of a blog article last week about filtering NTP request traffic via packet size which might be of interest !
So far I known of an unknown tool makes a default request packet of 50 bytes 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
P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
E: james.braunegg at micron21.com | ABN: 12 109 977 666
W: www.micron21.com/ddos-protection T: @micron21
This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of 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 message from your computer.
From: joel jaeggli [mailto:joelja at bogus.com]
Sent: Monday, February 24, 2014 7:31 AM
To: Royce Williams; nanog at 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 at techsolvency.com> wrote:
>> Newb question ... other than retrofitting, what stands in the way of
>> making BCP38 a condition of peering?
Peering is frequently but harldy exclusively on a best effort basis, e.g. you 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 to enter into
> In other words ... if it's a problem of awareness, could upstreams
> automate warning their downstreams? What about teaching RADb to
> periodically test for BCP38 compliance, send soft warnings (with links
> to relevant pages on www.bcp38.info), and publish stats?
> Continuing my naïveté ...what if upstreams required BCP38 compliance
> 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
> revenue streams -- but it sounds like nothing's going to change until
> it starts hitting the pocketbooks.
More information about the NANOG