Subject: Re: [TICTOC] [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer

From: Danny Mayer <[email-masked]>
Date: Sun, 27 Oct 2013 15:18:50 -0400

On 10/27/2013 9:42 AM, Tal Mizrahi wrote:
> Hi Danny,
> 
>> That also means that the extension field MUST NOT be added by any intermediate nodes if it does not exist.
> 
> I am not sure we want to go there, for 2 reasons:
> 
> 1. Let's not forget that the source and the intermediate node are in
fact two modules in the same client/server (see Figure 1 in the draft).
>From an interoperability perspective it would be exactly the same if the
source created the extension field, or the intermediate node did. Why
would we mandate a specific implementation detail that would be
completely transparent to the network?

Maybe I missed that in the draft, but don't you want the sending server
to decide whether or not it expects the timestamp be updated? Having
intermediate systems update the timestamp and extension field without
the originating server sanctioning it seems even worse (to me).

> 
> 2. A clock that receives an NTP message has no way of knowing
> whether
an extension field was added by the source or by an intermediate node,
and thus there is no way to enforce (enforce from a security
perspective) the requirement you suggested.

True enough but don't you want the originator to have a say in this so
that this becomes a recommendation for developers?

I've added TICTOC to the discussion. It was not in the original mail.

Danny

> Tal.
> 
> 
> -----Original Message-----
> From: Danny Mayer [mailto:[email-masked]] 
> Sent: Sunday, October 27, 2013 3:34 PM
> To: Tal Mizrahi; [email-masked]
> Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer
> 
> On 10/27/2013 3:58 AM, Tal Mizrahi wrote:
>> Hi Danny,
>>
>>> The draft does not state whether or not the source of the packet creates the extension field before it is sent to the recipient.
>>> That needs to be clarified.
>>
>> The source should create the extension field in advance. I will clarify this in the draft.
>>
> 
> That also means that the extension field MUST NOT be added by any intermediate nodes if it does not exist.
> 
> Danny
> 
>>
>>> I am aware that it is easy enough to change the contents of a packet 
>>> AND the UDP checksum and noone would be the wiser
>>
>> Right, I completely agree.
>>
>>> but I don't think that it's good policy.
>>
>>
>> Thanks,
>> Tal.
>>
>>
>> -----Original Message-----
>> From: Danny Mayer [mailto:[email-masked]]
>> Sent: Sunday, October 27, 2013 12:16 AM
>> To: Tal Mizrahi; [email-masked]
>> Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer
>>
>> On 10/21/2013 5:59 AM, Tal Mizrahi wrote:
>>> Hi,
>>> A new version is available:
>>>
>>> http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-01
>>>
>>> The most significant change since the last draft is that this draft 
>>> is
>>> **not** intended for authenticated mode.
>>>
>>> This was in response to security related concerns from Danny and Harlan.
>>>
>>> I believe the current draft does not present a new security 
>>> vulnerability compared to the existing NTPv4.
>>>
>>> (I think) I managed to convince Harlan of this. I am not sure I 
>>> convinced Danny yetÃ,Â.
>>>
>>
>> Let me try and explain my worries about this extension field.
>> The draft is marked as experimental so it falls into the category of something someone want's to try but won't necessarily make it further than that.
>>
>> The proposal's intent is to allow the packet to be modified in-flight to change the previously provided timestamp with another one. When one does that the packet's existing UDP checksum becomes invalid. In order to deal with this, instead of updating the UDP checksum itself, the extension field is either added, or updated, I'm not clear which, so that the additional set of bits makes the original UDP checksum be correct. The draft does not state whether or not the source of the packet creates the extension field before it is sent to the recipient.
>> That needs to be clarified. Either way the intent of the extension field is just to provide a delta so that the originator's original UDP checksum works. It has no other function. Potentially the timestamp could be updated multiple times by intermediaries and the extension field updated each time. This also means that a MAC cannot be present unless the MAC is updated each time and security like autokey cannot be used.
>>
>> My worry here is that this just provides another way of changing the contents of the NTP packet without disturbing the original UDP checksum.
>> It's not something I would want to encourage. I am aware that it is easy enough to change the contents of a packet AND the UDP checksum and noone would be the wiser but I don't think that it's good policy.
>>
>>
>> Danny
>>
> 
> 
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 28 Oct 2013 08:34:11 +0200

Hi Danny,

>> 2. A clock that receives an NTP message has no way of knowing whether
>>an extension field was added by the source or by an intermediate node, and thus there is no way to enforce (enforce from a security

>True enough but don't you want the originator to have a say in this so that this becomes a recommendation for developers?

As a recommendation it makes sense, and indeed I will add it as a SHOULD. 

Thanks,
Tal.

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: Sunday, October 27, 2013 9:19 PM
To: Tal Mizrahi; [email-masked]; [email-masked]
Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer

>From an interoperability perspective it would be exactly the same if the source created the extension field, or the intermediate node did. Why would we mandate a specific implementation detail that would be completely transparent to the network?

Maybe I missed that in the draft, but don't you want the sending server to decide whether or not it expects the timestamp be updated? Having intermediate systems update the timestamp and extension field without the originating server sanctioning it seems even worse (to me).

> 
> 2. A clock that receives an NTP message has no way of knowing whether
an extension field was added by the source or by an intermediate node, and thus there is no way to enforce (enforce from a security
perspective) the requirement you suggested.

True enough but don't you want the originator to have a say in this so that this becomes a recommendation for developers?

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 28 Oct 2013 08:09:09 +0000

Just some thoughts, and I hope I'm awake enough to type this...

There seem to be several issues here.

In the "Figure 1" case "core" packet timestamps come from the kernel
and the new packet timestamp will be added by the hardware engine.  I
understand the following question is outside the scope of this document,
but how can one determine how well sync'd the internal clock is with the
clock in the accurate timestamp engine?

If we have TX and RX hardware timestamping capabilities, we can use
NTP's interleave mode to communicate these timestamps as well.  Having
said that, I'm sure there is something to be learned from implementing
Tal's proposal.

H

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 28 Oct 2013 10:38:55 +0200

Hi Harlan,

>In the "Figure 1" case "core" packet timestamps come from the kernel and the new packet timestamp will be added by the hardware engine.  
>I understand the following question is outside the scope of this document, but how can one determine how well sync'd the internal clock is with the clock in the accurate timestamp engine?

Well, indeed it is strictly an implementation question. For example, in typical PTP implementations (that I am familiar with) the accurate clock is only maintained in one place, i.e., in the HW engine. The SW stack includes the servo algorithm; the SW stack regularly computes the necessary offset or frequency adjustments, and whenever necessary sends update commands to the HW engine about these adjustments. Thus, the SW stack does not need to maintain an additional clock, since all its computations are performed WRT the HW clock.

Thanks,
Tal.

-----Original Message-----
From: Harlan Stenn [mailto:[email-masked]] 
Sent: Monday, October 28, 2013 10:09 AM
To: Tal Mizrahi
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer

In the "Figure 1" case "core" packet timestamps come from the kernel and the new packet timestamp will be added by the hardware engine.  I understand the following question is outside the scope of this document, but how can one determine how well sync'd the internal clock is with the clock in the accurate timestamp engine?

If we have TX and RX hardware timestamping capabilities, we can use NTP's interleave mode to communicate these timestamps as well.  Having said that, I'm sure there is something to be learned from implementing Tal's proposal.

H

---

From: Kevin Stanton <[email-masked]>
Date: Mon, 28 Oct 2013 10:52:03 -0700

This is a somewhat unrelated question, but why not eliminate the servo?

If a software entity is the consumer of PTP time, I wonder if the benefit
of avoiding the y=mx+b computation (to compute PTP time from the time of
the free-running LAN hardware counter) is worth the trouble of disciplining
the hardware clock.

In other words, the hardware engine maintains a time reference and software
maintains the parameters for translating that time reference to PTP time
(also for hardware-captured Rx and Tx timestamps).  Of course, this doesn't
apply to one-step master ports.

Thoughts?

Kevin Stanton.

On Mon, Oct 28, 2013 at 1:38 AM, Tal Mizrahi <[email-masked]> wrote:

> Hi Harlan,
>
> >In the "Figure 1" case "core" packet timestamps come from the kernel and
> the new packet timestamp will be added by the hardware engine.
> >I understand the following question is outside the scope of this
> document, but how can one determine how well sync'd the internal clock is
> with the clock in the accurate timestamp engine?
>
> Well, indeed it is strictly an implementation question. For example, in
> typical PTP implementations (that I am familiar with) the accurate clock is
> only maintained in one place, i.e., in the HW engine. The SW stack includes
> the servo algorithm; the SW stack regularly computes the necessary offset
> or frequency adjustments, and whenever necessary sends update commands to
> the HW engine about these adjustments. Thus, the SW stack does not need to
> maintain an additional clock, since all its computations are performed WRT
> the HW clock.
>
> Thanks,
> Tal.
>
>
> In the "Figure 1" case "core" packet timestamps come from the kernel and
> the new packet timestamp will be added by the hardware engine.  I
> If we have TX and RX hardware timestamping capabilities, we can use NTP's
> interleave mode to communicate these timestamps as well.  Having said that,
> I'm sure there is something to be learned from implementing Tal's proposal.
>
> H
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>

---

From: Greg Dowd <[email-masked]>
Date: Mon, 28 Oct 2013 18:16:13 +0000

There are a variety of different implementation techniques, some of which do use free-running counters on the hw side, mapped to a software function up higher.  Some NIC vendors are already doing that.  One of the challenges for that type of operation is that the entire system must be aware and designed for that purpose until kernels/drivers/applications catch up.  The beauty of the "inline" function is that it can be inserted into the process, correcting errors on the input and/or output without changing the system at other layers.

The tight coupling of the servo to the timing hardware also tends to allow better precision in many cases, running in real-time or at high(er) data rates.  For some of our designs, we are synchronizing slave clocks in the sub 100ns (or better) in the presence of very high traffic loads.  Obviously, the application for this class of synchronization service is much more targeted than Internet (capital I) but the market does exist so why not use the technology.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin Stanton
Sent: Monday, October 28, 2013 10:52 AM
To: Tal Mizrahi
Cc: [email-masked]; Harlan Stenn; [email-masked]
Subject: Re: [TICTOC] [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer

If a software entity is the consumer of PTP time, I wonder if the benefit of avoiding the y=mx+b computation (to compute PTP time from the time of the free-running LAN hardware counter) is worth the trouble of disciplining the hardware clock.

In other words, the hardware engine maintains a time reference and software maintains the parameters for translating that time reference to PTP time (also for hardware-captured Rx and Tx timestamps).  Of course, this doesn't apply to one-step master ports.

Thoughts?

Kevin Stanton.

On Mon, Oct 28, 2013 at 1:38 AM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Harlan,

Thanks,
Tal.

-----Original Message-----
From: Harlan Stenn [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, October 28, 2013 10:09 AM
To: Tal Mizrahi
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer

H
_______________________________________________
TICTOC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 28 Oct 2013 20:57:20 +0200

Hi Kevin,

Just to make sure we are on the same page: this thread started out as a thread about NTP, and specifically about the following draft:
http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-01

I think the point you suggested is basically a religious discussion of one-step vs. two-step clocks in PTP.
The example I referred to in the thread below is a PTP slave as an analogous example to an NTP client. Since NTP is always one-step (no two-step mode in NTP), in our context the actual time-of-day has to be maintained in HW.

Please let me know if this makes sense.

Thanks,
Tal.

From: Kevin Stanton [mailto:[email-masked]]
Sent: Monday, October 28, 2013 7:52 PM
To: Tal Mizrahi
Cc: Harlan Stenn; [email-masked]; [email-masked]
Subject: Re: [TICTOC] [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer

Thoughts?

Kevin Stanton.

Thanks,
Tal.

-----Original Message-----
From: Harlan Stenn [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, October 28, 2013 10:09 AM
To: Tal Mizrahi
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer

H

---

From: Danny Mayer <[email-masked]>
Date: Mon, 28 Oct 2013 15:13:21 -0400

On 10/27/2013 10:10 AM, Magnus Danielson wrote:
> On 10/27/2013 02:42 PM, Tal Mizrahi wrote:
>> Hi Danny,
>>
>> 1. Let's not forget that the source and the intermediate node are in fact two modules in the same client/server (see Figure 1 in the draft). From an interoperability perspective it would be exactly the same if the source created the extension field, or the intermediate node did. Why would we mandate a specific implementation detail that would be completely transparent to the network?
>>
>> 2. A clock that receives an NTP message has no way of knowing whether an extension field was added by the source or by an intermediate node, and thus there is no way to enforce (enforce from a security perspective) the requirement you suggested.
> I think this discussion would benefit from separating "interface node"
> from "intermediate node" as these have different roles. The interface
> node would add the output time-stamp of the sending node. If
> intermediate nodes where allowed to add fields, we could have buffer
> compensation in NTP just as in PTP's transparent clock.

I'm not sure that there's a real difference here. From a topological
point of view the interface node and an intermediate node are just a
node in the network. You are just calling it a different name.

> At the same time, as long as there is no authentication on this, any
> intermediate node can create any form of modification that the receiver
> node will accept, malicious or unintentional. Hence, there is only so
> much protection you can create in the semantics.
> 

There's no protection whatsoever here.

Danny

---

From: Greg Dowd <[email-masked]>
Date: Mon, 28 Oct 2013 20:25:32 +0000

Actually, that's not completely correct.  While the NTP standard doesn't have any definition of two-step, the reference implementation ntpd includes support for two-step operation in some modes.  It is called interleaved mode.  It still doesn't change any of your points but it is there.

From: ntpwg-bounces+gdowd=[email-masked] [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Tal Mizrahi
Sent: Monday, October 28, 2013 11:57 AM
To: Kevin Stanton
Cc: [email-masked]; [email-masked]
Subject: Re: [ntpwg] [TICTOC] New version of draft-mizrahi-ntp-checksum-trailer

Hi Kevin,

Thanks,
Tal.

Thoughts?

Kevin Stanton.

Thanks,
Tal.

-----Original Message-----
From: Harlan Stenn [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, October 28, 2013 10:09 AM
To: Tal Mizrahi
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer

H

---

From: Danny Mayer <[email-masked]>
Date: Mon, 28 Oct 2013 15:12:47 -0400

Danny