Subject: Re: [ntpwg] IANA Autokey field types

From: brian utterback <[email-masked]>
Date: Fri, 10 Jun 2016 22:31:03 -0400

This needs to be fixed. Worse still, the IANA has a mixed set of formats
for extension types. The autokey RFC and the IANA values for autokey are
in agreement with two bits, a 6 bit code and an 8 bit field type. The
IANA further specifies a field type for the Checksum complement of
0x2006, which could be a code of 0x20 and a filed type of 0x06. However,
the reference implementation software actually implement the autokey
values with the code and field type swapped. Further, Harlan has
documented in the Last Ext draft, I-Do Ext draft and the Suggest REFID
Ext draft that he wants to take one bit away from the code to use to
indicate whether or not the extension has a MAC optional. He has further
said that he wants to use another bit to indicate whether or not a MAC
is actually present.

That would leave only 4 bits for the code and 8 bits for the field type
if we followed the docs, but if we follow the current implementation
those bit values are reversed, and 4 bits seem too little for the field
type.

Because the field type and code are implemented in macros in it would be
trivial to swap them in the reference implementation but it would not be
compatible with the previous versions and would break the various packet
capture programs in the world that dissect NTP packets.

Truthfully, the more I think about it the less I like the idea of using
the MAC optional and MAC present bits. Those things should be specific
to the implementation and specification of the  individual extension
fields. I don't see any value at all in having these things reflected in
the code field, and especially not the field type. If a particular
extension needs to convey that information, it should include it in the
extension data. The Autokey values (either interpretation) don't use the
bits that way and the UDP checksum requests the MAC optional bit doesn't
say that is what it means.

If we want to use the fields as documented but leave the the existing
software as is, then as Miroslav said, we need to register the other
values, mark the currently documented values as reserved but unused.
This will mean that autokey will chew up field types 0x00, 0x01, 0x02,
0x03, 0x04, 0x05, 0x06, 0x07, 0x08 and 0x09. This means that Checksum
Complement, I-Do and Suggest will need new field type numbers as well.

On 5/6/2016 8:35 AM, Miroslav Lichvar wrote:
> As more extension fields are now being proposed and new field types
> will need to be assigned, I think it would be good to address the
> issue with the IANA autokey field types not matching the types used by
> the reference implementation and avoid conflicts with newly assigned
> types.
>
> In RFC 5906 the extension field type consists of an R bit, E bit,
> 6-bit code and 8-bit version. This is what was used for for the IANA
> types. In ntpd it's R, E, 6-bit version and 8-bit code. The code and
> version are swapped. From the 30 allocated types only the tree 0x?202
> types (certificate message) actually match the types used by ntpd.
>
> What's the best way to get it fixed?
>
> I'm not sure if there are any other implementations supporting
> autokey. I assume someone would complain about this mismatch when
> testing interoperability with ntpd. Could we make a request to change
> the 27 types to the ntpd values? If not, can we ask for the missing
> types to be assigned as "private"?
>

-- 
Oracle <http://www.oracle.com>
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049 <tel:+1%206038973049>
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
------------------------------------------------------------------------
All working systems eventually start to exhibit their own agenda
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 11 Jun 2016 03:43:42 +0000

How can it possibly work if extension fields are implementation-specific
as far as the guts of each assigned field type is concerned/

H

brian utterback writes:
> This is a multi-part message in MIME format.
> --===============1034123743828004835==
> Content-Type: multipart/alternative;
>  boundary="------------090604040000060107050201"
> 
> This is a multi-part message in MIME format.
> --------------090604040000060107050201
> Content-Type: text/plain; charset=windows-1252
> Content-Transfer-Encoding: 7bit
> 
> --------------090604040000060107050201
> Content-Type: multipart/related;
>  boundary="------------070800000406020607000607"
> 
> 
> --------------070800000406020607000607
> Content-Type: text/html; charset=windows-1252
> Content-Transfer-Encoding: quoted-printable
> X-MIME-Autoconverted: from 8bit to quoted-printable by aserp1040.oracle.com i
> d u5B2VBgT009393
> 
> <html>
>   <head>
>     <meta content=3D"text/html; charset=3Dwindows-1252"
>       http-equiv=3D"Content-Type">
>   </head>
>   <body bgcolor=3D"#FFFFFF" text=3D"#000000">
>     This needs to be fixed. Worse still, the IANA has a mixed set of
>     formats for extension types. The autokey RFC and the IANA values for
>     autokey are in agreement with two bits, a 6 bit code and an 8 bit
>     field type. The IANA further specifies a field type for the Checksum
>     complement of 0x2006, which could be a code of 0x20 and a filed type
>     of 0x06. However, the reference implementation software actually
>     implement the autokey values with the code and field type swapped.
>     Further, Harlan has documented in the Last Ext draft, I-Do Ext draft
>     and the Suggest REFID Ext draft that he wants to take one bit away
>     from the code to use to indicate whether or not the extension has a
>     MAC optional. He has further said that he wants to use another bit
>     to indicate whether or not a MAC is actually present. <br>
>     <br>
>     That would leave only 4 bits for the code and 8 bits for the field
>     type if we followed the docs, but if we follow the current
>     implementation those bit values are reversed, and 4 bits seem too
>     little for the field type.<br>
>     <br>
>     Because the field type and code are implemented in macros in it
>     would be trivial to swap them in the reference implementation but it
>     would not be compatible with the previous versions and would break
>     the various packet capture programs in the world that dissect NTP
>     packets. <br>
>     <br>
>     Truthfully, the more I think about it the less I like the idea of
>     using the MAC optional and MAC present bits. Those things should be
>     specific to the implementation and specification of the=A0 individual
>     extension fields. I don't see any value at all in having these
>     things reflected in the code field, and especially not the field
>     type. If a particular extension needs to convey that information, it
>     should include it in the extension data. The Autokey values (either
>     interpretation) don't use the bits that way and the UDP checksum
>     requests the MAC optional bit doesn't say that is what it means. <br>
>     <br>
>     If we want to use the fields as documented but leave the the
>     existing software as is, then as Miroslav said, we need to register
>     the other values, mark the currently documented values as reserved
>     but unused. This will mean that autokey will chew up field types
>     0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08 and 0x09. This
>     means that Checksum Complement, I-Do and Suggest will need new field
>     type numbers as well. <br>
>     <br>
>     <div class=3D"moz-cite-prefix">On 5/6/2016 8:35 AM, Miroslav Lichvar
>       wrote:<br>
>     </div>
>     <blockquote cite=3D"mid:20160506123528.GA5044@localhost" type=3D"cite=
> ">
>       <pre wrap=3D"">As more extension fields are now being proposed and =
> new field types
> </pre>
>     </blockquote>
>     <br>
>     <div class=3D"moz-signature">-- <br>
>       <a href=3D"http://www.oracle.com" target=3D"_blank"><img
>           src=3D"cid:[email-masked]" alt=3D"Oracle"
>           border=3D"0" height=3D"26" width=3D"114"></a><br>
>       <font color=3D"#666666" size=3D"2" face=3D"Verdana, Arial, Helvetic=
> a,
>         sans-serif">Brian Utterback | Principal Software Engineer<br>
>         Phone: <a href=3D"tel:+1%206038973049" moz-do-not-send=3D"true">+=
> 1
>           6038973049</a> <br>
>         <font color=3D"#ff0000">Oracle</font> Systems/RPE Solaris Network=
> <br>
>         1 Oracle Dr. | Nashua, NH 03062</font>
>       <br>
>       <hr>
>       All working systems eventually start to exhibit their own agenda<br=
> >
>       <hr>
>       <a href=3D"http://www.oracle.com/commitment" target=3D"_blank"><img
>           src=3D"cid:[email-masked]" alt=3D"Green
>           Oracle" align=3D"absmiddle" border=3D"0" height=3D"28" width=3D=
> "44"></a>
>       <font color=3D"#4B7D42" size=3D"1" face=3D"Verdana, Arial, Helvetic=
> a,
>         sans-serif">Oracle is committed to developing practices and
>         products that help protect the environment</font>
>       <!-- This signature was generated by the MyDesktop Oracle Business =
> Signature utility version 5.0 -->
>     </div>
>   </body>
> </html>
> 
> --------------070800000406020607000607
> Content-Type: image/gif;
>  name="oracle_sig_logo.gif"
> Content-ID: <[email-masked]>
> Content-Disposition: inline;
>  filename="oracle_sig_logo.gif"
> Content-Transfer-Encoding: base64
> 
> R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9A
> QP/AwP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> ACH5BAAAAAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPV
> IDfcOQa6A8yRaO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1n
> BGRmhl8AWiUJYicCAIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4
> AAunsqg/dw95KwdfBgzBqKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1It
> xK7aKl8lCl8DAfALW1+2rUi3QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyI
> qRgMcA8a/z5AZQWXOxEdHxwUgfIgsX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjU
> mYLnomokcDlS4s0eFzQNqvXDEyzmAwFPyaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpF
> RxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt
> 1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvPm8OVEkAIYLYPThSsRIpEQJr1x94QBIT0
> 9FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8ABijggAQWaOCBCCao4A+CDDbo4IMQ
> RijhhBQKGAIAOw==
> --------------070800000406020607000607
> Content-Type: image/gif;
>  name="green-for-email-sig_0.gif"
> Content-ID: <[email-masked]>
> Content-Disposition: inline;
>  filename="green-for-email-sig_0.gif"
> Content-Transfer-Encoding: base64
> 
> R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zP
> uZu2lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> ACH5BAAAAAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxj
> SYdrOp/Q6NPgYqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMq
> DwFCAAIFPIYDgidrOUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQG
> BH82TpMicD0pAgQACToDAchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLD
> LS8MAvf497ruCZ+gOA0gfNt3AIK0J/JWKVzIsEQIADs=
> --------------070800000406020607000607--
> 
> --------------090604040000060107050201--
> 
> --===============1034123743828004835==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============1034123743828004835==--
>

---

From: Brian Utterback <[email-masked]>
Date: Sat, 11 Jun 2016 07:57:43 -0400

No, that's not what I am saying. What I am saying is that the 
specification for an extension already needs to say that a MAC is 
required for that extension, forbidden for that extension or optional. 
Those are the three possibilities and already we see the a problem of 
adding a single bit for them, three possibilities and only twp bit states.

So, if a MAC is optional for an extension field, there are two 
possibilities, either the extension field is agnostic towards MACs or it 
sometimes needs them and sometimes does not. If it is agnostic then that 
fact should be in the spec.

Now, if the extension field sometimes requires a MAC and sometimes does 
not, then there is some determining factor to that and again we have 
three possible states for the requirements of the field, i.e. MAC 
required, MAC forbidden or MAC agnostic. These requirements are set by 
the needs of the extension field itself, possibly determined by some 
state it is in. The autokey field always requires a MAC, but we might 
imagine a replacement (NTS perhaps?) that does not require a MAC 
initially because there is no shared secret to make one possible, but 
later on does require it once a shared secret is generated. The 
extension field processing knows what the current state is and whether 
or not there should be a MAC. And if that is not the case, (e.g. autokey 
not maintaining state on the server) then the requirement of a MAC or 
not is probably determined by what the subtype (code) is in the 
extension field. And finally, if that is not so and it really does need 
to convey this information, then the extension field spec merely has to 
steal a bit from the code field.

All of which presents another possible solution to our IANA problem or 
at least suggests which solution is better. While it would be better to 
keep the field type at 8 bits and the code at 6, I think that a 6 bit 
field type is probably enough to get us through to protocol 5.0. I don't 
think four bits will do it. In particular because we can used a modified 
version of the previously discussed "packing" extension that would allow 
us to have a special extension field that contains other extension 
fields, but these might have a different extension type space if we 
really needed to do it.

All working systems eventually show their own agendas.

---

From: brian utterback <[email-masked]>
Date: Sat, 11 Jun 2016 09:42:03 -0400

Does it make sense to enumerate all possible extension field types in
response to an I-Do request, or is just the type and code enough,
ignoring the req/resp/error bits (and whatever other bits we decide on,
if any) or just the type, ignoring the code?

In other words, using the problematic IANA field types for autokey as an
example, should an I-Do response from a system that does autokey need to
list all thirty field type values, or should it list the nine different
type/code values, or is just the 0x02 type value enough?

On 6/11/2016 7:57 AM, Brian Utterback wrote:
> possibilities, either the extension field is agnostic towards MACs or
> it sometimes needs them and sometimes does not. If it is agnostic then
> that fact should be in the spec.
>
> Now, if the extension field sometimes requires a MAC and sometimes
> does not, then there is some determining factor to that and again we
> have three possible states for the requirements of the field, i.e. MAC
> or not there should be a MAC. And if that is not the case, (e.g.
> autokey not maintaining state on the server) then the requirement of a
> MAC or not is probably determined by what the subtype (code) is in the
> extension field. And finally, if that is not so and it really does
> need to convey this information, then the extension field spec merely
> has to steal a bit from the code field.
>
> at least suggests which solution is better. While it would be better
> to keep the field type at 8 bits and the code at 6, I think that a 6
> bit field type is probably enough to get us through to protocol 5.0. I
> don't think four bits will do it. In particular because we can used a
> modified version of the previously discussed "packing" extension that
> would allow us to have a special extension field that contains other
> extension fields, but these might have a different extension type
> space if we really needed to do it.
>
>

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 12 Jun 2016 03:37:41 +0000

> type/code values, or is just the 0x02 type value enough?

So far, it looks like we only need the the base Field Type.

H

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 13 Jun 2016 08:31:08 +0000

> adding a single bit for them, three possibilities and only twp bit states.

I don't yet see the need for more than 2 states, required and optional.

I know Tal's "checksum complement" requires no MAC.  But if that
proposal is implemented as-is (remember, it's experimental) and used
it's perfectly fine to use the MAC-OPTIONAL flag for this case because
the sending NTP instance will *know* that the checksum complement EF
will be used, so it will know that it should not include a MAC.

I'm not saying there is no value to allowing the 3 cases, I'm just not
seeing a use for it now, and I'm having a hard time seeing the need for
it later, as the packet is being built by the sender so the sender knows
what can and can't be done.

> fact should be in the spec.

The bit indicates REQUIRED or OPTIONAL.  If it's needed, it's REQUIRED.
If it's not needed, it's OPTIONAL.  When building the EFs for the
packet, the appropriate bits are chosen.

> extension field.

The described Field Types for NTS already accomodate this.

The same is true for the other EFs I've proposed.

And if NTS is negotiated as part of the NTP exchange process, one has
the option of using symmetric key to provide authentication until NTS
has the authentication process negotiated.

> And finally, if that is not so and it really does need 

Yes.

> fields, but these might have a different extension type space if we 

I asked Dieter, et al, if NTS wanted to use codes or not, and the answer
was "No, that functionality of that is included inside the NTS EF, and
carrying that information in the EF header is not needed."

Autokey uses 9 codes.

So, again, it's not looking like we'll need more codes.

Right now, my list of EFs includes:

0x0002  Autokey
0x0003  MAC extension field
0x0004  NTS
0x0005  Checksum Complement
0x0006  Suggest REFID
0x0007  I Do
0x0008  Last Extension/Legacy MAC follows

0x8000  Response (Autokey, I Do)
0x4000  Error (Autokey)
0x2000  MAC not required
0x1000  MAC included

which leaves 4 bits for the "code" (which is only used by Autokey).
This may be enough, it may not.  Who can say.  But 16 codes seems to be
plenty for now.  If not, we can likely take bits from the the top of the
Field Type.

We have 8 bits for the Field Type.  This looks to be way more than we
need, as we're currently using 8 out of the possible 256.  I don't see
us using that many more of these, so the top bits are available should
we need them for codes.

H
--

> --------------0BB5E1BCFE604A88DAD0B02F
>     <meta content="text/html; charset=windows-1252"
>       http-equiv="Content-Type">
>   </head>
>   <body bgcolor="#FFFFFF" text="#000000">
>     <div class="moz-cite-prefix">No, that's not what I am saying. What I
>       am saying is that the specification for an extension already needs
>       to say that a MAC is required for that extension, forbidden for
>       that extension or optional. Those are the three possibilities and
>       already we see the a problem of adding a single bit for them,
>       three possibilities and only twp bit states.<br>
>       <br>
>       possibilities, either the extension field is agnostic towards MACs
>       or it sometimes needs them and sometimes does not. If it is
>       agnostic then that fact should be in the spec. <br>
>       <br>
>       does not, then there is some determining factor to that and again
>       we have three possible states for the requirements of the field,
>       i.e. MAC required, MAC forbidden or MAC agnostic. These
>       requirements are set by the needs of the extension field itself,
>       possibly determined by some state it is in. The autokey field
>       always requires a MAC, but we might imagine a replacement (NTS
>       perhaps?) that does not require a MAC initially because there is
>       no shared secret to make one possible, but later on does require
>       it once a shared secret is generated. The extension field
>       processing knows what the current state is and whether or not
>       there should be a MAC. And if that is not the case, (e.g. autokey
>       not maintaining state on the server) then the requirement of a MAC
>       or not is probably determined by what the subtype (code) is in the
>       need to convey this information, then the extension field spec
>       merely has to steal a bit from the code field. <br>
>       <br>
>       All of which presents another possible solution to our IANA
>       problem or at least suggests which solution is better. While it
>       would be better to keep the field type at 8 bits and the code at
>       6, I think that a 6 bit field type is probably enough to get us
>       through to protocol 5.0. I don't think four bits will do it. In
>       particular because we can used a modified version of the
>       previously discussed "packing" extension that would allow us to
>       have a special extension field that contains other extension
>       fields, but these might have a different extension type space if
>       we really needed to do it. <br>
>       <br>
>       <br>
>       On 6/10/2016 11:43 PM, Harlan Stenn wrote:<br>
>     </div>
>     <blockquote cite="mid:[email-masked]" type="cite">
>       <pre wrap="">How can it possibly work if extension fields are implement
> ation-specific
>       <blockquote type="cite">
>         <pre wrap="">This is a multi-part message in MIME format.
>         <blockquote type="cite">
>           <pre wrap="">As more extension fields are now being proposed and ne
> w field types
>         <pre wrap="">
> Oracle <a class="moz-txt-link-rfc2396E" href="http://www.oracle.com">&lt;http
> ://www.oracle.com&gt;</a>
> Phone: +1 6038973049 <a class="moz-txt-link-rfc2396E" href="tel:+1%2060389730
> 49">&lt;tel:+1%206038973049&gt;</a>
> Green Oracle <a class="moz-txt-link-rfc2396E" href="http://www.oracle.com/com
> mitment">&lt;http://www.oracle.com/commitment&gt;</a> Oracle is committed to
> &lt;html&gt;
>   &lt;head&gt;
>     &lt;meta content=3D"text/html; charset=3Dwindows-1252"
>       http-equiv=3D"Content-Type"&gt;
>   &lt;/head&gt;
>   &lt;body bgcolor=3D"#FFFFFF" text=3D"#000000"&gt;
>     to indicate whether or not a MAC is actually present. &lt;br&gt;
>     &lt;br&gt;
>     little for the field type.&lt;br&gt;
>     &lt;br&gt;
>     packets. &lt;br&gt;
>     &lt;br&gt;
>     requests the MAC optional bit doesn't say that is what it means. &lt;br&g
> t;
>     &lt;br&gt;
>     type numbers as well. &lt;br&gt;
>     &lt;br&gt;
>     &lt;div class=3D"moz-cite-prefix"&gt;On 5/6/2016 8:35 AM, Miroslav Lichva
> r
>       wrote:&lt;br&gt;
>     &lt;/div&gt;
>     &lt;blockquote cite=3D"mid:20160506123528.GA5044@localhost" type=3D"cite=
> "&gt;
>       &lt;pre wrap=3D""&gt;As more extension fields are now being proposed an
> d =
> new field types
> &lt;/pre&gt;
>     &lt;/blockquote&gt;
>     &lt;br&gt;
>     &lt;div class=3D"moz-signature"&gt;-- &lt;br&gt;
>       &lt;a href=3D<a class="moz-txt-link-rfc2396E" href="http://www.oracle.c
> om">"http://www.oracle.com"</a> target=3D"_blank"&gt;&lt;img
>           src=3D<a class="moz-txt-link-rfc2396E" href="cid:part1.03040504.070
> [email-masked]">"cid:[email-masked]"</a> alt=3D"Oracle"
>           border=3D"0" height=3D"26" width=3D"114"&gt;&lt;/a&gt;&lt;br&gt;
>       &lt;font color=3D"#666666" size=3D"2" face=3D"Verdana, Arial, Helvetic=
> a,
>         sans-serif"&gt;Brian Utterback | Principal Software Engineer&lt;br&gt
> ;
>         Phone: &lt;a href=3D<a class="moz-txt-link-rfc2396E" href="tel:+1%206
> 038973049">"tel:+1%206038973049"</a> moz-do-not-send=3D"true"&gt;+=
> 1
>           6038973049&lt;/a&gt; &lt;br&gt;
>         &lt;font color=3D"#ff0000"&gt;Oracle&lt;/font&gt; Systems/RPE Solaris
>  Network=
> &lt;br&gt;
>         1 Oracle Dr. | Nashua, NH 03062&lt;/font&gt;
>       &lt;br&gt;
>       &lt;hr&gt;
>       All working systems eventually start to exhibit their own agenda&lt;br=
> </pre>
>         <blockquote type="cite">
>           <pre wrap="">
> </pre>
>         </blockquote>
>         <pre wrap="">      &lt;hr&gt;
>       &lt;a href=3D<a class="moz-txt-link-rfc2396E" href="http://www.oracle.c
> om/commitment">"http://www.oracle.com/commitment"</a> target=3D"_blank"&gt;&l
> t;img
>           src=3D<a class="moz-txt-link-rfc2396E" href="cid:part4.09000206.090
> [email-masked]">"cid:[email-masked]"</a> alt=3D"Green
> "44"&gt;&lt;/a&gt;
>       &lt;font color=3D"#4B7D42" size=3D"1" face=3D"Verdana, Arial, Helvetic=
> a,
>         sans-serif"&gt;Oracle is committed to developing practices and
>         products that help protect the environment&lt;/font&gt;
>       &lt;!-- This signature was generated by the MyDesktop Oracle Business =
> Signature utility version 5.0 --&gt;
>     &lt;/div&gt;
>   &lt;/body&gt;
> &lt;/html&gt;
> 
> Content-ID: <a class="moz-txt-link-rfc2396E" href="mailto:part1.03040504.0708
> [email-masked]">&lt;[email-masked]&gt;</a>
> Content-ID: <a class="moz-txt-link-rfc2396E" href="mailto:part4.09000206.0900
> [email-masked]">&lt;[email-masked]&gt;</a>
> <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">ntpwg@l
> ists.ntp.org</a>
> <a class="moz-txt-link-freetext" href="http://lists.ntp.org/listinfo/ntpwg">h
> ttp://lists.ntp.org/listinfo/ntpwg</a>
>     <p><br>
>     </p>
>     <div class="moz-signature">-- <br>
>       <a href="http://www.oracle.com" target="_blank"> <img
>           src="http://www.oracle.com/us/design/oracle-email-sig-198324-355094
> .jpg"
>           moz-do-not-send="true" alt="Oracle" height="26" border="0"
>           width="114"> </a><br>
>       <font face="Verdana, Arial, Helvetica, sans-serif" color="#666666"
>         size="2">Brian Utterback | Principal Software Engineer<br>
>         Phone: <a href="tel:+1%206038973049" moz-do-not-send="true">+1
>           6038973049</a> <br>
>         <font color="#ff0000">Oracle</font> Systems/RPE Solaris Network<br>
>         1 Oracle Dr. | Nashua, NH 03062</font> <br>
>       <hr> All working systems eventually show their own agendas.
>       <hr> <a href="http://www.oracle.com/commitment" target="_blank">
>         <img
>           src="http://www.oracle.com/us/design/green-sig-275518-355092.jpg"
>           moz-do-not-send="true" alt="Green Oracle" height="28"
>           align="absmiddle" border="0" width="44"> </a> <font
>         face="Verdana, Arial, Helvetica, sans-serif" color="#4B7D42"
>         size="1">Oracle is committed to developing practices and
>         products that help protect the environment</font></div>
>   </body>
> </html>
> 
> --------------0BB5E1BCFE604A88DAD0B02F--
>

---

From: brian utterback <[email-masked]>
Date: Mon, 13 Jun 2016 18:52:15 -0400

> us using that many more of these, so the top bits are available should

(Having a bit for "MAC not required" seems counter intuitive to me. Is
that to remain consistent with autokey? Whatever.)

Except it doesn't which brings us back around to the IANA problem
Miroslav brought up in the first place.

The current autokey implementation does not use 0x0002, it uses 0x0200.

Here's how I see it. For each extension we have one word of information,
which includes a length and something else. In ideal world the length
information is the only thing that should be necessary to determine if
the packet is well formed. The chain of lengths ends at the end of the
packet then it is well formed, and not if it doesn't. We'll ignore the
MAC for the time being, that isn't this discussion.

Now, again in an ideal world the "something else" would include only
enough information to identify the type of the extension and whatever
other information is necessary for the processing of the packet
independent of the type of the extension field. All other state
information that is specific to an extension field should be internal to
the field. Thus I think that it was a mistake to have a request/response
bit and the good/error bit, since none of those change the handling of
the packet independent of the current state of the autokey extension field.

Now, that having been said, I think it might be possible to make a case
for a MAC Not Required bit, since that would mean that a packet that had
an extension with the MAC Not Required bit unset which did not actually
have a MAC would be ill-formed and could invoke whatever action that
entails.

Now, a one bit in the MAC Not Required bit field would essentially
indicate "don't care". Not all extensions will have a don't care
possibility and we need to make it clear which one do and don't. So, I
unlike the Req/Resp and Err bits, we should make the MAC Not Required
part of the type field. Thus a field that never cares would register
0x200n with the IANA, but not 0x000n and during processing would reject
0x000n, which differs from the Req/Res/Err bits. If a field sometimes
requires a MAC and sometimes doesn't care then then it would register
both numbers.

I don't see the purpose of the MAC Included bit. I could see it down in
the regular packet to indicate whether or not a legacy mac is on this
packet, but what does it do for us as part of the extension header? If a
MAC is required then it is there. If it is not required then the MAC is
or isn't there but the field doesn't need it. If the field sometimes
needs it and sometimes doesn't then it should just use the MAC Required
form.

As far as the code goes, it was a big mistake to have the code be part
of this field at all. It is information that is entirely internal to
each individual extension field and like the legacy MAC field has left
us with a mess to work around. Autokey uses a four bit code which isn't
too bad, but unfortunately it put them the low order bits instead of the
high order bits. If we take the bottom four bits as the code, then we
have to change all of the other field types and start assigning them
consistently with the autokey type in the second four bits. Or we could
treat autokey as a special case and eliminate the concept of a code
going forward, but then implementing it is a mess.
-- 
Oracle <http://www.oracle.com>
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049 <tel:+1%206038973049>
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
------------------------------------------------------------------------
All working systems eventually start to exhibit their own agenda
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Mon, 13 Jun 2016 22:06:57 -0400

> that to remain consistent with autokey? Whatever.)

There is no point to MAC not required or optional flag. That means it
doesn't matter so why bother? If the MAC is there, it doesn't matter and
if it's not there it still doesn't matter.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 14 Jun 2016 07:08:26 +0000

> if it's not there it still doesn't matter.

Danny, please support your position.

You know I think you are completely wrong on your position.

H

---

From: Danny Mayer <[email-masked]>
Date: Tue, 14 Jun 2016 06:10:26 -0400

> Danny, please support your position.

I just did. It makes no difference whether or not a MAC is present for
the extension field. I've seen no use case where such a flag is needed.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 14 Jun 2016 18:06:55 +0000

Danny,

You and I are going in circles on this.  I'm not seeng anything new.

Let's agree to disagree.

H
--

---

From: brian utterback <[email-masked]>
Date: Tue, 14 Jun 2016 14:51:34 -0400

> You and I are going in circles on this.  I'm not seeng anything new.

No, no, no, no! You can't agree to disagree on what an RFC is or should
mean!

We currently have a mess, with some bad choices made in the past and
multiple contradictory attempts being made to fix it. It is not too late
to change the RFCs and drafts, but it is incumbent upon us find the
cleanest solution to codify that doesn't break existing implementations
or if it does break them, that does the least damage.

So, that having been said, I have to agree with Danny that the burden of
proof is on you Harlan, what is the use case for the proposed new two bits?

As I said, the only case I could come up with is just that it makes it
more convenient for the implementation to determine if a packet is well
formed, which is kind of weak. I know of no use case at all for the
Req/Resp bit and the Error bit. If there is no use case for them, then
we should lock in the current 30 Autokey IANA values and just call them
opaque. If there is a good use case then we must codify their use.
Anything we say works one way that we fail to codify risks being broken
further down the road. Let's clean up the mess and not smear it around.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 14 Jun 2016 22:02:40 -0400

> You and I are going in circles on this.  I'm not seeng anything new.

I am trying to help you. I need to see a use case where such an option
would be helpful, useful or some other reason. Since you haven't
advanced a reason for it it is hard to see why it is needed. You really
need to answer that.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 15 Jun 2016 02:10:59 +0000

> advanced a reason for it it is hard to see why it is needed. You really

I'm pretty sure I've covered this clearly many times.  At least as
clearly as I know how.

Please re-read the archives and ask any specific questions you might
have.

H

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 15 Jun 2016 02:14:50 +0000

Danny Mayer writes:
> would be helpful, useful or some other reason.

And to be crystal clear:

> Since you haven't

I have done the above MANY times.

I'm done repeating myself to you.

H

---

From: brian utterback <[email-masked]>
Date: Wed, 15 Jun 2016 17:48:27 -0400

I have just spent several hours going through all 112 messages you sent
to the NTPWG mailing list over the last 15 months. With all due respect,
you have been overtly vague every time someone asked you to explain what
you meant but have demanded exact bits and use cases every time some one
said they thought what you were saying wouldn't work. You may have a
wonderful idea of how everything is supposed to work in your head and
truthfully I have a better understanding of your thinking now because
there are hints strewn throughout the emails, but I am not totally sure
because they are not all consistent (I think your thoughts evolved over
time). However, you have not articulated that idea to the rest of us in
a way we can understand. Perhaps we are just too dumb to follow your
thinking, but since we are talking about what the RFCs should say, it is
a requirement that it be set down in a way that anyone can understand
reading the RFC and does require them to sift through the mail archives.

That having been said, I have no desire to pile on you at this point, my
only desire is to fix the mess we have now and find the way forward. We
need a way to capture the current consensus at any point in time. The
email archives is clearly inadequate to the task. Does anyone have any
idea on how to collaborate on this? I don't think we have a real
consensus on anything so does anyone feel that they cannot in good
conscience participate in such a collaboration at this point, even if it
means rehashing some things?

---

From: brian utterback <[email-masked]>
Date: Sat, 18 Jun 2016 22:53:58 -0400

Okay, I think I understand now what the purpose of the two new bits is.
However, before I get to that, I would like to address the IANA problem.

We currently have thirty IANA NTP Field extension types reserved that
are not in use by anyone and we have failed to reserve the 30 field
types that are actually in use by autokey. This needs to be rectified.

Rather than just trade the thirty existing for the thirty correct
values, I have a different proposal. I propose that we just reserve the
entire namespace of 0xn2nn (i.e. a two in the second nybble, any other
values for the other three) for use by autokey and say that autokey will
use them however it does now. While this chews up a sixteenth of the bit
space of the extension field type, it completely frees up the rest of
the bit space from preexisting formats.

If we do that, we no longer have to be backwards compatible with the
other bits and allows us to decide what bits, if any, we want to include
in the extension field type.

We know that autokey already used the first two bits. The first was used
to indicate a request or response and the second to indicate an error
return. To me, this seems like a layer violation. These bits provide no
information that is useful above the layer of processing the individual
extension field, that is, while they are generic they don't provide
information that changes the processing of the packet or extensions
fields or MAC above the individual extension processing layer and should
therefore be included internally to the extension field itself, if such
information is appropriate for an individual extension field.

Now, considering the two new proposed bits, "MAC not required" and "MAC
included", I see some utility here, but I think they are somewhat
misnamed. The name "MAC not required" bothers me for its double negative
quality. I realize that it was chosen to be that way to make it
consistent with autokey, but as I said before, we don't need to be
consistent with autokey. We can choose it to be whatever makes the most
sense. I would this prefer "MAC required", but I could live with it the
other way I suppose.

The "MAC Included" bit I would instead call "Field acts as MAC". It took
me quite some time to figure this bit out because the other name is
unclear as to the intention, but eventually I found an email that
explained it.

Now, the thing is, these two bits together do allow the required
presence of a MAC field a feature of well-formedness even for extension
fields that are not known. But truthfully I see little utility in this.
A little, but not much. When MAC functionality is provided by an unknown
extension field, it might as well not be there at all, since it cannot
be processed and the MAC function verified. For extension fields we do
know about we either know from the specs whether a field does or does
not require a MAC, and whether or not it can provide one or if both of
those states differ at different states of the extension field, the
field itself needs to be processed to see which state is required.

On the other hand, the fact that a field might act as a MAC is perhaps
useful to know. We might want to process fields that can provide the MAC
functionality prior to processing the others so that we know going in
whether or not there is a valid MAC for a given extension field. To make
this work though, care will be needed in defining the behavior of the bit.

That all having been said, if we do what I said before and carve out the
space for autokey and completely do away with the concept of the "code"
being in this field, then I do not feel strongly about keeping or
getting rid of any or all of these bits. The current idea of the code
and type break down and the four bits left the bit space very disjoint.
Without the code the bitspace is clean again, except for the autokey
slice, which we pretty much had to have anyway. I have spoken to Danny
and Miroslav offline and they expressed their desire to get rid of all
of the bits. For the reason I gave above, I'd  like to get rid of at
least the Req/Resp and Error bits, and possibly the other two as well.
Does anyone have anything else to add?

On 6/15/2016 5:48 PM, brian utterback wrote:
> I have just spent several hours going through all 112 messages you
> sent to the NTPWG mailing list over the last 15 months. With all due
> respect, you have been overtly vague every time someone asked you to
> explain what you meant but have demanded exact bits and use cases
> every time some one said they thought what you were saying wouldn't
> work. You may have a wonderful idea of how everything is supposed to
> work in your head and truthfully I have a better understanding of your
> thinking now because there are hints strewn throughout the emails, but
> I am not totally sure because they are not all consistent (I think
> your thoughts evolved over time). However, you have not articulated
> that idea to the rest of us in a way we can understand. Perhaps we are
> just too dumb to follow your thinking, but since we are talking about
> what the RFCs should say, it is a requirement that it be set down in a
> way that anyone can understand reading the RFC and does require them
> to sift through the mail archives.
>
> That having been said, I have no desire to pile on you at this point,
> my only desire is to fix the mess we have now and find the way
> forward. We need a way to capture the current consensus at any point
> in time. The email archives is clearly inadequate to the task. Does
> anyone have any idea on how to collaborate on this? I don't think we
> have a real consensus on anything so does anyone feel that they cannot
> in good conscience participate in such a collaboration at this point,
> even if it means rehashing some things?
>

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 19 Jun 2016 03:39:14 +0000

Brian,

I'm swamped still, so this will be quick.

Glad to hear you see where I'm coming from.

I don't yet see a need for the ERROR bit beyond Autokey.  But Autokey is
part of NTPv4.  If we find no more use for an ERROR bit, we can move
things up by a bit in NTPv5.

The RESPONSE bit is used by both Autokey and I-DO.

For NTPv4, I'm not terribly worried about the layout issues.

We currently use 9 codes for Autokey, and it will be trivial to document
them.  I'm going to try and get this done in time for the upcoming IETF
meeting.

H
--
brian utterback writes:
> --------------010507030601050909050504
> --------------010507030601050909050504
>  boundary="------------040401000903010705060706"
> 
> 
> --------------040401000903010705060706
> d u5J2s8Wn012500
>     Okay, I think I understand now what the purpose of the two new bits
>     is. However, before I get to that, I would like to address the IANA
>     problem. <br>
>     <br>
>     We currently have thirty IANA NTP Field extension types reserved
>     that are not in use by anyone and we have failed to reserve the 30
>     field types that are actually in use by autokey. This needs to be
>     rectified. <br>
>     <br>
>     values, I have a different proposal. I propose that we just reserve
>     the entire namespace of 0xn2nn (i.e. a two in the second nybble, any
>     other values for the other three) for use by autokey and say that
>     autokey will use them however it does now. While this chews up a
>     sixteenth of the bit space of the extension field type, it
>     completely frees up the rest of the bit space from preexisting
>     formats. <br>
>     <br>
>     other bits and allows us to decide what bits, if any, we want to
>     include in the extension field type. <br>
>     <br>
>     We know that autokey already used the first two bits. The first was
>     used to indicate a request or response and the second to indicate an
>     error return. To me, this seems like a layer violation. These bits
>     provide no information that is useful above the layer of processing
>     the individual extension field, that is, while they are generic they
>     don't provide information that changes the processing of the packet
>     or extensions fields or MAC above the individual extension
>     processing layer and should therefore be included internally to the
>     extension field itself, if such information is appropriate for an
>     individual extension field. <br>
>     <br>
>     Now, considering the two new proposed bits, "MAC not required" and
>     "MAC included", I see some utility here, but I think they are
>     somewhat misnamed. The name "MAC not required" bothers me for its
>     double negative quality. I realize that it was chosen to be that way
>     to make it consistent with autokey, but as I said before, we don't
>     need to be consistent with autokey. We can choose it to be whatever
>     makes the most sense. I would this prefer "MAC required", but I
>     could live with it the other way I suppose.<br>
>     <br>
>     The "MAC Included" bit I would instead call "Field acts as MAC". It
>     took me quite some time to figure this bit out because the other
>     name is unclear as to the intention, but eventually I found an email
>     that explained it. <br>
>     <br>
>     presence of a MAC field a feature of well-formedness even for
>     extension fields that are not known. But truthfully I see little
>     utility in this. A little, but not much. When MAC functionality is
>     provided by an unknown extension field, it might as well not be
>     there at all, since it cannot be processed and the MAC function
>     verified. For extension fields we do know about we either know from
>     the specs whether a field does or does not require a MAC, and
>     whether or not it can provide one or if both of those states differ
>     at different states of the extension field, the field itself needs
>     to be processed to see which state is required. <br>
>     <br>
>     On the other hand, the fact that a field might act as a MAC is
>     perhaps useful to know. We might want to process fields that can
>     provide the MAC functionality prior to processing the others so that
>     we know going in whether or not there is a valid MAC for a given
>     extension field. To make this work though, care will be needed in
>     defining the behavior of the bit.<br>
>     <br>
>     That all having been said, if we do what I said before and carve out
>     the space for autokey and completely do away with the concept of the
>     "code" being in this field, then I do not feel strongly about
>     keeping or getting rid of any or all of these bits. The current idea
>     of the code and type break down and the four bits left the bit space
>     very disjoint. Without the code the bitspace is clean again, except
>     for the autokey slice, which we pretty much had to have anyway. I
>     have spoken to Danny and Miroslav offline and they expressed their
>     desire to get rid of all of the bits. For the reason I gave above,
>     I'd=A0 like to get rid of at least the Req/Resp and Error bits, and
>     possibly the other two as well. Does anyone have anything else to
>     add?<br>
>     <br>
>     <div class=3D"moz-cite-prefix">On 6/15/2016 5:48 PM, brian utterback
>       wrote:<br>
>     </div>
>     <blockquote cite=3D"mid:[email-masked]" type=3D"cite">
>       sent to the NTPWG mailing list over the last 15 months. With all
>       due respect, you have been overtly vague every time someone asked
>       you to explain what you meant but have demanded exact bits and use
>       cases every time some one said they thought what you were saying
>       wouldn't work. You may have a wonderful idea of how everything is
>       supposed to work in your head and truthfully I have a better
>       understanding of your thinking now because there are hints strewn
>       throughout the emails, but I am not totally sure because they are
>       not all consistent (I think your thoughts evolved over time).
>       However, you have not articulated that idea to the rest of us in a
>       way we can understand. Perhaps we are just too dumb to follow your
>       thinking, but since we are talking about what the RFCs should say,
>       it is a requirement that it be set down in a way that anyone can
>       understand reading the RFC and does require them to sift through
>       the mail archives. <br>
>       <br>
>       That having been said, I have no desire to pile on you at this
>       point, my only desire is to fix the mess we have now and find the
>       way forward. We need a way to capture the current consensus at any
>       point in time. The email archives is clearly inadequate to the
>       task. Does anyone have any idea on how to collaborate on this? I
>       don't think we have a real consensus on anything so does anyone
>       feel that they cannot in good conscience participate in such a
>       collaboration at this point, even if it means rehashing some
>       things? <br>
>       <br>
>       <div class=3D"moz-cite-prefix">On 6/14/2016 10:10 PM, Harlan Stenn
>         wrote:<br>
>       </div>
>       <blockquote cite=3D"mid:[email-masked]" type=3D"ci=
> te">
>         <pre wrap=3D"">Danny Mayer writes:
> </pre>
>         <blockquote type=3D"cite">
>           <pre wrap=3D"">On 6/14/2016 2:06 PM, Harlan Stenn wrote:
> </pre>
>           <blockquote type=3D"cite">
>             <pre wrap=3D"">Danny,
> 
>           <pre wrap=3D"">I am trying to help you. I need to see a use cas=
> e where such an option
>         <pre wrap=3D"">I'm pretty sure I've covered this clearly many tim=
> es.  At least as
> clearly as I know how.
> 
>         <a moz-do-not-send=3D"true" href=3D"http://www.oracle.com"
>           target=3D"_blank"><img
>             src=3D"cid:[email-masked]" alt=3D"Oracle"
>         <font size=3D"2" color=3D"#666666" face=3D"Verdana, Arial, Helvet=
> ica,
>           Phone: <a href=3D"tel:+1%206038973049" moz-do-not-send=3D"true"=
> >+1
> 
>             6038973049</a> <br>
>           <font color=3D"#ff0000">Oracle</font> Systems/RPE Solaris
>           Network<br>
>         <hr> All working systems eventually start to exhibit their own
>         agenda<br>
>         <hr> <a moz-do-not-send=3D"true"
>           href=3D"http://www.oracle.com/commitment" target=3D"_blank"><im=
> g
>             src=3D"cid:[email-masked]" alt=3D"Green
>         <font size=3D"1" color=3D"#4B7D42" face=3D"Verdana, Arial, Helvet=
> ica,
>         <!-- This signature was generated by the MyDesktop Oracle Busines=
> s Signature utility version 5.0 -->
>       </div>
>       <br>
>       <fieldset class=3D"mimeAttachmentHeader"></fieldset>
>       <br>
>       <pre wrap=3D"">_______________________________________________
> ntpwg mailing list
> <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]"=
> >[email-masked]</a>
> <a class=3D"moz-txt-link-freetext" href=3D"http://lists.ntp.org/listinfo/=
> ntpwg">http://lists.ntp.org/listinfo/ntpwg</a></pre>
>     </blockquote>
>     <br>
>           src=3D"cid:[email-masked]" alt=3D"Oracle"
>       <font size=3D"2" color=3D"#666666" face=3D"Verdana, Arial, Helvetic=
> a,
>           src=3D"cid:[email-masked]" alt=3D"Green
>       <font size=3D"1" color=3D"#4B7D42" face=3D"Verdana, Arial, Helvetic=
> a,
> --------------040401000903010705060706
> Content-Type: image/gif
> Content-ID: <[email-masked]>
> --------------040401000903010705060706
> Content-Type: image/gif
> Content-ID: <[email-masked]>
> --------------040401000903010705060706
> Content-Type: image/gif;
> Content-ID: <[email-masked]>
> --------------040401000903010705060706
> Content-Type: image/gif;
> Content-ID: <[email-masked]>
> --------------040401000903010705060706--
> 
> --------------010507030601050909050504--
>

---

From: brian utterback <[email-masked]>
Date: Sun, 19 Jun 2016 08:44:33 -0400

> The RESPONSE bit is used by both Autokey and I-DO.

Actually it isn't used by I-DO. As the RFC is currently written it is
specified but elicits no documented change in behavior. Did you intend
something?

> them.  I'm going to try and get this done in time for the upcoming IETF

Fair enough. So your plan is to say that the top nybble is reserved for
the four bits and the next three are the extension type field which is
orthogonal to the first four bits, and that autokey thus uses the
following extension types:

0x200 No-Operation
0x201 Association Message
0x202 Certificate Message
0x203 Cookie Message
0x204 Autokey Message
0x205 Leapseconds Message
0x206 Sign Message
0x207 IFF Identity Message
0x208 GQ Identity Message
0x209 MV Identity Message

It is unfortunate that autokey uses the bottom nybble for a code since
it is information private to autokey, but as long as we specify that
this was a mistake and should not be repeated I guess it isn't too bad,
although 0x200 alone would have been nicer.  Are we clear on this point,
that no other extension field going forward should put field private
information into the field type?

All of the above means of course that the IANA values for the other
extension fields need to change by eliminating the specification of the
first nybble:

0x005 Checksum Complement (RFC 7821, sec 5)
0x000 Crypto-NAK (draft-mayer-ntp-mac-extension-field-00, sec 5)
0x003 MAC extension (draft-mayer-ntp-mac-extension-field-00, sec 5)
0x008 Last extension (draft-stenn-ntp-last-extension-00, sec 4)
0x006 Suggest extension (draft-stenn-ntp-suggest-refid-00, sec 7)

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 20 Jun 2016 00:46:23 +0000

> specified but elicits no documented change in behavior. Did you intend

Yes, if I send you an I-DO you reply with an I-DO-RESPONSE.

Otherwise we don't know when to stop replying unless we save state.

I'll have to reply to the rest of your message later.

H

---

From: brian utterback <[email-masked]>
Date: Mon, 20 Jun 2016 10:29:05 -0400

That makes perfect sense and may even be implied by the I-DO draft, but
it isn't really very clear reading it. Again, I am not sure this
shouldn't be handled internally to the field but I don't see any reason
to not handle it with this bit. But the wording in all of the RFCs and
drafts need to be made consistent.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 24 Jun 2016 08:53:04 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 15.06.2016 um 04:14 in Nachricht
> I'm done repeating myself to you.

Hi guys!

Maybe work on a private shared document, where Harlan picks his arguments from the archives to present them to Danny, and Danny writes any objections in to that document. Then Harlan gan update the document. Once that document is stable, tell us about it. Would that be OK for you?

Ulrich

---

From: Daniel Franke <[email-masked]>
Date: Mon, 27 Jun 2016 11:02:41 -0400

Suggestions for a way forward on the field-type issue.

Somebody who cares about autokey (i.e., not me), should write a draft
updating RFC5906 with field types that match what's in use. Its IANA
Considerations section should request allocation of the correct field
types, and request that the existing allocations be changed to
"Reserved" to prevent future registration conflicts.

Some extensions need to contain information to distinguish between
request vs. response, error vs. normal. I have no problem with using
separate field types to communicate that information. However, that
doesn't necessitate stealing an entire bit out of the field-type
field. Every RFC which defines any new extension fields can have its
own way of doing things and this shouldn't ever result in any
conflict. Implementations which understand those fields can apply
whatever convention the defining RFC dictates. Implementations which
don't understand the those fields just ignore them. In that case
they'll have no means of extracting information about request vs.
response or error vs. normal, but that's okay because they would have
no use for it.

The MAC-required vs. MAC-optional bit mentioned in some of the current
I-Ds seems completely useless to me. In what possible situation would
the sender need to specify to the receiver whether or not to enforce
the presence of the MAC, wherein for the receiver to permit the sender
to specify non-enforcement would constitute anything other than a
vulnerability?

One possibly-defensible case for a global bit would be a "covered by
MAC" bit. My knee-jerk response as a crypto engineer is just to say
"if a MAC is present, it covers the entire packet", but the existence
of the checksum complement extension renders this unworkable, since
the checksum complement has to be the very last thing computed before
the packet is sent. So, we need some way of dealing with the case
where a receiver gets a packet that contains both an unrecognized
extension field, and a (recognized) MAC extension field. The receiver
needs some way of knowing whether to include the unrecognized
extension field in the MAC calculation. I see three ways of going
about this:

1. Steal a bit out of the field type which indicates whether the field
should be covered by any MACs.
2. Enforce the convention that MAC extensions always cover the 48-byte
header plus all the extensions that precede the MAC extension, but do
not cover any extensions which come after them.
3. Have any MAC extensions we define explicitly enumerate what parts
of the packet they cover.

I like option #2 the best but I could be talked into any of these.
However, if we are going with option #1 then it is ESSENTIAL that we
produce an RFC specifying this before we go any further with creating
new extension fields, and we need to have separate IANA registries for
covered-by-MAC and not-covered-by-MAC extension types. Otherwise,
we're risking a future disaster when someone at IANA, unaware of the
significance of this bit, allocates a field type with the bit
incorrectly set.

Choosing option #2 or #3 might merit an Informational RFC to record
this decision, but this is far less important.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 28 Jun 2016 08:59:24 +0200

On Mon, Jun 27, 2016 at 11:02:41AM -0400, Daniel Franke wrote:
> The receiver

I like the option #2 best too. That's how I thought it would work with
the new MAC extension field that Danny is working on. The question is
if we will need other MAC fields (e.g. the one that NTS is proposing)
and if they should be allowed to have different rules for what is
covered by the MAC.

-- 
Miroslav Lichvar