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 >>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? As a recommendation it makes sense, and indeed I will add it as a SHOULD. Thanks, Tal. -----Original Message----- From: Danny Mayer [mailto:[email protected]] Sent: Sunday, October 27, 2013 9:19 PM To: Tal Mizrahi; [email protected]; [email protected] Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer 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 protected]] > Sent: Sunday, October 27, 2013 3:34 PM > To: Tal Mizrahi; [email protected] > 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 protected]] >> Sent: Sunday, October 27, 2013 12:16 AM >> To: Tal Mizrahi; [email protected] >> 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 >> > > > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
