Subject: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00

From: Tal Mizrahi <[email-masked]>
Date: Mon, 4 Jul 2011 15:00:56 +0300

Hi,

I have posted a new draft that discusses Checksum updates in time synchronization protocols.
http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00
Comments will be welcome.

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

---

From: Greg Dowd <[email-masked]>
Date: Mon, 11 Jul 2011 15:29:08 +0000

Is the use model you envision for NTP to support hardware timestamping at the edge?  In NTP, the addition of an extension field requires the presence of the MAC.  This requires the dissemination and maintenance of keys as well as the defined MAC checking.  How would this model work if the NTP packet did  have the MAC?  This extension field would be covered by the MAC and the authenticator would fail.  Or do you expect this block would have the key info and update the MAC as well?  And, how would it work if the MAC isn't there.  Would the update not be used?

In PTP, there is a TC protocol function which necessitates the modification of the packet.  In NTP, as it is defined as a UDP protocol, there is not as clear a path to how lower stack layers modify the PDUs.

If you define this simply at the edge, I'm not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: [email-masked]; [email-masked]
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Hi,

Thanks.
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 12 Jul 2011 17:44:02 +0300

Hi Greg,

Thanks for your feedback.

> In NTP, the addition of an extension field requires the presence of the MAC.
[TM] According to RFC5905 "The extension fields are used to add optional capabilities, for example, the Autokey security protocol". So indeed, the only extension field currently defined is for security purposes, but the current draft proposes to use a newly defined extension field, independent of the MAC usage.

> How would this model work if the NTP packet did  have the MAC?
[TM] The current draft is more useful for cases where the MAC is not used, since this draft is about simplifying the implementation of intermediate nodes. When the MAC is used, it would mean that the intermediate node would have to compute the MAC, and only then to perform the Checksum update.

> If you define this simply at the edge, I'm not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?
[TM] The idea is that the intermediate node (an ASIC/FPGA) assigns the packet's timestamp field, significantly improving the accuracy. The benefit of this improvement is negligible if the path between the NTP nodes consists of a large number of hops, BUT when there is a small number of hops this improvement is significant. An example use-case I have in mind is in the wireless backhaul, where the RBS and RNC synchronize over a CES, either using PTP or NTP. When NTP is used in this case, high precision is required, and can benefit from timestamping at the intermediate node.

Regards,
Tal.

From: Greg Dowd [mailto:[email-masked]]
Sent: Monday, July 11, 2011 6:29 PM
To: Tal Mizrahi; [email-masked]; [email-masked]
Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Hi,

Thanks.
Tal.

---

From: Greg Dowd <[email-masked]>
Date: Tue, 12 Jul 2011 16:51:19 +0000

Hi Tal,
                The MAC is a necessary component in the current protocol when extensions are present.  The parsing of incoming packets uses frame size as mechanism for determining the code path to take in addition to its obvious utility value in autokey.  The relevant section in 5905 is the first sentence in the NTP Extension Field Format section 7.5.
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.

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Tuesday, July 12, 2011 7:44 AM
To: Greg Dowd; [email-masked]; [email-masked]
Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Hi Greg,

Regards,
Tal.

Hi,

Thanks.
Tal.

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 13 Jul 2011 17:53:58 +0000

Greg,

The MAC is intended to protect against a message modification attack, 
which surely is not the object here. In principle, the MAC can be 
omitted and an extension field can be used in much the same way as a 
transparent bridge in PTP.

Dave

Greg Dowd wrote:

> Is the use model you envision for NTP to support hardware timestamping 
> at the edge?  In NTP, the addition of an extension field requires the 
> presence of the MAC.  This requires the dissemination and maintenance 
> of keys as well as the defined MAC checking.  How would this model 
> work if the NTP packet did  have the MAC?  This extension field would 
> be covered by the MAC and the authenticator would fail.  Or do you 
> expect this block would have the key info and update the MAC as well?  
> And, how would it work if the MAC isn't there.  Would the update not 
> be used?
>
>  
>
> In PTP, there is a TC protocol function which necessitates the 
> modification of the packet.  In NTP, as it is defined as a UDP 
> protocol, there is not as clear a path to how lower stack layers 
> modify the PDUs.
>
>  
>
> If you define this simply at the edge, I'm not sure how much value 
> this additional UDP checksum update adds?  Is there a model you have 
> in mind?
>
>  
>
>  
>
>  
>
>  
>
>------------------------------------------------------------------------
>

---

From: Greg Dowd <[email-masked]>
Date: Wed, 13 Jul 2011 18:22:23 +0000

The NTPv4 protocol, and the implementation, currently don't have the ability to distinguish an extension from a MAC uniquely.  I would rather see a "NOOP" MAC (with keyid 0 or -1) function defined which would let nodes process and drop the frame with auth failure and not a malformed packet.

Looking beyond the protocol state machine, how could we include some indicator in the frame that it had been modified?  Perhaps we could make some extension mandatory?  One issue with the way TCs work in PTP is that they are all doing a read-modify-write against the correction field.  It is not possible to distinguish either the number or the timing characteristics of the elements modifying the time.  In a closed point-to-point protocol like telecom style PTP this is not an issue as the links, and the capabilities of the TC elements, are well-defined and managed.  In NTP, it would be useful to develop a "profile" which would define this NTP application over a controlled or managed network.  It could specifically call out the usage of hardware timestamps where available, the format and/or requirement to generate an extension, the restrictions on use of authenticators or autokey, the impact on the utility value of the dispersion/root distance fields, etc.

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com<http://www.symmetricom.com>
"Everything should be made as simple as possible, but no simpler" Albert Einstein
From: David L. Mills [mailto:[email-masked]]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; [email-masked]; [email-masked]
Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Greg,

The MAC is intended to protect against a message modification attack, which surely is not the object here. In principle, the MAC can be omitted and an extension field can be used in much the same way as a transparent bridge in PTP.

Dave

Greg Dowd wrote:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Hi,

Thanks.
Tal.

________________________________

ntpwg mailing list

[email-masked]<mailto:[email-masked]>

---

From: todd glassey <[email-masked]>
Date: Wed, 13 Jul 2011 12:08:48 -0700

On 7/13/2011 11:22 AM, Greg Dowd wrote:
>
> The NTPv4 protocol, and the implementation, currently don't have the 
> ability to distinguish an extension from a MAC uniquely.  I would 
> rather see a "NOOP" MAC (with keyid 0 or -1) function defined which 
> would let nodes process and drop the frame with auth failure and not a 
> malformed packet.
>
> Looking beyond the protocol state machine, how could we include some 
> indicator in the frame that it had been modified?
>
You only need this if there is a new set of policies that are to be 
supported. If so what are the policies to be.

> Perhaps we could make some extension mandatory?  One issue with the 
> way TCs work in PTP is that they are all doing a read-modify-write 
> against the correction field.  It is not possible to distinguish 
> either the number or the timing characteristics of the elements 
> modifying the time.  In a closed point-to-point protocol like telecom 
> style PTP this is not an issue as the links, and the capabilities of 
> the TC elements, are well-defined and managed.  In NTP, it would be 
> useful to develop a "profile" which would define this NTP application 
> over a controlled or managed network.  It could specifically call out 
> the usage of hardware timestamps where available, the format and/or 
> requirement to generate an extension, the restrictions on use of 
> authenticators or autokey, the impact on the utility value of the 
> dispersion/root distance fields, etc.
>
> Greg Dowd
>
> www.symmetricom.com <http://www.symmetricom.com>
>
> *From:*David L. Mills [mailto:[email-masked]]
> *Sent:* Wednesday, July 13, 2011 10:54 AM
> *To:* Greg Dowd
> *Cc:* Tal Mizrahi; [email-masked]; [email-masked]
> *Subject:* Re: [ntpwg] [TICTOC] New draft: 
> draft-mizrahi-tictoc-checksum-trailer-00
>
> Greg,
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Tal Mizrahi
> *Sent:* Monday, July 04, 2011 5:01 AM
> *To:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* [TICTOC] [ntpwg] New draft: 
> draft-mizrahi-tictoc-checksum-trailer-00
>
> Hi,
>
> [email-masked]  <mailto:[email-masked]>

-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 14 Jul 2011 04:32:15 +0000

todd,

A careful read of the specification should give you comfort that the 
parsing rules do distinguish between an extension field and a MAC. In 
particular, the rules permit one or more extension fields without a MAC. 
The only requirement is that a MAC, if present, must be the last field.

Dave

todd glassey wrote:

>> would let nodes process and drop the frame with auth failure and not 
>> a malformed packet. 
>>
>>  
>>
>> Is the use model you envision for NTP to support hardware 
>> timestamping at the edge?  In NTP, the addition of an extension field 
>> requires the presence of the MAC.  This requires the dissemination 
>> and maintenance of keys as well as the defined MAC checking.  How 
>> would this model work if the NTP packet did  have the MAC?  This 
>> extension field would be covered by the MAC and the authenticator 
>> would fail.  Or do you expect this block would have the key info and 
>> update the MAC as well?  And, how would it work if the MAC isn't 
>> there.  Would the update not be used?
>>
>>  
>>
>> From: [email-masked] <mailto:[email-masked]> 
>> [mailto:[email-masked]] On Behalf Of Tal Mizrahi
>> To: [email-masked] <mailto:[email-masked]>; [email-masked]

---

From: todd glassey <[email-masked]>
Date: Thu, 14 Jul 2011 06:44:59 -0700

On 7/13/2011 9:32 PM, David L. Mills wrote:
> particular, the rules permit one or more extension fields without a 
> MAC. The only requirement is that a MAC, if present, must be the last 
> field.
Yes David - of course they do. I was talking about the idea of designing 
the protocol based on specific policies it delivered something totally 
to the group at this point but something that needs to happen.

Todd
>>> modifying the time.  In a closed point-to-point protocol like 
>>> telecom style PTP this is not an issue as the links, and the 
>>> capabilities of the TC elements, are well-defined and managed.  In 
>>> NTP, it would be useful to develop a "profile" which would define 
>>> this NTP application over a controlled or managed network.  It could 
>>> specifically call out the usage of hardware timestamps where 
>>> available, the format and/or requirement to generate an extension, 
>>> the restrictions on use of authenticators or autokey, the impact on 
>>> the utility value of the dispersion/root distance fields, etc.
>>>
>>> Greg Dowd
>>>
>>> The MAC is intended to protect against a message modification 
>>> attack, which surely is not the object here. In principle, the MAC 
>>> can be omitted and an extension field can be used in much the same 
>>> way as a transparent bridge in PTP.
>>>
>>> Dave
>>>
>>> Greg Dowd wrote:
>>>
>>> timestamping at the edge?  In NTP, the addition of an extension 
>>> field requires the presence of the MAC.  This requires the 
>>> dissemination and maintenance of keys as well as the defined MAC 
>>> checking.  How would this model work if the NTP packet did  have the 
>>> MAC?  This extension field would be covered by the MAC and the 
>>> authenticator would fail.  Or do you expect this block would have 
>>> the key info and update the MAC as well?  And, how would it work if 
>>> the MAC isn't there.  Would the update not be used?
>>>

---

From: Greg Dowd <[email-masked]>
Date: Thu, 14 Jul 2011 16:10:38 +0000

When you say specification, do you mean something other than the RFC5905 document?  Here is the RFC language.

The relevant section in 5905 is the first sentence in the NTP Extension Field Format section 7.5.
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.

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com<http://www.symmetricom.com>
"Everything should be made as simple as possible, but no simpler" Albert Einstein
From: ntpwg-bounces+gdowd=[email-masked] [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of David L. Mills
Sent: Wednesday, July 13, 2011 9:32 PM
To: todd glassey
Cc: [email-masked]
Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00

todd,

A careful read of the specification should give you comfort that the parsing rules do distinguish between an extension field and a MAC. In particular, the rules permit one or more extension fields without a MAC. The only requirement is that a MAC, if present, must be the last field.

Dave

todd glassey wrote:

Looking beyond the protocol state machine, how could we include some indicator in the frame that it had been modified?
You only need this if there is a new set of policies that are to be supported. If so what are the policies to be.

Perhaps we could make some extension mandatory?  One issue with the way TCs work in PTP is that they are all doing a read-modify-write against the correction field.  It is not possible to distinguish either the number or the timing characteristics of the elements modifying the time.  In a closed point-to-point protocol like telecom style PTP this is not an issue as the links, and the capabilities of the TC elements, are well-defined and managed.  In NTP, it would be useful to develop a "profile" which would define this NTP application over a controlled or managed network.  It could specifically call out the usage of hardware timestamps where available, the format and/or requirement to generate an extension, the restrictions on use of authenticators or autokey, the impact on the utility value of the dispersion/root distance fields, etc.

Greg Dowd
Cc: Tal Mizrahi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Greg,

Dave

Greg Dowd wrote:

Hi,

Thanks.
Tal.

ntpwg mailing list

ntpwg mailing list

--

Todd S. Glassey

ntpwg mailing list

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 15 Jul 2011 04:51:09 +0000

todd,

I have not the slightest clue what you are advocaiting, but it is 
probably not anNTP extension field.

Dave

todd glassey wrote:

> Yes David - of course they do. I was talking about the idea of 
> designing the protocol based on specific policies it delivered 
> something totally to the group at this point but something that needs 
> to happen.
>
> Todd
>
>>
>> Dave
>>
>> todd glassey wrote:
>>
>>>> The NTPv4 protocol, and the implementation, currently don't have 
>>>> the ability to distinguish an extension from a MAC uniquely.  I 
>>>> would rather see a "NOOP" MAC (with keyid 0 or -1) function defined 
>>>> which would let nodes process and drop the frame with auth failure 
>>>> and not a malformed packet. 
>>>>
>>>>  
>>>>
>>>> Looking beyond the protocol state machine, how could we include 
>>>> some indicator in the frame that it had been modified? 
>>>>
>>>> this NTP application over a controlled or managed network.  It 
>>>> could specifically call out the usage of hardware timestamps where 
>>>> checking.  How would this model work if the NTP packet did  have 
>>>> the MAC?  This extension field would be covered by the MAC and the 
>>>> this additional UDP checksum update adds?  Is there a model you 
>>>> have in mind?
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>>  
>>>>

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 15 Jul 2011 17:00:19 +0000

Greg,

The document from whch the spec was derifed is now six years old, but 
that is not the point. The parser can now deal with the absence of a 
MAC, as well as hash algorithms of both 16 and 20 octets.

Dave:

> When you say specification, do you mean something other than the 
> RFC5905 document?  Here is the RFC language.
>
>  
>
> From: ntpwg-bounces+gdowd=[email-masked] 
> [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf 
> Of David L. Mills
> Cc: Tal Mizrahi; [email-masked] <mailto:[email-masked]>;

---

From: todd glassey <[email-masked]>
Date: Fri, 15 Jul 2011 11:03:03 -0700

On 7/13/2011 9:32 PM, David L. Mills wrote:
> parsing rules do distinguish between an extension field and a MAC.
yes they do...
> In particular, the rules permit one or more extension fields without a 
yes, and that's fine but there are policy control models which may want 
more. The real issues is what specific functional policies NTP is setup 
to implement. This is something that you and I have argued about since 
we split on the first AutoKEY draft way back when.

I look at NTP as a source of evidence -that's what I am after - 
documenting the evidence models possible with NTP for compliance practices.

Todd

---

From: todd glassey <[email-masked]>
Date: Fri, 15 Jul 2011 11:06:52 -0700

> something totally to the group at this point but something that needs 
What I am suggesting Dave is that its time to do that formal review on 
what NTP is and what proof of operations it delivers formally, and in 
that process documenting that as a WG we understand what policies NTP 
can and cannot be use to deploy.

You of course know them all by heart as the father of the protocol but 
99.999% of the audit world doesn't. Worse 99.999% of the Admins also 
don't either but that is a different issue IMHO.

Todd

---

From: Danny Mayer <[email-masked]>
Date: Fri, 15 Jul 2011 15:27:37 -0400

> we split on the first AutoKEY draft way back when.

Protocol is not the place for policy. That's an admin/management role.
You cannot dictate policy anywhere and doesn't belong in the protocol.
You can design your own policy distribution protocol if you want that
that has nothing to do with NTP.

> documenting the evidence models possible with NTP for compliance practices.

NTP cannot be used as a source of evidence, there are just too many ways
of spoofing a timestamp without evidence of tampering.

Danny

---

From: todd glassey <[email-masked]>
Date: Sat, 16 Jul 2011 13:12:28 -0700

> Protocol is not the place for policy. That's an admin/management role.
No Danny - POLICY is what the PROTOCOL IMPLEMENTS. There is no way 
around this no matter how you try and cover it up. The policy is what 
the protocol is set up to implement. The structure of the controls that 
are in place are what provide the policy implementations.

> You cannot dictate policy anywhere and doesn't belong in the protocol.
Yes you can... the Protocol must implement USE MODELS which are defined 
by the policy.
> that has nothing to do with NTP.
Right...

---

From: Danny Mayer <[email-masked]>
Date: Sat, 16 Jul 2011 22:30:37 -0400

> are in place are what provide the policy implementations.

That means that you have no understanding of what the NTP protocol
implements.

> Yes you can... the Protocol must implement USE MODELS which are defined

No, the protocol only defines how data is transferred but there is no
requirement about how it gets used at the receiving end. You cannot
dictate that.

Danny