Subject: [ntpwg] MAC Extension Field

From: Danny Mayer <[email-masked]>
Date: Tue, 02 Jun 2015 14:05:32 -0400

I'd like to discuss the possibility of creating a MAC extension field
with a view to getting rid of the existing MAC in the future.

The rationale for doing so is that the existing MAC is inflexible, is
not of one specific length and there is no length field and the hash
algorithm is not definable.

An extension field MAC could cover all data up to the MAC extension
field, be able to specify (to be documented in an RFC) the algorithm to
be used, would have a specific length and could be flexible enough that
there could be multiple MAC extension fields in a single packet, each
with their own potential algorithms.

Since an extension field contains a length field we don't need to play
games to guess how long a MAC is and which algorithm to use. Currently
you are limited to MD5 and SHA1 and makes the processing of extension
fields difficult.

Danny

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 02 Jun 2015 19:35:37 +0000

+1

---

From: Anil Kumar <[email-masked]>
Date: Tue, 02 Jun 2015 18:33:37 +0000

I do support the thought , we should keep all the NTP extensions in
strictly TLV format. I would like to collaborate and contribute in any
possible way for this.

---

From: Greg Dowd <[email-masked]>
Date: Tue, 2 Jun 2015 18:47:01 +0000

I'm all for it.  There's a little chicken and egg problem since 5905 currently says a MAC is always present when an extension is present.  However, it is still a much better evolutionary path.  As long as the new one is big enough to pass the current extension check but be failed in the mac verify routine, I think it is even interoperable with existing implementations.

I think the contents are debatable, extensible, etc as long as it is clearly identifiable as a mac extension, but hopefully without using so much of the id space in extensions the way autokey was doing.

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Danny Mayer
Sent: Tuesday, June 02, 2015 11:06 AM
To: [email-masked]
Subject: [ntpwg] MAC Extension Field

EXTERNAL EMAIL

I'd like to discuss the possibility of creating a MAC extension field with a view to getting rid of the existing MAC in the future.

The rationale for doing so is that the existing MAC is inflexible, is not of one specific length and there is no length field and the hash algorithm is not definable.

An extension field MAC could cover all data up to the MAC extension field, be able to specify (to be documented in an RFC) the algorithm to be used, would have a specific length and could be flexible enough that there could be multiple MAC extension fields in a single packet, each with their own potential algorithms.

Since an extension field contains a length field we don't need to play games to guess how long a MAC is and which algorithm to use. Currently you are limited to MD5 and SHA1 and makes the processing of extension fields difficult.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 03 Jun 2015 03:22:02 +0000

Greg Dowd writes:
> I'm all for it.  There's a little chicken and egg problem since 5905
> currently says a MAC is always present when an extension is present.
> However, it is still a much better evolutionary path.  As long as the
> new one is big enough to pass the current extension check but be
> failed in the mac verify routine, I think it is even interoperable
> with existing implementations.

I wonder if we can change the language in 5905 so it optionally allows
the trailing (old-style) MAC, and we specify that if we use "MAC in an
extension field" we know that the only thing we're signing there is
"stuff up to this field".

H

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 03 Jun 2015 08:04:28 +0200

>>> Greg Dowd <[email-masked]> schrieb am 02.06.2015 um 20:47 in Nachricht
> currently says a MAC is always present when an extension is present.  

I'm afraid NTPv5 must provide both MACs, old and new, and NTPv6 could then set the obsolete MAC to some flags value like all-ones or all-zeroes.

> However, it is still a much better evolutionary path.  As long as the new one 
> is big enough to pass the current extension check but be failed in the mac 
> verify routine, I think it is even interoperable with existing 
> implementations.
> 
> I think the contents are debatable, extensible, etc as long as it is clearly 
> identifiable as a mac extension, but hopefully without using so much of the 
> id space in extensions the way autokey was doing.
> 
> 
> I'd like to discuss the possibility of creating a MAC extension field with a 
> view to getting rid of the existing MAC in the future.
> 
> The rationale for doing so is that the existing MAC is inflexible, is not of 
> one specific length and there is no length field and the hash algorithm is 
> not definable.
> 
> An extension field MAC could cover all data up to the MAC extension field, 
> be able to specify (to be documented in an RFC) the algorithm to be used, 
> would have a specific length and could be flexible enough that there could be 
> multiple MAC extension fields in a single packet, each with their own 
> potential algorithms.
> 
> Since an extension field contains a length field we don't need to play games 
> to guess how long a MAC is and which algorithm to use. Currently you are 
> limited to MD5 and SHA1 and makes the processing of extension fields 
> difficult.
> 
> Danny
>

---

From: Hal Murray <[email-masked]>
Date: Tue, 02 Jun 2015 23:39:03 -0700

> one specific length and there is no length field and the hash algorithm is

Would we be better off starting over with a new version of the basic packet 
format?

What else would you change if you had the chance?

-- 
These are my opinions.  I hate spam.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 03 Jun 2015 06:29:59 -0400

On 6/3/2015 3:56 AM, [email-masked] wrote:

> I also support the idea of having an MAC extension field. But I question
> if it has to be defined in the document draft-ietf-ntp-extension-field.
>  This draft intends to clarify some points regarding the usage of
> extension fields and the MAC field. I strongly support that this draft
> clearly states that the MAC field is not necessary in the presence of
> extension fields. A MAC extension field can be defined in a security
> draft as we intend to do in the NTS draft.
> 
> Dieter
> 

If you look at that code you will see that it's already there!

Danny

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Wed, 3 Jun 2015 11:27:38 +0000

Hi All,

NTPv4 known issues like IPv6 REF-ID, Fixed MAC and etc.. can be addressed in a way by introducing NTP extensions.

Legacy NTP implementation impose unnecessary size restriction upon extensions to be introduced in future.
Such restrictions are unfriendly and must be addressed before new extension starts evolving.

IMHO, we need to address size restrictions introduced by legacy MAC for new extensions.
In this regard I have a proposal which tries to address this issue. 

Request everyone in the community to provide your view on the attached proposal.

Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+anil.sn=[email-masked]] On Behalf Of Danny Mayer
Sent: 03 June 2015 16:00
To: [email-masked]; [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

On 6/3/2015 3:56 AM, [email-masked] wrote:

> I also support the idea of having an MAC extension field. But I 
> question if it has to be defined in the document draft-ietf-ntp-extension-field.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 03 Jun 2015 09:12:40 -0400

> Would we be better off starting over with a new version of the basic packet 

Probably not but I'm open to suggestions. The biggest problem would be
interoperability with previous versions of NTP.

> What else would you change if you had the chance?
I believe that Harlan has a laundry list if we decide to bump up the NTP
version.

Danny

---

From: Brian Haberman <[email-masked]>
Date: Wed, 03 Jun 2015 09:38:48 -0400

Hi Ulrich,

On 6/3/15 2:04 AM, Ulrich Windl wrote:
> 
> I'm afraid NTPv5 must provide both MACs, old and new, and NTPv6 could
> then set the obsolete MAC to some flags value like all-ones or
> all-zeroes.

I am not sure why the above would be the case.  If we bumped the version
to 5, we can specify what we want the behavior to be.  We are not
beholden to the NTPv4-style of MAC in that situation.

We may need to assess client/server interoperability issues, but that
doesn't mean we have to support the old MAC in a new version.

Regards,
Brian

---

From: Danny Mayer <[email-masked]>
Date: Wed, 03 Jun 2015 10:25:54 -0400

> "stuff up to this field".

That language is already in the extension field draft which makes it
clear that the existing MAC field is optional unless you have an
extension field (like autokey) that requires it.

There is no need to go to NTPv5 for a MAC extension field. You just have
to continue to support the old and optional MAC field as well.

Danny

---

From: Greg Dowd <[email-masked]>
Date: Wed, 3 Jun 2015 15:55:54 +0000

I think your added modifier "that requires it" isn't present in 5905.  Section 7.5 NTP Extension Field Format, sentence 1 reads. " In NTPv4, one or more extension fields can be inserted after the  header and before the MAC, which is always present when an extension field is present. "

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2015 7:26 AM
To: Harlan Stenn; Greg Dowd
Cc: [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

EXTERNAL EMAIL

> "stuff up to this field".

That language is already in the extension field draft which makes it clear that the existing MAC field is optional unless you have an extension field (like autokey) that requires it.

There is no need to go to NTPv5 for a MAC extension field. You just have to continue to support the old and optional MAC field as well.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 03 Jun 2015 12:00:34 -0400

On 6/3/2015 7:27 AM, Anil Kumar S N (VRP Network BL) wrote:
> Hi All,
> 
> NTPv4 known issues like IPv6 REF-ID, Fixed MAC and etc.. can be
addressed in a way by introducing NTP extensions.
> Such restrictions are unfriendly and must be addressed before new
extension starts evolving.

There are no size restrictions on extension fields except that imposed
up the limits to the size of a single UDP packet. The extension fields
have a length field which specify the length of the extension field.

> IMHO, we need to address size restrictions introduced by legacy MAC for new extensions.

No, we don't have size restrictions on the extension fields we just have
a guessing game on whether or not there is a MAC field and how long
there is.

> Request everyone in the community to provide your view on the attached proposal.

I am against this proposal as it does not address backward compatibility
and prevents interoperability with existing implementations.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 03 Jun 2015 12:07:20 -0400

On 6/3/2015 11:55 AM, Greg Dowd wrote:
> I think your added modifier "that requires it" isn't present in
> 5905.
Section 7.5 NTP Extension Field Format, sentence 1 reads. " In NTPv4,
one or more extension fields can be inserted after the header and before
the MAC, which is always present when an extension field is present. "

Right. The updated language is in the extension field draft now under
review and is contained in Section 7.5.1 in that draft and specifically
7.5.1.1. That draft updates the language of RFC5905.

Danny

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 4 Jun 2015 05:00:31 +0000

Hi Danny,

	DANNY >> 	There are no size restrictions on extension fields except that imposed up the limits to the size of a single UDP packet. The extension fields have a length field which 
			specify the	length of the extension field.
	ANIL >> 	I agrees Extension has length field but apart for actual data there is need for extra padding due to legacy MAC. Our proposal is to address this extra padding issue.

	DANNY >>	No, we don't have size restrictions on the extension fields we just have a guessing game on whether or not there is a MAC field and how long there is.
	ANIL >> 	This is the issue we wanted to address.

	DANNY >> 	I am against this proposal as it does not address backward compatibility and prevents interoperability with existing implementations.
	ANIL >> 	We have taken care of backward compatibility and interoperability.

			Please refer to section in the draft which talks in detail : 
			3.3. Cases ensuring backward compatibility. 

			Please let us know how backward compatibility and interoperability are not addressed by this draft, that would be helpful.
			https://tools.ietf.org/html/draft-choudharykumar-ntp-ntpv4-extended-extensions-00

Thanks & Regards
Anil S N

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: 04 June 2015 00:01
To: Anil Kumar S N (VRP Network BL); [email-masked]; [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

> Such restrictions are unfriendly and must be addressed before new
extension starts evolving.

There are no size restrictions on extension fields except that imposed up the limits to the size of a single UDP packet. The extension fields have a length field which specify the length of the extension field.

> IMHO, we need to address size restrictions introduced by legacy MAC for new extensions.

No, we don't have size restrictions on the extension fields we just have a guessing game on whether or not there is a MAC field and how long there is.

> Request everyone in the community to provide your view on the attached proposal.

I am against this proposal as it does not address backward compatibility and prevents interoperability with existing implementations.

Danny

---

From: Florian Weimer <[email-masked]>
Date: Thu, 04 Jun 2015 15:04:59 +0200

> with a view to getting rid of the existing MAC in the future.

MAC field in extensions are problematic because in order to locate the
MAC, you need to parse the packet.  This means the MAC does not protect
the packet parser, and there could be confusion about what is actually
covered by the MAC.  A packet filtering device would have to know more
about the protocol than absolutely necessary to weed out bad packets
before they hit the NTP server.

-- 
Florian Weimer / Red Hat Product Security
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Thu, 04 Jun 2015 13:54:37 -0400

You are stealing a bit from the extension field identifier field. As a
result the extension field identifier will be interpreted by
non-upgraded NTP server as a new extension field and will regard it as
unknown and thereby breaking interoperability.

I cannot support breaking interoperability.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 05 Jun 2015 07:20:19 -0400

First of all, Autokey may not be the only extension field. As I recall
Autokey DOES require a MAC but how big is the MAC? If you have
additional Extension Fields then they will not know that you have stolen
a bit and you will have a situation where a previously recognized
extension field is now unrecognized by the unchanged server because you
changed the ID of the extension field.

You also need to be able to deal with Extension Fields without a MAC, a
MAC without Extension Fields and multiple extension fields in addition
to the autokey field.

It took me months of work with Dave Mills trying to figure out how to
get the extension field formulated in RFC5905 (and 5906) so that
extension fields could be added cleanly.

The only way to do this properly is to bump NTP to v5 but then I want to
have the MAC in an extension field itself so that there is not separate
MAC field in which case your proposal is not needed (except for relaxing
the restriction on the size of the extension field to not require a 4
byte rounding.

Danny
On 6/4/2015 10:45 PM, Vikram Choudhary wrote:
> Hi Danny,
> 
> We are not proposing any changes to the existing extensions. Please
> check section 2.2. which is clearly documented for the newer extension
> and will not be considered for the existing one. We have a have special
> constraint for maintaining interoperability with the existing Â Autokey
> extension.
> 
> o. Autokey extension/s MUST be continuous and SHOULD start after NTP
>     header.
> 
>     Proposed M-BIT solution cannot be used for Autokey extension as the
>     MSB (most significant bit) of Autokey Field type is already used for
>     indicating response messages. If the Autokey extensions are used in
>     the middle then it won't be possible to indicate whether more/none
>     extensions are following the current extension or not. Thus Autokey
>     extensions MUST be the first extension after NTP header and SHOULD
>     be processed as per the guideline defined by RFC 5906 <https://tools.ietf.org/html/rfc5906> [RFC5906 <https://tools.ietf.org/html/rfc5906>].
> 
> 
> So IMHO, there won't be anyÂ interoperabilityÂ issue. Please correct me
> if I am missing your point.
> 
> Thanks
> Vikram
> 
> On Thu, Jun 4, 2015 at 11:24 PM, Danny Mayer <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Vikram Choudhary <[email-masked]>
Date: Fri, 5 Jun 2015 08:15:07 +0530

Hi Danny,

We are not proposing any changes to the existing extensions. Please check
section 2.2. which is clearly documented for the newer extension and will
not be considered for the existing one. We have a have special constraint
for maintaining interoperability with the existing  Autokey extension.

    Proposed M-BIT solution cannot be used for Autokey extension as the
    MSB (most significant bit) of Autokey Field type is already used for
    indicating response messages. If the Autokey extensions are used in
    the middle then it won't be possible to indicate whether more/none
    extensions are following the current extension or not. Thus Autokey
    extensions MUST be the first extension after NTP header and SHOULD
    be processed as per the guideline defined by RFC 5906
<https://tools.ietf.org/html/rfc5906> [RFC5906
<https://tools.ietf.org/html/rfc5906>].

So IMHO, there won't be any interoperability issue. Please correct me if I
am missing your point.

Thanks
Vikram

On Thu, Jun 4, 2015 at 11:24 PM, Danny Mayer <[email-masked]> wrote:

> >       DANNY >>        There are no size restrictions on extension fields
> except that imposed up the limits to the size of a single UDP packet. The
> extension fields have a length field which
> >       ANIL >>         I agrees Extension has length field but apart for
> actual data there is need for extra padding due to legacy MAC. Our proposal
> is to address this extra padding issue.
> >
> >       DANNY >>        No, we don't have size restrictions on the
> extension fields we just have a guessing game on whether or not there is a
> MAC field and how long there is.
> >       DANNY >>        I am against this proposal as it does not address
> backward compatibility and prevents interoperability with existing
> implementations.
> >                       Please let us know how backward compatibility and
> interoperability are not addressed by this draft, that would be helpful.
> >
> up the limits to the size of a single UDP packet. The extension fields have
> a length field which specify the length of the extension field.
> >
> >>
> a guessing game on whether or not there is a MAC field and how long there
> is.
> >

---

From: Danny Mayer <[email-masked]>
Date: Sat, 06 Jun 2015 21:16:26 -0400

On 6/5/2015 10:50 PM, Vikram Choudhary wrote:
> Hi Danny,
> 
> Thanks for your thoughts. Please find my reply inline.
> 
> Thanks
> Vikram
> 
> On Fri, Jun 5, 2015 at 4:50 PM, Danny Mayer <[email-masked]
>     First of all, Autokey may not be the only extension field.As I
>     recallÂ Autokey DOES require a MAC but how big is the MAC?
> 
> Â 
> 
>     Vikram >>> AFAIK, only one well defined NTP extension is available
>     till date, cited by RFC 5906. If you know any other reference please
>     share. Yes, you are correct Autokey requires MAC. BTW, section 7.5
>     of RFC 5905 clearly mandates MAC should always be present when an
>     extension field is available.

Yes and the draft RFC for the extension field clarifies this to make it
clear that it's really optional. Did you read the draft? It's in last
call. Autokey requires it but it's the only one we are aware of to
actually require it. We don't know what other extension fields there
are. Tal has a draft out for one and it does not use a MAC.

Danny

---

From: Vikram Choudhary <[email-masked]>
Date: Sat, 6 Jun 2015 08:20:32 +0530

Hi Danny,

Thanks
Vikram

On Fri, Jun 5, 2015 at 4:50 PM, Danny Mayer <[email-masked]> wrote:

> recall Autokey DOES require a MAC but how big is the MAC?

> Vikram >>> AFAIK, only one well defined NTP extension is available till
> date, cited by RFC 5906. If you know any other reference please share. Yes,
> you are correct Autokey requires MAC. BTW, section 7.5 of RFC 5905 clearly
> mandates MAC should always be present when an extension field is available.

If you have additional Extension Fields then they will not know that you
> have stolen a bit You also need to be able to deal with Extension Fields
> without a MAC, a MAC without Extension Fields and multiple extension fields
> in addition

to the autokey field.

> Vikram >>> M-bit will only be added for the newer extension not for the
> existing one. Moreover, all the newer extension to come MUST take care of
> the M-bit while getting the IANA values assigned. It's mentioned as the
> part of the draft.

It took me months of work with Dave Mills trying to figure out how to get
> the extension field formulated in RFC5905 (and 5906) so that extension
> fields could be added cleanly.

> Vikram >>> I really appreciate your time in taking up this discussion. My
> intention is not to derail anyone. Since, we have an alternate solution
> towards this proposal so just wanted to share our idea with the community.
> At the end of the day only the best should be delivered to the community.

The only way to do this properly is to bump NTP to v5 but then I want
> to have the MAC in an extension field itself so that there is not
> separate MAC field in which case your proposal is not needed (except for
> relaxing the restriction on the size of the extension field to not require
> a 4 byte rounding.

> Vikram: I do agree that NTPv5 will be a better place for cleaning up all
> this mesh. IMHO, we also got to address the issues with the existing
> version which is heavily deployed in the market. Coming to our proposal, we
> are trying to save the extra padding as much as possible and provide more
> relaxation to the application while packaging NTP packet.

> >     be processed as per the guideline defined by RFC 5906 <
> https://tools.ietf.org/html/rfc5906> [RFC5906 <
> https://tools.ietf.org/html/rfc5906>].
> >
> >

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Tue, 9 Jun 2015 04:01:49 +0000

Dear Danny,

	Yes and the draft RFC for the extension field clarifies this to make it clear that it's really optional. Did you read the draft? It's in last call. Autokey requires it but it's the only one we are aware of to actually require it. We don't know what other extension fields there are. Tal has a draft out for one and it does not use a MAC.

ANIL >> We read the your draft and this change should not impact your draft. As your draft clarifies NTPv3 and NTPv4 extension.
	  We can request Tal to use more bit. Please share Tal's Mail-ID I will discuss.

Thanks & Regards
Anil S N

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: 07 June 2015 06:46
To: Vikram Choudhary
Cc: Anil Kumar S N (VRP Network BL); [email-masked]; [email-masked]; Vikram Choudhary; [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

>     extension field is available.

Yes and the draft RFC for the extension field clarifies this to make it clear that it's really optional. Did you read the draft? It's in last call. Autokey requires it but it's the only one we are aware of to actually require it. We don't know what other extension fields there are. Tal has a draft out for one and it does not use a MAC.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 09 Jun 2015 23:15:15 -0400

On 6/9/2015 12:01 AM, Anil Kumar S N (VRP Network BL) wrote:
> Dear Danny,
> 
> Yes and the draft RFC for the extension field clarifies this to make
it clear that it's really optional. Did you read the draft? It's in last
call. Autokey requires it but it's the only one we are aware of to
actually require it. We don't know what other extension fields there
are. Tal has a draft out for one and it does not use a MAC.
> 
> ANIL >> We read the your draft and this change should not impact
> your
draft. As your draft clarifies NTPv3 and NTPv4 extension.
> We can request Tal to use more bit. Please share Tal's Mail-ID I
> will
discuss.
> Anil S N

Anil,

I would really appreciate it if you could fix your email client. It[s
very hard to distinguish between my message and your responses. It's the
opposite of the way one expects to read it.

Tal is on the ntp wg distribution list so he will be receiving these
emais. If you read the draft RFC's you will even see his contact
information.

What disturbs me greatly is that you are proposing to work around a
problem by introducing additional incompatibilities instead of solving
the underlying issue directly. I know of at least 3 possible solutions,
but one requires us to increment the NTP packet version to 5, the second
would be a better way of addressing the problem without completely
making it disappear and the third is the one I am proposing which is to
turn the MAC into a full extension field so that we can drop the
existing MAC in the future.

I'm not sure why you think your idea won't cause problems and why you
don't want to solve the real problem.

I'd appreciate it if others on the list can join in an give their
opinion of this.

Danny

Danny

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Wed, 10 Jun 2015 04:00:36 +0000

Dear Danny,

	Please find my comments in line. 

Thanks & Regards
Anil S N

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: 10 June 2015 08:45
To: Anil Kumar S N (VRP Network BL); Vikram Choudhary
Cc: [email-masked]; [email-masked]; Vikram Choudhary; [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

> Yes and the draft RFC for the extension field clarifies this to make
it clear that it's really optional. Did you read the draft? It's in last call. Autokey requires it but it's the only one we are aware of to actually require it. We don't know what other extension fields there are. Tal has a draft out for one and it does not use a MAC.
> 
> ANIL >> We read the your draft and this change should not impact your

Anil,

I would really appreciate it if you could fix your email client. It[s very hard to distinguish between my message and your responses. It's the opposite of the way one expects to read it.
Anil >> Hope this time its correct.

Tal is on the ntp wg distribution list so he will be receiving these emais. If you read the draft RFC's you will even see his contact information.
Anil >> I got it : [email-masked] thanks

What disturbs me greatly is that you are proposing to work around a problem by introducing additional incompatibilities instead of solving the underlying issue directly. I know of at least 3 possible solutions, but one requires us to increment the NTP packet version to 5, the second would be a better way of addressing the problem without completely making it disappear and the third is the one I am proposing which is to turn the MAC into a full extension field so that we can drop the existing MAC in the future.

Anil >> Danny if at we want to introduce any new extensions we would like it to be in this format, which helps new extensions. I am worried the cases were 0 length TLV ex: Capabilities TLV we need to have minimum of 7 Octets as per current scenario. I would prefer NTPv5. There is no way we can completely eliminate the issue due to fixed MAC in NTPv4, We would like to give a workaround for NTPv4. Danny I support your thought of making MAC as an extension, if you remember I am first person to support your idea, But even if you make MAC as an extension we need this due to backward compatibility. Please don't treat this draft as opposed to your draft, Please treat it as an add-on to your draft. I have no issues if you want to merge our draft since both talk about same NTPv4 extensions. 

I'm not sure why you think your idea won't cause problems and why you don't want to solve the real problem.
Anil >> I strongly feel my solution will solve the problem without side any effects. I am there for real problems too, I support MAC as an extension and I support MTPv5. In the hope of NTPv5 we can't ignore NTP v4. Since many customers are using NTPv4 and its serving their purpose as of now, they might not readily move into NTPv5. I request you to accept this solution if its technically not a issue, I believe this give more flexibility for new extensions. I am thank full that you're the one person who is responding to our draft. 

I'd appreciate it if others on the list can join in an give their opinion of this.
Anil >> Yes we need second opinion, Me and Danny disagree on some points. As a community member your opinion matters a lot. Please give your opinion. I feel NTP working group can be more active so that we can come up with better solutions. Me and Danny both might be wrong... Humble request Please come forward and give your opinion.

Thanks & Regards
Anil S N

Danny

Danny

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 10 Jun 2015 09:13:02 +0000

Hi Anil,

Taking a look at draft-choudharykumar-ntp-ntpv4-extended-extensions-01,
I am a bit confused about how the draft achieves its purpose.

The abstract says: "This document redefines NTP extension header proposed in RFC 5905 for addressing unnecessary padding issue which is required for differentiating between NTP extension and MAC data."
But then, in section 2.2: "First extension following NTP header MUST be at least 28 octets.", and also "First extension following utokey extension MUST be at least 28 octets.".
How does your proposal reduce the "unnecessary padding"? It seems that if we want to be backward compatible with the legacy MAC, we can't avoid the 28 octet restriction.

I agree with Danny that going forward it would be a good idea to define the MAC as an extension field.

Regards,
Tal.

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Anil Kumar S N (VRP Network BL)
Sent: Wednesday, June 10, 2015 7:01 AM
To: [email-masked]; Vikram Choudhary
Cc: [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

Dear Danny,

Thanks & Regards
Anil S N

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: 10 June 2015 08:45
To: Anil Kumar S N (VRP Network BL); Vikram Choudhary
Cc: [email-masked]; [email-masked]; Vikram Choudhary; [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

Anil,

Thanks & Regards
Anil S N

Danny

Danny

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Wed, 10 Jun 2015 09:29:42 +0000

Hi Tal,

	You are correct , this restriction is applicable only to these two cases which is same as [draft-ietf-ntp-extension-field-02], Using our draft the restriction is imposed only on the first extension following current NTP Header or Autokey, This is needed to differentiate b/w MAC or extension. 

	"First extension following NTP header MUST be at least 28 octets.", 
	"First extension following Auto key extension MUST be at least 28 octets.".

Let's say we have MAC is part of Extension [draft-ietf-ntp-extension-field-02],  The last point says " the length of the last extension field MUST be at least 28 octets. The length of the other extension fields in this case MUST be at least 16 octets each ". Were all the extensions including last extension has length restriction. We could remove impose length restrictions on all the extension between NTP header and last extension.

For your reference :
7.5.1 Extension Fields and MACs
   7.5.1.4 Extension Fields in the Absence of a MAC

   If a MAC is not present, one or more extension fields can be inserted
   after the header, according to the following rules:

   o If the packet includes a single extension field, the length of the
      extension field MUST be at least 7 words, i.e., at least 28
      octets.

   o If the packet includes more than one extension field, the length
      of the last extension field MUST be at least 28 octets. The length
      of the other extension fields in this case MUST be at least 16
      octets each.

Thanks & Regards
Anil S N

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: 10 June 2015 14:43
To: Anil Kumar S N (VRP Network BL); [email-masked]; Vikram Choudhary
Cc: [email-masked]
Subject: RE: [ntpwg] MAC Extension Field

Hi Anil,

Regards,
Tal.

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Anil Kumar S N (VRP Network BL)
Sent: Wednesday, June 10, 2015 7:01 AM
To: [email-masked]; Vikram Choudhary
Cc: [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

Dear Danny,

Thanks & Regards
Anil S N

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: 10 June 2015 08:45
To: Anil Kumar S N (VRP Network BL); Vikram Choudhary
Cc: [email-masked]; [email-masked]; Vikram Choudhary; [email-masked]
Subject: Re: [ntpwg] MAC Extension Field

Anil,

Thanks & Regards
Anil S N

Danny

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 10 Jun 2015 17:32:06 -0400

On 6/10/2015 12:00 AM, Anil Kumar S N (VRP Network BL) wrote:
> Thanks & Regards Anil S N
> 
> -----Original Message----- From: Danny Mayer [mailto:[email-masked]] 
> Sent: 10 June 2015 08:45 To: Anil Kumar S N (VRP Network BL); Vikram
> Choudhary Cc: [email-masked]; [email-masked]; Vikram
> Choudhary; [email-masked] Subject: Re: [ntpwg] MAC Extension
> Field
> 
> it clear that it's really optional. Did you read the draft? It's in
> last call. Autokey requires it but it's the only one we are aware of
> to actually require it. We don't know what other extension fields
> there are. Tal has a draft out for one and it does not use a MAC.
>> 
>> Thanks & Regards Anil S N
> 
> Anil,
> 
> very hard to distinguish between my message and your responses. It's
> the opposite of the way one expects to read it. Anil >> Hope this
> time its correct.
> 
> information. Anil >> I got it : [email-masked] thanks
> 
> problem by introducing additional incompatibilities instead of
> solving the underlying issue directly. I know of at least 3 possible
> solutions, but one requires us to increment the NTP packet version to
> 5, the second would be a better way of addressing the problem without
> completely making it disappear and the third is the one I am
> proposing which is to turn the MAC into a full extension field so
> that we can drop the existing MAC in the future.
> 
> Anil >> Danny if at we want to introduce any new extensions we would
> like it to be in this format, which helps new extensions. I am
> worried the cases were 0 length TLV ex: Capabilities TLV we need to
> have minimum of 7 Octets as per current scenario.

I don't know what TLV means. I'm not sure how you can have a 0 length of
anything valid. However we cannot change the Extension Field length
without bumping the packet rev to 5.

 I would prefer
> NTPv5. There is no way we can completely eliminate the issue due to
> fixed MAC in NTPv4, We would like to give a workaround for NTPv4.
> Danny I support your thought of making MAC as an extension, if you
> remember I am first person to support your idea, But even if you make
> MAC as an extension we need this due to backward compatibility.

This requires changing the requirements for an Extension Field and for
that you MUST bump the packet version, it just cannot be done for NTPv4.

> Please don't treat this draft as opposed to your draft, Please treat
> it as an add-on to your draft. I have no issues if you want to merge
> our draft since both talk about same NTPv4 extensions.

This is NOT an addon to the draft. This is an incompatibility.

> don't want to solve the real problem. 

Anil >> I strongly feel my
> solution will solve the problem without side any effects. I am there
> for real problems too, I support MAC as an extension and I support
> MTPv5. In the hope of NTPv5 we can't ignore NTP v4. Since many
> customers are using NTPv4 and its serving their purpose as of now,
> they might not readily move into NTPv5. I request you to accept this
> solution if its technically not a issue, I believe this give more
> flexibility for new extensions. I am thank full that you're the one
> person who is responding to our draft.
> 

No this is NOT technically feasible because it ignores backward
compatibility issues which you keep glossing over. The MAC extension
field would allow us to not include a MAC in the packet but requires
that the extension field size obey the current restrictions for NTPv4.
They can be changed for a V5. I believe that the size of the extension
field was originally set to make things easier to implement in hardware
but I cannot be certain. Tal, Greg or Martin might know better.

Danny

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 11 Jun 2015 02:31:30 +0000

Danny,

Please find my comments inline "[Anil >>] ".
I don't think this draft is incompatible with old version. Please don't mention it again unless you prove it.

Thanks & Regards
Anil S N

> Sent: 11 June 2015 03:02
> time
> > its correct.
> solving
> > the underlying issue directly. I know of at least 3 possible
> proposing
> > which is to turn the MAC into a full extension field so that we can
> > drop the existing MAC in the future.
> >
> worried
> > the cases were 0 length TLV ex: Capabilities TLV we need to have
> > minimum of 7 Octets as per current scenario.
> 
> I don't know what TLV means. I'm not sure how you can have a 0 length
> of anything valid. However we cannot change the Extension Field length
[Anil >>] https://tools.ietf.org/html/rfc5561 Please refer LDP capabilities TLV(Type Length Value) rfc 
where "9.  Dynamic Capability Announcement TLV" Dynamic capabilities are announced using 0 or 1 length TLV.

> that you MUST bump the packet version, it just cannot be done for NTPv4.
[Anil >>] Since we cannot change NTPv4 version, That's is the reason for introducing new draft 
and this draft is applicable only for the new extensions.
> This is NOT an addon to the draft. This is an incompatibility.
[Anil >>] This is not incompatibility, since this is applicable only for new extensions, 
old extensions for which field types are approved by IANA are processed and handled as normal.
> but I cannot be certain. Tal, Greg or Martin might know better.
[Anil >>] Common Danny , We have taken care of backward compatibility, Your are not willing to understand it.
Either its software or hardware, there are restrictions imposed on all the extensions which are not needed.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 11 Jun 2015 12:22:26 +0200

> old extensions for which field types are approved by IANA are processed and handled as normal.

I read your proposal on the extension format, but I'm not sure I
understand it correctly. It seems to remove restrictions on length of
new extensions (to save bandwidth) by allocating one bit from the
field type to signal if it's the last extension field in the packet.

But how will an old implementation know how to parse a packet
including a new extension field which is shorter than what was
required before?

-- 
Miroslav Lichvar

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 11 Jun 2015 10:50:21 +0000

Hi Lichvar,

	Thanks for spending time on our proposal.
	
	By referring to current IANA assigned values for NTP extension field type, I can say there is only one extension type which is autokey.
	Our proposal handles autokey by specifying all new extensions must be placed after autokey extension in NTP packet. So current implementation has no issues.
	Current implementation which don't understand new extensions need not to change any code and processing of unknown extension must be as per NTPv4 RFC.

	If current implementation decides to support new extension then M-Bit has to be processed then there will be need for code change.

	IANA reference link :
	https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml

Field Type	Meaning
0x0002	No-Operation Request
0x8002	No-Operation Response
0xC002	No-Operation Error Response
0x0102	Association Message Request
0x8102	Association Message Response
0xC102	Association Message Error Response
0x0202	Certificate Message Request
0x8202	Certificate Message Response
0xC202	Certificate Message Error Response
0x0302	Cookie Message Request
0x8302	Cookie Message Response
0xC302	Cookie Message Error Response
0x0402	Autokey Message Request
0x8402	Autokey Message Response
0xC402	Autokey Message Error Response
0x0502	Leapseconds Message Request
0x8502	Leapseconds Message Response
0xC502	Leapseconds Message Error Response
0x0602	Sign Message Request
0x8602	Sign Message Response
0xC602	Sign Message Error Response
0x0702	IFF Identity Message Request
0x8702	IFF Identity Message Response
0xC702	IFF Identity Message Error Response
0x0802	GQ Identity Message Request
0x8802	GQ Identity Message Response
0xC802	GQ Identity Message Error Response
0x0902	MV Identity Message Request
0x8902	MV Identity Message Response
0xC902	MV Identity Message Error Response

Thanks & Regards
Anil S N

> From: Miroslav Lichvar [mailto:[email-masked]]
> Sent: 11 June 2015 15:52
> To: Anil Kumar S N (VRP Network BL)
> Cc: [email-masked]; Vikram Choudhary; [email-masked]
> > > > Please don't treat this draft as opposed to your draft, Please
> > > > treat it as an add-on to your draft. I have no issues if you want
> > > > to merge our draft since both talk about same NTPv4 extensions.
> > >
> > [Anil >>] This is not incompatibility, since this is applicable only
> > for new extensions, old extensions for which field types are approved
> by IANA are processed and handled as normal.
> 
> new extensions (to save bandwidth) by allocating one bit from the field
> type to signal if it's the last extension field in the packet.
> 
> But how will an old implementation know how to parse a packet including
> a new extension field which is shorter than what was required before?
> 
> --
> Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 11 Jun 2015 13:48:53 +0200

> 	If current implementation decides to support new extension then M-Bit has to be processed then there will be need for code change.

I think there is a difference between understanding the content of a
new extension and being able to skip it in the packet in order to
find the MAC and verify the format of the packet.

An old NTP server should be able to reply to clients using a new
extension that it doesn't understand. If the packet is dropped as
having invalid format (the new extension is shorter that it should
be), there will be no reply. Is that correct?

> 	https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml

BTW, the values in this list (and apparently also the format specified
in RFC 5906) don't seem to correspond to what ntpd is actually using.
The version and code are swapped, e.g. sign message response is
actually 0x8206, not 0x8602.

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 11 Jun 2015 12:10:41 +0000

Hi Lichvar,

	Please find my reply in line [Anil >>]

Thanks & Regards
Anil S N

> Sent: 11 June 2015 17:19
> > 	By referring to current IANA assigned values for NTP extension
> field type, I can say there is only one extension type which is autokey.
> > 	Our proposal handles autokey by specifying all new extensions
> must be placed after autokey extension in NTP packet. So current
> implementation has no issues.
> > 	Current implementation which don't understand new extensions need
> not to change any code and processing of unknown extension must be as
> per NTPv4 RFC.
> >
> > 	If current implementation decides to support new extension then
> M-Bit has to be processed then there will be need for code change.
> 
> new extension and being able to skip it in the packet in order to find
> the MAC and verify the format of the packet.
> 
[Anil >>] 
RFC 5905 says extension field is verified as format checks and if in case of unknown type then the whole packet will be dropped.
Processing of unknown extension filed type is not discussed much in RFC 5905, as below text says its treated as format checks.

9.2.  Peer Process Operations

   The receive routine defines the process flow upon the arrival of a
   packet.  An example is described by the receive() routine in
   Appendix A.5.1.  There is no specific method required for access
   control, although it is recommended that implementations include such
   a scheme, which is similar to many others now in widespread use.  The
   access() routine in Appendix A.5.4 describes a method of implementing
   access restrictions using an access control list (ACL).  Format
   checks require correct field length and alignment, acceptable version
   number (1-4), and correct extension field syntax, if present.

> having invalid format (the new extension is shorter that it should be),
> there will be no reply. Is that correct?
[Anil >>] 
	I don't think client will get response as per RFC 5905. There is been discussion on proposing NTPv5 where we can have 
sort of Capability exchange extension but it's in the future. 
> actually 0x8206, not 0x8602.
[Anil >>] This is as per IANA website, RFC and IANA website says 0x8602. I got to check my code too :)

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 11 Jun 2015 14:33:45 +0200

> RFC 5905 says extension field is verified as format checks and if in case of unknown type then the whole packet will be dropped.

Where it does say that?

>    number (1-4), and correct extension field syntax, if present.

By correct extension field syntax I'd understand a check of the field
length not requiring the type to be known, but I'd be interested to
know what others think of that.

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 11 Jun 2015 13:48:52 +0000

> > RFC 5905 says extension field is verified as format checks and if in
> case of unknown type then the whole packet will be dropped.
> 
> Where it does say that?
[Anil >>] I don't find any reference which talks precisely about processing of unknown filed type. 

LDP protocol TLV's filed type has U-Bit which indicates how to process unknown TLV.
--------
U, Unknown TLV. 1 bit.

U	Description
0	A notification must be returned to the message originator and the entire message must be ignored.
1	The unknown TLV is silently ignored and the rest of the message is processed as if the unknown TLV did not exist
--------

> 
> > Processing of unknown extension filed type is not discussed much in
> RFC 5905, as below text says its treated as format checks.
> 
> >
[Anil >>] Interesting case is when a server supports only symmetric key basic NTPv4 RFC (Autokey macro is disabled while compiling) 
and  NTPv4 client is configured a server with autokey, if server is dropping this packet.
we can derive a conclusion a packet with unknown extension will be dropped. Let's hear it from the community about their views.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 11 Jun 2015 16:20:39 -0400

On 6/10/2015 10:31 PM, Anil Kumar S N (VRP Network BL) wrote:
> I don't think this draft is incompatible with old version. Please
don't mention it again unless you prove it.

Your esteem in my eyes has dropped precipitously. You don't tell me what
to do or try and keep me quiet. This is the IETF and we deal with
architectural issues and they need to be thoroughly discussed.

Have you reviewed the effects of your proposal with all of the different
NTP servers that are deployed? This include, to name just a few, ntpd,
ntpdate, sntp (from the NTP Reference implementation), Chrony, NTimed,
Windows Time Service (sntp), etc. Unless you have done so you cannot
make claims that you can interoperate with existing implementations
which is a requirement of any change.

> where "9. Dynamic Capability Announcement TLV" Dynamic capabilities
are announced using 0 or 1 length TLV.

I have no idea where LDP falls into this. NTP doesn't have anything to
do with LDP.

> old extensions for which field types are approved by IANA are processed and handled as normal.

You haven't addressed backward compatibility. If an existing
implementation receives one of these packets with new extension fields,
it will drop the packet because the extension field length will very
likely to be invalid (there's a 75% chance of that).

> [Anil >>] Common Danny , We have taken care of backward
> compatibility,
Your are not willing to understand it.

I understand it all right which is why I'm telling you it's not going to
be backward compatible.

> Either its software or hardware, there are restrictions imposed on
> all
the extensions which are not needed.

Without going to NTPv5 you can't lift the restrictions. With NTPv5 the
length restrictions can be lifted but then I'd want the MAC as an
extension field so that the MAC won't be in the packet anyway so there
would be no need to steal extension field ID bits.

What's missing from all of this is what you are intending to do with
extension fields. I presume you have a plan for them but haven't told us
what it is and why the length field restriction is so onerous.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 11 Jun 2015 16:30:48 -0400

> Where it does say that?

The processing of unknown extension fields is discussed in the extension
field draft which is currently in last call.

> know what others think of that.

The length of the extension field IS part of the syntax check. If
necessary, we can add clarifying language for this. This is irrespective
of whether or not the extension field is known to the receiving server.

Danny

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Fri, 12 Jun 2015 04:22:07 +0000

> Your esteem in my eyes has dropped precipitously. You don't tell me
> what to do or try and keep me quiet. This is the IETF and we deal with
[Anil >>] Sorry Danny, it was a request. I never meant to silence you. I am no one to silence you or anyone.
I requested you not to mention until it was proved, I am sorry again for my words.
Your reply was ending with a conclusion so I wanted to you to prove me I am wrong, 
I am all ok to accept if my proposal is wrong. Please don't take me other way. 
I know your knowledge and your contribution to ntp is high, I might not match it.
I have lot of respect to you.

> 
> Have you reviewed the effects of your proposal with all of the
> different NTP servers that are deployed? This include, to name just a
> few, ntpd, ntpdate, sntp (from the NTP Reference implementation),
> Chrony, NTimed, Windows Time Service (sntp), etc. Unless you have done
> so you cannot make claims that you can interoperate with existing
> implementations which is a requirement of any change.
> 
[Anil >>] I don't have so much resource to test so much, but with logical reasoning is what driving me to 
Propose this draft.

> >> of anything valid. However we cannot change the Extension Field
> >> length without bumping the packet rev to 5.
[Anil >>] I never said LDP has something to do with NTP, it was an example 
For 0 length TLV Usage. 
> >>> remember I am first person to support your idea, But even if you
> >>> make MAC as an extension we need this due to backward compatibility.
> >>
> >> This requires changing the requirements for an Extension Field and
> >> for that you MUST bump the packet version, it just cannot be done
> for NTPv4.
> > [Anil >>] Since we cannot change NTPv4 version, That's is the reason
> > for introducing new draft and this draft is applicable only for the
> new extensions.
> >>
> treat
[Anil >>] As I understand server will not initiate first packet in NTP, NTP client supports new extension and 
Server don't support new extension then obviously packet will be dropped. This is same as autokey. 
If server doesn't support autokey and client is configured with autokey then server will drop whole packet. 
How different is this with our proposal ?

> 
> >>
> >>>
> >>> I'm not sure why you think your idea won't cause problems and why
> >>> you don't want to solve the real problem.
> >>
> >> They can be changed for a V5. I believe that the size of the
> >> extension field was originally set to make things easier to
> implement
> >> in hardware but I cannot be certain. Tal, Greg or Martin might know
> better.
> >>
> I understand it all right which is why I'm telling you it's not going
> to be backward compatible.
[Anil >>] In any case if server don't support new extension then none of the 
New extensions are backward compatible when client sends it to server,
this is what your words meant :)

> extension fields. I presume you have a plan for them but haven't told
> us what it is and why the length field restriction is so onerous.
[Anil >>] This is the design issue, More bit and unknown extension process bit should 
Have introduced from the beginning. This is the first step to correct it. 

Thanks & Regards
Anil S N

---

From: Richard Welty <[email-masked]>
Date: Thu, 11 Jun 2015 10:31:51 -0400

> we can derive a conclusion a packet with unknown extension will be dropped. Let's hear it from the community about their views.
if i were coding, and the behavior in response to an unknown
extension type was unspecified, my first inclination would be
to log it as an error and discard the packet in its entirety.

my second step would be to go to the working group and point
out that the specification was incomplete.

richard

-- 
[email-masked]
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 12 Jun 2015 08:01:46 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 11.06.2015 um 13:48 in
Nachricht <20150611114853.GF6202@localhost>:
[...]
> actually 0x8206, not 0x8602.
[...]

I also noted that some values from RFC 1305 also seem to use unusual counting of bits (as compared to the actual implementation). E.g.  RFC 1305, page 55, figure 6...

Regards,
Ulrich

---

From: Danny Mayer <[email-masked]>
Date: Fri, 12 Jun 2015 16:23:34 -0400

> [Anil >>] I don't have so much resource to test so much, but with
logical reasoning is what driving me to

I don't have the resources either but unless we can be assured that you
won't break backward compatibility with these servers (and those are
just a small subset of the list) we cannot assume anything as long as
they conform to the current RFC.

> [Anil >>] I never said LDP has something to do with NTP, it was an example 

Since you cannot have a zero length extension field I have no idea what
you are suggesting or why you mentioned it.

> [Anil >>] As I understand server will not initiate first packet in
NTP, NTP client supports new extension and
> If server doesn't support autokey and client is configured with
autokey then server will drop whole packet.
> How different is this with our proposal ?>

It is more likely that the server will support the extension and the
client (also a server) will not.

> this is what your words meant :)

Yes and there are repercussions for that.

> Have introduced from the beginning. This is the first step to correct it. 

The real solution is to get rid of the MAC field and move it into an
extension field. The M bit just makes things worse and not better
because servers that understood an extension field and don't know about
this bit suddenly find an unknown extension field where the understood
extension field used to be.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 12 Jun 2015 16:35:57 -0400

> out that the specification was incomplete.

That's one of the issues addressed in the current draft extension field
RFC. See https://tools.ietf.org/html/draft-ietf-ntp-extension-field-02
Section 7.5 which states the following:

"If a host receives an extension field with an unknown Field Type value,
the host SHOULD ignore the extension field and MAY drop the packet
altogether if policy requires it."

If you want to be secure you need to drop the packet. However I know
that many servers will just ignore any extensions and process it anyway.
Witness how much KISS codes are ignored, to the recipient's detriment.

Danny

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Mon, 15 Jun 2015 05:02:12 +0000

Danny in summary, we will add an appendix which would explain in details with all possible extensions 
To prove how backward compatibility is addressed and not breaking inter-operability.

With that we will present it to community for their view point, comments and feedbacks.

Finally I have to thank community as whole for spending time on our proposal and 
few sent us unicast feedbacks and comments will definitely address your concerns.

> >> Chrony, NTimed, Windows Time Service (sntp), etc. Unless you have
> >> done so you cannot make claims that you can interoperate with
> >> existing implementations which is a requirement of any change.
> >>
> >> I have no idea where LDP falls into this. NTP doesn't have anything
> >> to do with LDP.
> > [Anil >>] I never said LDP has something to do with NTP, it was an
> > example For 0 length TLV Usage.
> 
> >> implementation receives one of these packets with new extension
> >> fields, it will drop the packet because the extension field length
> >> will very likely to be invalid (there's a 75% chance of that).
> > [Anil >>] In any case if server don't support new extension then none
> > of the New extensions are backward compatible when client sends it to
> > server, this is what your words meant :)
> 
> > [Anil >>] This is the design issue, More bit and unknown extension
> > process bit should Have introduced from the beginning. This is the
> first step to correct it.
> 

Thanks & Regards
Anil S N

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 15 Jun 2015 12:02:58 +0200

On Fri, Jun 12, 2015 at 04:35:57PM -0400, Danny Mayer wrote:
> If you want to be secure you need to drop the packet.

How would accepting a packet with an unknown extension worsen security?

> However I know

If all servers replied to packets with unknown extensions, wouldn't it
simplify and speed up the client's detection of server's extension
support? If a server is dropping packets with unknown extensions, the
client won't know if the reply was dropped or if it was simply lost in
the network. It will need to try it again without that extension and
see if there is a reply. If it supports multiple extensions, it may
need to repeat this process for each extension separately.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 18 Jun 2015 18:33:14 -0400

> need to repeat this process for each extension separately.

I don't disagree with anything you say. However it is much more likely a
server will understand an extension field than an end-client since the
receiving server is more likely to get updated while clients are just
"forgotten" for the most part. As you probably are aware KISS codes are
almost always ignored by clients which probably don't even know they
exist or why they are used. KISS codes can actually push your local
clock further away from the reference time yet some end-clients tend to
accept the contents as valid. The client usually initiates the request
and probably won't have an extension field in it so it is less likely
that the server will respond with an extension field unless someone
knows of a reason to do so.

Each server needs to make a conscious decision on an unknown extension
field. If you are interested in making sure your time is accurate and
want to use secure methods you really should be dropping the packets
with unknown extensions. I would recommend logging unknown extensions at
the very least.

Does any of this help?

Danny