Re: [Ntp] NTS IANA request

On Fri, Jun 7, 2019 at 10:16 PM Harlan Stenn <stenn@nwtime.org> wrote:
>
>
>
> 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.

There are many places where these problems could be solved. That
doesn't free us from having to deal with them.

>
> > 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.

The issue isn't with being an amplifier, the issue with being the
victim of an amplifier. Blocking src = 123 is an easy solution for the
network team, but makes it impossible to operate a time service
without blocking those users who use the reference implementation. So
operators of NTP servers have to decide: be vulnerable to DDOS or not
support common clients. This is not good.

>
> 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?

The details aren't that interesting and mostly concern assumptions
that get broken by the solution to the above problem of putting the
server on its own ip range with its own firewall rules which are not
protected.

>
> > 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!
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

--
"Man is born free, but everywhere he is in chains".
--Rousseau.