IETF Logo Mail Archive

Re: [TICTOC] [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00

Danny Mayer <mayer@ntp.org> Mon, 29 July 2013 21:15 UTC

Return-Path: <mayer@ntp.org>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C2011E8146 for <tictoc@ietfa.amsl.com>; Mon, 29 Jul 2013 14:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO5WP2q51mI5 for <tictoc@ietfa.amsl.com>; Mon, 29 Jul 2013 14:15:26 -0700 (PDT)
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7609E11E813A for <tictoc@ietf.org>; Mon, 29 Jul 2013 14:15:25 -0700 (PDT)
Received: from [198.22.153.36] (helo=[10.2.64.39]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <mayer@ntp.org>) id 1V3ump-000FTs-0Z; Mon, 29 Jul 2013 21:15:24 +0000
Message-ID: <51F6DB63.9090208@ntp.org>
Date: Mon, 29 Jul 2013 17:15:15 -0400
From: Danny Mayer <mayer@ntp.org>
Organization: NTP
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Tal Mizrahi <talmi@marvell.com>
References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380F@IL-MB01.marvell.com> <51F69E59.9010403@ntp.org> <74470498B659FA4687F0B0018C19A89C01A0FA109DCC@IL-MB01.marvell.com>
In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0FA109DCC@IL-MB01.marvell.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 198.22.153.36
X-SA-Exim-Rcpt-To: talmi@marvell.com, ntpwg@lists.ntp.org, tictoc@ietf.org, mills@udel.edu
X-SA-Exim-Mail-From: mayer@ntp.org
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Cc: "ntpwg@lists.ntp.org" <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>, "David L. Mills" <mills@udel.edu>
Subject: Re: [TICTOC] [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mayer@ntp.org
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 21:15:27 -0000

On 7/29/2013 4:46 PM, Tal Mizrahi wrote:
> Hi Danny,
> 
> I understand your concern, and I would like to clarify an important point: I believe the functionality described in this draft is useful in unauthenticated mode, and not useful in authenticated mode. In authenticated mode, an intermediate entity that changes the packet would have to re-compute the MAC, so re-computing the UDP checksum as well does not significantly complicate the intermediate entity.
> 
> I tried to explain this point in the draft (the text is quoted below), but if the working group feels strongly about it I am willing to make it a stronger statement - that the checksum trailer is only  relevant to unauthenticated mode, and is not to be used in authenticated mode.
> 
> Danny, does this make sense?
> 

Not to me. If you are already changing the packet directly why not
change the packet UDP checksum as well while you're at it?

I'd rather see the corrected time in an extension field rather than
changing the packet itself.

Danny
> Quoting from section 3.4 of the draft:
>    While a Checksum Trailer MAY be used when authentication is enabled,
>    in practice the Checksum Trailer is more useful in unauthenticated
>    mode, allowing the intermediate entity to perform serial processing
>    of the packet without storing-and-forwarding it.
> 
> 
> Tal.
> 
> 
> -----Original Message-----
> From: Danny Mayer [mailto:mayer@ntp.org] 
> Sent: Monday, July 29, 2013 6:55 PM
> To: Tal Mizrahi
> Cc: ntpwg@lists.ntp.org; tictoc@ietf.org; David L. Mills
> Subject: Re: [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00
> 
> I have serious concerns about this draft. I effect it seems to say that any intermediate mode can alter the contents of the packet in flight and thus encourage a MIM attack. Furthermore it recommends recomputing the MAC. Why bother to do it this way if you can just recompute the MAC (if
> any) and then UDP checksum and place it in the UDP checksum field. I'd rather have the new timestamp placed in the extension field so that the receiving server can use it or not.
> 
> The security considerations makes no mention of these issues.
> 
> Danny
> 
>

v2.23.0 | Report a Bug | By Email