Re: [ntpwg] Comments on new drafts

[Miroslav Lichvar <[e-mail]>]

On Thu, Apr 07, 2016 at 09:16:26PM +0000, Harlan Stenn wrote:
> Miroslav Lichvar writes:
> > draft-mayer-ntp-mac-extension-field-00
> > - Instead of hiding the hash function, I think it might be more useful
> >   to specify it directly in the field to allow easier debugging when
> >   the authentication fails. The MAC length field could be shortened to
> >   one octet and the other octet could specify the key type, allowing
> >   256 different types.
> 
> I see the cost of advertising the hash function.  I don't see the
> benefit to advertising the hash function.  If there's a failure, that
> should be a very rare event and it should be obvious how to fix it.

Beside knowing which hash function was used in the MAC, the type field
will allow other MACs in the field, not just those used by
authentication with symmetric keys.

> If the hash function is communicated, I think there are probably better
> ways to convey that information besides trying to save 1 byte.

If you want to keep the data aligned to 4 octets and not waste too
much space, what else do you propose?

> I have no opinion as to whether or not we should limit the size of the
> hash to ~256 bytes (if I understood that part correctly).

The size could be specified in multiplies of 4, if you think 256 is
not enough. I don't.

> > - MACs could be treated as opaque data, not requiring symmetric keys
> >   with 32-bit key IDs. This would allow storing MACs from new
> >   authentication schemes and they wouldn't need a new extension field,
> >   just a new MAC type for this extension field.
> 
> I don't understand "... they wouldn't need a new extension field, just a
> new MAC type for this extension field."

The NTS MAC could be stored in this field for instance, it doesn't
have to be a new extension field. If you had multiple MACs in this
field packet, they would be independent. Their order wouldn't change
the result, the second MAC wouldn't have to include the first one, the
third MAC wouldn't need to include the first and second one, and so on.

> > draft-stenn-ntp-i-do-00
> > - It's not clear to me why there needs to be a "MAC required" bit and
> >   why it should be specified in this draft. This was discussed before,
> >   but I've not seen any conclusion.
> 
> We've had MACs from before we had the first EF.  When autokey arrived,
> it *required* a MAC.  Many years' later, we have now just added an
> experimental EF that says "there MUST NOT be a MAC."

That information is included in the specification of the field. How
will that bit change behaviour of an implementation that doesn't
understand the field? It would be great if you could give an example
of a difference in the processing of the packet when this bit is set
and not set.

> > draft-stenn-ntp-ipv6-refid-hash-00
> > - The idea was discussed several times before. It doesn't make much
> >   sense to me. 
> 
> Then don't implement it, and don't announce that you support it in I-Do
> exchanges.

If I don't implement it, I won't be able to detect loops with servers
that do implement it. This is not an optional feature as I understand
it. It changes the definition of the refid field in the NTPv4 packets
and everyone has to deal with it.

> > - In order to avoid conflicts with refids based on IPv4 addresses it
> >   makes conflicts between refids based on IPv6 more likely. Why should
> >   be IPv4 special? The world is quickly moving to IPv6.
> 
> It uses an initial octet that CANNOT appear as a source address, so
> your argument that it "makes conflicts between refids based on IPv6 more
> likely" seems ... wrong to me, at least for IPv4-based refids.

I mean conflict between two refids generated from two different IPv6
addresses. Your proposal prevents a conflict between IPv6 refids and
IPv4 refids, but at a cost that there will be more conflicts between
IPv6 refids. The 32-bit IPv4 space would be mapped to 32 bits in
refid, but the 128-bit IPv6 space only to 24 bits. Don't you see the
problem?

> > draft-stenn-ntp-leap-smear-refid-00
> > - I don't think the refid field in NTP packet is a good place to store
> >   an offset.
> 
> Where else can it go that it's obvious, visible, and almost totally
> backward-compatible?

I think the reference timestamp would be a much better choice.

> > - The refid will conflict with 1/256 of refids based on IPv6. Even if
> >   the IPv6 refid draft that shrinks the space for IPv6 refids to 24
> >   bits is accepted, it will take some time before it's used.
> 
> Only for client mode associations at the ~S3 level, that do not choose
> to implement any of the other proposals around I-Do and refids.

That includes all old implementations, right? I.e. the target of the
proposal?

> What do you propose as an alternative for servers that want to offer
> smeared time to clients?

If you need to see the fact that the server is leap smearing in the
ntpq output in the refid field, pick a constant value for refid and
don't encode the offset. That's what I did in chrony.

> > draft-stenn-ntp-suggest-refid-00
> > - Again, the "required MAC" bit in the field type doesn't seem useful.
> 
> Again, what I wrote above.  The bit says "MAC OPTIONAL", and is
> backward-compatible.

Ok, sorry for the confusion.

> > - I'd suggest to use all bits of the refid (not fix the first octet to
> >   0xfd) to make collisions less likely.
> 
> Your suggestion is backwards-incompatible.  We have already seen reports
> of the IPv6 hash returing a value that matches the IPv4 address of a
> *different IPv4 host on the same network as the IPv6 host*.

But the same thing is happening in IPv6-only networks (and you want to
make that problem even more common). The users just need to know the
refid is not an IPv4 address.

> Refids are there for 1-degree loop detection, not "who is my upstream
> server".

I disagree. Yes, the main purpose is prevention of loops, but up to
now matching refids of two servers indicated they used the same
source. That is a useful information.

> The primary reason for the refid is to detect degree-1 timing loops.

Ok, so preventing loops between two peers is important, but between
three and more peers it is not?

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