Subject: Re: [Ntp] WG Call for Adoption: draft-stenn-ntp-extension-fields

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 26 Sep 2018 16:10:25 +0200

FWIW, I've submitted a draft for the idea that was described in the
previous email.

https://www.ietf.org/id/draft-mlichvar-ntp-short-extension-fields-00.txt

Suggestions, comments, and co-authors are welcome. If anyone has a
better name for the draft, the format, or extension fields specified
in the draft, please let me know.

M.

On Fri, Jul 27, 2018 at 10:19:18AM +0200, Miroslav Lichvar wrote:
> On Thu, Jul 26, 2018 at 12:59:57PM -0400, Daniel Franke wrote:
> > If for whatever reason we really, really have to support shorter
> > extension fields and can't wait for NTPv5 to do it, then I agree with
> > Miroslav that his sub-extensions proposal is the sanest way to go
> > about it. But I don't want to adopt that proposal either until I've
> > seen a use case for it that's compelling enough to justify the extra
> > complexity, and so far I haven't seen one.
> 
> Some of the EFs that were proposed are shorter than 28 octets, e.g.
> I-Do or Suggested-REFID. Also, I'm considering to split some of the
> fields from the correction EF into a separate EF. I think it would be
> nice to allow short EFs to limit the waste of bandwidth.
> 
> If we limited the use of the packing EF to one, not allowed MACs after
> it, and required it to contain all EFs in the packet, it would
> basically provide what we want from NTPv5. We could call it NTPv4.1 if
> you like. The extra complexity would be a new check and flag in the
> parser.
> 
> An NTPv4.1 packet would have the following format:
> - 48-octet NTPv4 header
> - 2-octet magic number (the packing EF type)
> - 2-octet length of all data following the NTP header (the packing EF
>   length)
> - >24 octets of one or more EFs with no restrictions on minimal length
> 
> A parser that supports the NTPv4.1 format would check that:
> - the length of the packet is at least 76 octets
> - the 49th and 50th octets contain the magic number
> - the 51th and 52th octets contain a value that is equal to the
>   length of the packet - 48
> 
> If the above is true, the parser knows there is no legacy MAC, i.e. 
> the remaining data should be parsed as extension fields. There is no
> ambiguity in parsing.
> 
> An older parser following RFC7822 would see a valid NTPv4 packet with
> a single >28-octet EF of an unknown type.
> 
> When compared to the "quick" NTPv5 approach, NTPv4.1 packets would be
> longer by 4-24 octets. The 24-octet waste would be with a single
> 4-octet extension field (if one is ever specified). With
> longer/multiple EFs it would decrease down to 4 octets.
> 
> Does that make sense?
> 
> -- 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Hal Murray <[email-masked]>
Date: Thu, 27 Sep 2018 01:36:17 -0700

> - >24 octets of one or more EFs with no restrictions on minimal length

A possible alternative would be an EF that said no bare MAC.
  2 byte magic number
  2 byte length

--------

Is this whole problem a wild goose chase?  If two systems are using MACs, they 
have exchanged keys.  Could they also exchange a no-bare-MAC flag using the 
same mechanism?

Why can't a system simply declare that it doesn't support bare MACs?  If so, 
why would anybody ever send it one?

-- 
These are my opinions.  I hate spam.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 27 Sep 2018 11:06:41 +0200

> A possible alternative would be an EF that said no bare MAC.

The length of the EF would be 4 octets? That would prevent the
ambiguity in parsing (assuming the minimum length of the packet is
still 76 octets), but it wouldn't be compatible with RFC 7822, which
says the minimum length of an EF is 16 octets. Implementations that
follow it would drop such a packet for having an invalid format.

> why would anybody ever send it one?

A server and client can certainly do that, but all other devices or
programs that may be processing packets between would have to follow
that and keep some state.

A switch looking for the Correction EF will not be keeping any state
for NTP and it must be sure it's really the EF and not just a random
MAC before it modifies the packet.

It would be nice if tcpdump/wireshark could reliably parse NTP packets
and display individual EFs.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Thu, 27 Sep 2018 03:23:48 -0700

[email-masked] said:
> The length of the EF would be 4 octets? That would prevent the ambiguity in
> parsing (assuming the minimum length of the packet is still 76 octets), but
> it wouldn't be compatible with RFC 7822, which says the minimum length of an
> EF is 16 octets. Implementations that follow it would drop such a packet for
> having an invalid format. 

RFC 7822 and RFC 5905 both say:
  While the minimum field length containing required fields is
  four words (16 octets), the maximum field length cannot be longer
  than 65532 octets, due to the maximum size of the Length field.

I can't find any place where it expands on "required fields".  It looks like 
that refers to the extension fields as used by Autokey.

There is a similar quirk about request and response:
  Other than defining the field format, this document makes no use
  of the field contents. An extension field contains a request or
  response message in the format shown in Figure 14.

Is the current intent that there is a min length?  Do extension fields really 
have to be requests or responses?

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 27 Sep 2018 15:01:40 -0700

Hal,

Re "declaring" what is supported, you're saying you are supporting:

 https://tools.ietf.org/html/draft-stenn-ntp-i-do-04

right?

I think everything else in this thread is clearly and fully covered in
the (updated):

 https://tools.ietf.org/html/draft-stenn-ntp-extension-fields-07

H

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Hal Murray <[email-masked]>
Date: Fri, 28 Sep 2018 04:29:27 -0700

>  https://tools.ietf.org/html/draft-stenn-ntp-i-do-04

No.  I was thinking of something much simpler.  Maybe a note on the web page 
describing the NTP server, next to the place where it says it does/doesn't do 
leap smearing.

I'm not sure that "what is supported" captures the spirit of what I was 
suggesting.  I was trying to describe something that wasn't supported.  You 
may be able to turn that inside out with some good wordsmithing.

> I think everything else in this thread is clearly and fully covered in the
> (updated):

I find section 4 hard to read.  There are huge chunks of old/new text with no 
summary of what is changing.

The minimum length of 16 bytes has been changed to 8.  I still don't 
understand why an EF needs any payload at all.

It still describes the 16 bit extension-type field as 2 flag bits, one for 
query/response, and another that is deprecated.  Is there an EF type for MAC?  
Is that a query or response?

The link behind "NEW: 'RFC5905 Section 7.5.1 - Extension Fields and MACs'" in 
the Table of Contents doesn't work.  (It's a new section.  There is no place 
to link to.  I think the link should be removed.)

There are no links to sections 4.2 or 4.3 from the Table of Contents.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Sep 2018 17:40:39 -0700

> describing the NTP server, next to the place where it says it does/doesn't do 

In an operational setting, how is external information about what is or
is not supported useful?

The whole point of I-DO is that it provides a way for a newer instance
of the code to operationally detect what the other side can handle.

Have you actually implemented your idea?  What does it get you?  What
does it *not* get you?

> summary of what is changing.

The text of the old and new stuff is pretty small, and it's pretty easy
to see what changed.  Are you saying you have tried to implement this
and you had difficulty?

> understand why an EF needs any payload at all.

Where do you see that the minimum length is 8?  Section 4.2 (the new
section 7.5) says:

 ... The minimunm size of an Extension Field is a 32-bit word
 (4 octets),  ...

> Is that a query or response?

I don't understand your first question.  A legacy MAC is not an EF.

I don't see
https://www.ietf.org/archive/id/draft-stenn-ntp-mac-last-ef-02.txt
listed anywhere on the IETF tools document tracker.  But that's where
the MAC-EF proposal was.

As for your second, would you be happier with:

 R: 0 for "Information/Query", 1 for a "Response"

I think I'll make that change anyway.

> to link to.  I think the link should be removed.)

There is a place to link to - it's on the top of page 8.

> There are no links to sections 4.2 or 4.3 from the Table of Contents.

The draft is in XML format and uses the IETF tools.  If there's a bug in
their HTML generator please let them know.

---

From: Hal Murray <[email-masked]>
Date: Fri, 28 Sep 2018 20:41:26 -0700

[email-masked] said:
> In an operational setting, how is external information about what is or is
> not supported useful? 

It helps an admin decide if they want to use that server or not.

> The whole point of I-DO is that it provides a way for a newer instance of the
> code to operationally detect what the other side can handle.

It doesn't (yet) handle the I-DONT case.

There is still the problem of old servers that do/don't do leap smearing, so 
the idea of checking a web page or similar shouldn't be strange.

> Have you actually implemented your idea?

No.  Miroslav Lichvar's comment about updating a Correction EF complicates 
things.

> What does it get you?  What does it *not* get you?

What it gets me, is simplification of the EF/MAC handling.  I don't have to 
worry about all the kludgery to dance around MACs that might get confused with 
EFs.

More importantly, I don't have to think about it.

> Where do you see that the minimum length is 8?  Section 4.2 (the new section
> 7.5) says: 

I was reading quickly.
>    While the minimum field length of an EF that contains no value or
>    padding fields is one word (four octets), and the minimum field
>    length of an EF that contains required fields is two words (8
>    octets), ...
I saw the second half which says "required fields".  If they are required, 
then they must be there so the min length is 8.

> The text of the old and new stuff is pretty small, and it's pretty easy to
> see what changed.  Are you saying you have tried to implement this and you
> had difficulty? 
I was trying to find what it said about the minimum length.  That could be a 
simple sentence.  Instead, I have to do a manual diff.  The old section 7.5 is 
a half page.  The new is a page and a half.  Somebody could easily focus on 
the new stuff without noticing the length change.

>  R: 0 for "Information/Query", 1 for a "Response" 
I think what's missing is the idea that the Request/Response bit only applies 
to some uses.  As written, it doesn't allow for unsolicited information.

> https://www.ietf.org/archive/id/draft-stenn-ntp-mac-last-ef-02.txt

Thanks.  That seems overly complicated, but I admit I haven't thought about 
this area a lot.

Your last EF adds 4 bytes, but leaves a bare MAC.  I've been trying to think 
of ways to get rid of bare MACs.  Your MAC-EF takes 8 more bytes for a single 
MAC.

I think I'd prefer a single MAC-EF - same layout as your LAST-EF except the 
length includes the MAC.

> There is a place to link to - it's on the top of page 8.

Your "top of page 8" is in the new document.

Here is the link I was referring to:
  https://tools.ietf.org/html/rfc5905#section-7.5.1
It goes to the old RFC.  There is no section 7.5.1 in the old RFC.
There are actually 2 occurrences of that link.  One in the Table of Contents 
and a second  at the top of page 8, the header for section 4.3

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 28 Sep 2018 22:31:58 -0700

> It helps an admin decide if they want to use that server or not.

And what happens if the remote version of NTP changes between the time
an admin reads whatever happens to be on that external mechanism and "now"?

And what assurance do you have that the external mechanism has correct
information even at the moment you read it?

> It doesn't (yet) handle the I-DONT case.

The absence of I-DO should be regarded as I-DONT.

> the idea of checking a web page or similar shouldn't be strange.

What does leap smearing have to do with the overall structure of
extension fields?

> No.  Miroslav Lichvar's comment about updating a Correction EF complicates 

I don't see it.  What do you mean, and how does it apply to my proposal?

> worry about all the kludgery to dance around MACs that might get confused with 
I've already implemented this and it works just great.  It's not
complicated at all.

> More importantly, I don't have to think about it.

I don't see your point here.  Would you please expand?

> then they must be there so the min length is 8.

You're still not reading it.  If there is no payload, the minimum EF
length is 4 octets.  If there is a payload, the minimum EF length is 8.

> the new stuff without noticing the length change.

I submit the only interesting bit here is does the new text make sense,
and can an implementor be expected to be able to write working code
based on it.

The introduction of the document clearly says what the purpose of this
proposal is.

Every other time I've added explanatory text to a proposal I'm told that
I should remove that text because it's not useful long-term.

> to some uses.  As written, it doesn't allow for unsolicited information.

Then we disagree.  An R bit of 0 is clearly unsolicited information.

> Thanks.  That seems overly complicated, but I admit I haven't thought about 

It might make more sense to you if you were implementing it, and your
code had to deal with legacy and new NTP instances.

> of ways to get rid of bare MACs.  Your MAC-EF takes 8 more bytes for a single 

The way to get rid of bare MACs is to use a MAC-EF, or some other
mechanism.  But that won't work when talking to a legacy client, so you
can either dance thru hoops or use I-DO.

The MAC-EF takes 8 octets because it is preparing for the case where
multiple MACs are allowed.

It would not be hard to have a MAC-EF that only encapsulated a single
legacy MAC.  I'm not sure it's worth saving 4 octets for this case.

> I think I'd prefer a single MAC-EF - same layout as your LAST-EF except the 

OK.

> Your "top of page 8" is in the new document.

Of course it's in the new document.  The proposal is to add that new
content.

> and a second  at the top of page 8, the header for section 4.3

If the proposal is adopted, then the link will work.

I don't see the value in breaking the xref now, and then fixing it if
the proposal is passed.