Subject: [TICTOC] [ntpwg] 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.

---

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?
>
>  
>
>  
>
>  
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>ntpwg mailing list
>[email-masked]
>http://lists.ntp.org/listinfo/ntpwg
>

---

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