[169309] in North American Network Operators' Group
Re: Filter NTP traffic by packet size?
daemon@ATHENA.MIT.EDU (Laszlo Hanyecz)
Thu Feb 20 16:07:47 2014
From: Laszlo Hanyecz <laszlo@heliacal.net>
In-Reply-To: <CAPpGzHFQoqqB6SKP1c1nX=LX9=C7djhi5szwN1trxE8bVMNJDg@mail.gmail.com>
Date: Thu, 20 Feb 2014 21:05:24 +0000
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Filtering will always break something. Filtering 'abusive' network =
traffic is intentionally difficult - you either just let it be, or you =
filter it along with the 'good' network traffic that it's pretending to =
be. How can you even tell it's NTP traffic - maybe by the port numbers? =
What if someone is running OpenVPN on those ports? What about IP =
options? Maybe some servers return extra data? =20
This is really not a network operator problem, it's an application =
problem if anything. While it makes sense to temporarily filter a large =
flood to keep the rest of your customers online, it's a very blunt =
instrument, as the affected customer is usually still taken offline - =
but I'm talking about specific targeted filters anyway. Doing blanket =
filtering based on packet sizes is sure to generate some really hard to =
debug failure cases that you didn't account for.
Unfortunately, as long as Facebook loads, most of the users are happy, =
and so these kinds of practices will likely be implemented in many =
places, with some people opting to completely filter NTP or UDP. Maybe =
it will buy you a little peace and quiet today, but tomorrow it's just =
going to be happening on a different port/protocol that you can't =
inspect deeply, and you don't dare block. I can imagine 10 years from =
now, where we're writing code that fragments replies into 100 byte =
packets to get past this, and everyone loses. Your filter is =
circumvented, the application performs slower, and the 'bad guys' found =
another way that you can't filter. When all that's left is TCP port =
443, that's what all the 'abuse' traffic will be using too.
Laszlo
On Feb 20, 2014, at 8:41 PM, Edward Roels <edwardroels@gmail.com> wrote:
> Curious if anyone else thinks filtering out NTP packets above a =
certain
> packet size is a good or terrible idea.
>=20
> =46rom my brief testing it seems 90 bytes for IPv4 and 110 bytes for =
IPv6 are
> typical for a client to successfully synchronize to an NTP server.
>=20
> If I query a server for it's list of peers (ntpq -np <ip>) I've seen
> packets as large as 522 bytes in a single packet in response to a 54 =
byte
> query. I'll admit I'm not 100% clear of the what is happening
> protocol-wise when I perform this query. I see there are multiple =
packets
> back forth between me and the server depending on the number of peers =
it
> has?
>=20
>=20
> Would I be breaking something important if I started to filter NTP =
packets
>> 200 bytes into my network?
