[169383] in North American Network Operators' Group
Re: Filter NTP traffic by packet size?
daemon@ATHENA.MIT.EDU (Carsten Bormann)
Sat Feb 22 04:49:23 2014
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAD6AjGTvnOzp0c171UdFStF6HQaeogGCu=-ReGWNLOo7vSpx8g@mail.gmail.com>
Date: Sat, 22 Feb 2014 10:48:09 +0100
To: Cb B <cb.list6@gmail.com>
Cc: "nanog@nanog.org list" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>> (Just be careful not to try to "fight yesterday's war=94.)
> yesterday's war =3D don't bring up that operators are having a real
> problem with UDP,
No, you don=92t.
You are having a problem with applications that enable strongly =
amplified reflection.
(Yes, after the days of smurf passed, these are all on UDP, because it =
is hard to make that mistake with TCP, and nothing else is deployable.
Still, your problem is not =93with UDP=94, but with those applications.)
The obvious solution for a new protocol is to make sure that it doesn=92t =
have that problem, whether it is layered on UDP or something else.
(In yesterday=92s network, it *only* can be layered on UDP, because =
nothing else goes through NATs.)
Also, note that the NTP issue we are seeing right now is not a protocol =
problem at all, it is all about shoddy implementation.
The next problem is that the hammers you have to fix this at the network =
level really aren=92t that good for fixing the rust on those =
implementations.
The QUIC people tell us they are able to talk UDP to about 93 % of the =
people they can talk TCP to.
So a part of the network will be stuck with running their applications =
on today=92s TCP.
But that doesn=92t mean that we can=92t layer useful new stuff on UDP, =
it just will be less universally available.
(With those new applications coming online, blanket filtering of UDP =
will be exposed even more as the low-ball networking that it is, so I =
expect the workability of UDP to go up over time, not down.)
Gr=FC=DFe, Carsten
