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

[Danny Mayer <[e-mail]>]

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:[e-mail]] 
> Sent: Sunday, October 27, 2013 3:34 PM
> To: Tal Mizrahi; [e-mail]
> 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:[e-mail]]
>> Sent: Sunday, October 27, 2013 12:16 AM
>> To: Tal Mizrahi; [e-mail]
>> 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
>>
> 
> 
>