Subject: Re: [ntpwg] RFC7822 issues

From: Greg Dowd <[email-masked]>
Date: Wed, 11 May 2016 14:36:21 +0000

Just a nit.  Maximum asymmetry is ALL the round trip.  Max offset for that sample is half.

On May 11, 2016 05:33, Miroslav Lichvar <[email-masked]> wrote:
EXTERNAL EMAIL

On Tue, May 10, 2016 at 12:53:50AM -0700, Harlan Stenn wrote:
> On 5/10/16 12:21 AM, Miroslav Lichvar wrote:
> > Isn't that because until very recently there were no other extension
> > fields than those used by autokey? Now you are proposing new fields
> > and we want the old implementations to be able to parse them, right?
>
> 1) nobody has implemented these new EFs yet.
>
> 2) As far as autokey goes, there will be at most one autokey EF in a
> packet.  There may be more EFs, eventually.
>
> 3) If A sends an EF to B and B does not respond, it's up to A to decide
> to either keep trying or decide B can't handle this new EF.  This is
> another reason I came up with the I-DO EF proposal.
>
> It's not that difficult to figure out if the ntp instance on the "far
> side" can handle these or not.

Ok, it's starting to make sense to me now. You seem to be saying it's
acceptable to send old implementations packets in a format which they
don't understand. The server drops the packet and the client can try
the older format after several missed replies. Do I understand it
correctly?

> > I think we could allow even shorter extension fields if we put them
> > inside a longer extension field. I proposed a packing extension field
> > in my other mail yesterday.
>
> Why bother?  To protect old code?  In that case it's better to just not
> send EFs that are not understood.

Yes, I assumed there was an interest in making only backward
compatible changes in the same version of the protocol. An old server
can ignore an unknown extension field and reply to the client, which
will immediatelly know the server doesn't support the extension field.

If the server drops the packet due to invalid format, the client has
to guess if the server really dropped it (for whatever reason) or the
packet was just lost in the network, or its network connection is not
up yet. This will be slower and less reliable. The I-Do specification
will help with new extension fields, but the client will still need to
detect if the server supports I-Do.

Anyway, I think it would be cleaner if the specification didn't
require the implementation to look at the field type/key ID in order
to distinguish extension fields from a MAC, i.e. avoid rules like if
the packet has at least one autokey field, it must have a MAC, or if
the key ID is < 65536, it's not an extension field.

> > The data in the packet (except the TC field) could still be
> > authenticated. The TC correction would be accepted only if it was
> > sane, e.g. smaller than maximum asymmetry in the measured delay.
> >
> > [1] http://lists.ntp.org/pipermail/ntpwg/2015-August/002335.html
>
> Got bounds on that asymmetry?  Sure looks like an easily exploitable
> situation to me, certainly more exploitable than many of the recent
> security bugs we've addressed.

Half of the measured delay is the upper bound. There could be also a
configurable limit for the correction. A MITM attacker can create a
larger error in the measurement simply by delaying the request or
response, there is no need to modify anything in the packet.

--
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg