Re: [Ntp] NTS IANA request

On 6/7/2019 7:49 PM, Watson Ladd wrote:
> 
> 
> On Fri, Jun 7, 2019, 10:34 AM Daniel Franke <dfoxfranke@gmail.com
> <mailto:dfoxfranke@gmail.com>> wrote:
> 
>     On Fri, Jun 7, 2019 at 10:31 AM Danny Mayer <mayer@ntp.org
>     <mailto:mayer@ntp.org>> wrote:
>     > We do what we did for EDNS0, get the firewall folks to change their
>     > policies to allow for larger payloads. It will takes years but
>     firewall
>     > people have to move with changes as they happen.
> 
>     EDNS0 may literally be the worst possible role model here. It made DNS
>     a serious amplifier, the internet's second-worst offender after NTP.
>     It *created* the problems that those firewall rules were put in to
>     solve. Today if you want to make a DNS request whose response is
>     likely to be larger than 512 bytes, you're practically forced to do it
>     over TCP.
> 
> 
> NTP? There are no mode 6 packets in RFC 5905. 

How is this relevant?

> Let's be clear about what happened: one implementation did something
> silly

Point of order: is this a technical comment?  Is it professional?

The implementation was behaving as it did pretty much from before 1989 -
it was in xntp2, and I haven't checked anything earlier.

Back from when the "internet" was a friendly and helpful place.

The Reference Implementation required a token for MRU lists, the vehicle
for the amplification attack starting in late March of 2010.

The 'monitor' keyword was added in July of 2010.

The 'mode7' keyword was added in November of 2011.

The big NTP attacked happened in December 2013.

Folks had more than 2 years to decide to upgrade.

But none of these attacks, NTP, DNS, etc. would have been possible had
folks implemented BCP38, which was published in May of 2000.

> and we have to clean up the mess.

If you mean the NTP WG, then we disagree.

We have responsibilities *to* people, not *for* people.

If folks choose not to upgrade their software, or to not bother with BCP
on traffic or configurations, against recommendation, that's their
choice.  It is arguably irresponsible, but it's still their choice.

> And to compound the problem
> src=123 is used for queries by that same implementation so time servers
> can't block the amplification easily and still be useable by the widely
> shipped implementation. 

How exactly would not using 123 for queries allow folks to block
amplification?  The forged packets were likely not coming from port 123.

Your assertion makes no sense to me.  Perhaps you could rephrase it for
me and anybody else who doesn't know what you're trying to say.

> I'm still jumping through hoops because of this.

In what way?

> Sincerely,
> Watson
> 
> 
> 
>     _______________________________________________
>     ntp mailing list
>     ntp@ietf.org <mailto:ntp@ietf.org>
>     https://www.ietf.org/mailman/listinfo/ntp
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!