[ntpwg] Comments on new drafts

[Miroslav Lichvar <[e-mail]>]

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

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

draft-stenn-ntp-ipv6-refid-hash-00
- The idea was discussed several times before. It doesn't make much
  sense to me. 
- 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's an incompatible change making assumptions about how the refid
  is used in clients.

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

draft-stenn-ntp-suggest-refid-00
- Again, the "required MAC" bit in the field type doesn't seem useful.
- I'd suggest to use all bits of the refid (not fix the first octet to
  0xfd) to make collisions less likely.
- The extension field could be extended to contain also refids of
  upstream servers (obtained with this extension).
- 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.

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.)
- Will be this extension field useful when the new MAC extension field
  is ready? It looks like they have a similar purpose.

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