Re: [ntpwg] Comments on new drafts

[Harlan Stenn <[e-mail]>]

Miroslav Lichvar writes:
> I've few quick comments and questions on the new drafts. I can expand
> on that later if there is any interest.
> 
> draft-mayer-ntp-mac-extension-field-00
> - I'm not sure if hiding the length of the MAC using padding with
>   random data is really useful. This was discussed before. The
>   attacker can search for the key in parallel using all hash
>   functions. As their number is very small, the slowdown is
>   insignificant.

Doing this is a local policy choice.  If you don't want to do it, then
don't.

> - 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.  It
should also be possible to provide the hash function with a mode 6
query, so authenticated folks can see the hash algorithm.

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

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

> - In order to save bandwidth with functions producing long digests,
>   they could be truncated to some fixed size, like NTS already does in
>   its MAC extension field. Is 128 bits enough?

I'd like to see a clear and complete analysis of the costs and benefits.
Doing this is certainly an option.

> - 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 existing and new MAC proposals don't need any changes for new
authentication schemes, from what I can see.

> draft-stenn-ntp-i-do-00
> - The draft mentions negotiation. Is the server required to keep a
>   state of what the client supports? I'd expect it to be a purely
>   informational field that doesn't change over time.

If no state is kept then traditional v4 behavior should be used.

If there is a "peer" structure of some sort, then it's easy to keep a
bit of state.  But again, this is a local policy choice.

And yes, this information may change over time, and either side can
re-issue this exchange.  Two obvious reasons why this might happen
include "Now that we have completed an NTS negotiation, I see that you
qualify for additional authorizations, so I-Do the follwing, if you are
interested", and "Gee, I restarted.  I don't remember what we agreed to
before."

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

The bit is "MAC OPTIONAL", not "MAC REQUIRED".  The use of this bit is
backward-compatible with the original behavior.

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

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

For IPv6 refids I think we'd only get a false-positive response in this
case.  And again, this doesn't happen if both sides implement I-Do.

*If* you want to use traditional S2+ refids instead of Sharon's "Not
You" refid, or my suggested-refid, then fine, do that.  If you are OK
with the current setup, then fine, use that.

If you don't want to implement this, then don't.

As I recall, it was 2 trivial lines of code to make this work on each
side, "sending it", and "is that what I got".

Oh, if "The world is quickly moving to IPv6" and the assumption is that
IPv4 will die off soon, then it shouldn't be too long before more folks
upgrade their NTP software. :)

> - It's an incompatible change making assumptions about how the refid
>   is used in clients.

It's easy enough to control when it's used if that's important.

And the cost if one side doesn't implement it is not huge, it's a timing
loop where each side will increase its stratum every poll.  This is a
"self-correcting" problem, in the rare event it happens.

As more software gets upgraded, more systems can be expected to
implement I-Do and then this situation can be better detected.

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

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

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

> - This should rather be a new extension field, maybe in a more general
>   form that allows different time scales and their offset to UTC to be
>   specified.

Feel free to propose that as an alternative.  I specifically chose what
I did because it's very good at being backward-compatible and it's very
visible.

Putting the offset in an EF means clients that don't understand the EF
will either drop the packet completely (a clear lose) or won't know what
to do with it.  Running ntpq -p will not show that the system is
following a leap-smeared system peer.  These limitations are
show-stoppers, in my book.

This issue is *all* about backward-compatibility in the face of people
running out-of-date software.

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

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

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

> - The extension field could be extended to contain also refids of
>   upstream servers (obtained with this extension).

Out-of-scope for this proposal, and of unproven value.

> - Instead of hiding the real refid, I'd rather see servers to use this
>   extension field to announce the same refid to all clients in order
>   to allow them to detect multihomed hosts and duplicates in paths to
>   their stratum 1 sources. This is discussed in the other thread.

It's not hiding the real refid.

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

There are other ways to do this, and providing information about the
identity of "other servers involved with time exchange" creates security
problems.

> draft-stenn-ntp-last-extension-00
> - Field length of 4 is currently not valid in NTP packets. The minimum
>   length is 16 and there are special rules for the last extension
>   field. Is there a plan to relax these requirements? (It would be
>   an incompatible change.)

Then don't use it unless it's agreeable based on I-Do.

If it's agreeable then it's OK to use it.

> - Will be this extension field useful when the new MAC extension field
>   is ready? It looks like they have a similar purpose.

Yes.  If nothing else, it can be useful for broadcast situations where
some clients may not understand MAC-EF but do understand a legacy MAC.

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