RE: Filter NTP traffic by packet size?

[James Braunegg <james.braunegg () micron21 com>]

Dear All

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

Kindest Regards

        
James Braunegg
P:  1300 769 972  |  M:  0488 997 207 |  D:  (03) 9751 7616
E:   james.braunegg () 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.

-----Original Message-----
From: joel jaeggli [mailto:joelja () bogus com] 
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 
> > 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.
>
> Royce