From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 4 09:15:18 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522A121F8737 for ; Mon, 4 Jul 2011 09:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.226 X-Spam-Level: X-Spam-Status: No, score=-5.226 tagged_above=-999 required=5 tests=[AWL=1.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAeUgQWkDTFD for ; Mon, 4 Jul 2011 09:15:17 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 0759A21F8736 for ; Mon, 4 Jul 2011 09:15:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C572E86D766 for ; Mon, 4 Jul 2011 16:15:15 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 6BDA786D41E for ; Mon, 4 Jul 2011 12:01:18 +0000 (UTC) Received: from galiil.marvell.com ([199.203.130.254]) by mail1.ntp.org with esmtps (TLSv1:RC4-MD5:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qdhpr-000GMC-M9 for ntpwg@lists.ntp.org; Mon, 04 Jul 2011 12:01:18 +0000 From: Tal Mizrahi To: "tictoc@ietf.org" , "ntpwg@lists.ntp.org" Date: Mon, 4 Jul 2011 15:00:56 +0300 Thread-Topic: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00 Thread-Index: Acw6QVZgcbH3mJzTRZOF+kYbuNTxSA== Message-ID: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-SA-Exim-Connect-IP: 199.203.130.254 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: talmi@marvell.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Mon, 04 Jul 2011 16:13:53 +0000 Subject: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3758786936821864637==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org --===============3758786936821864637== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01223E573C5AILMB01marve_" --_000_74470498B659FA4687F0B0018C19A89C01223E573C5AILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have posted a new draft that discusses Checksum updates in time synchroni= zation protocols. http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00 Comments will be welcome. Thanks. Tal. --_000_74470498B659FA4687F0B0018C19A89C01223E573C5AILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have pos= ted a new draft that discusses Checksum updates in time synchronization pro= tocols.

http://tools.ietf.org/html/= draft-mizrahi-tictoc-checksum-trailer-00

Comments will be welcome.

&nbs= p;

Thanks.

Tal.

= --_000_74470498B659FA4687F0B0018C19A89C01223E573C5AILMB01marve_-- --===============3758786936821864637== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============3758786936821864637==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 11 08:31:02 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AC121F8D4B for ; Mon, 11 Jul 2011 08:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.341 X-Spam-Level: X-Spam-Status: No, score=-4.341 tagged_above=-999 required=5 tests=[AWL=2.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW+19nmdU8kc for ; Mon, 11 Jul 2011 08:31:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id C7DFC21F8B40 for ; Mon, 11 Jul 2011 08:30:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id EF41486D766 for ; Mon, 11 Jul 2011 15:30:56 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 2750486D4F0 for ; Mon, 11 Jul 2011 15:29:26 +0000 (UTC) Received: from mail5.symmetricom.com ([69.25.98.10]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QgIQ7-0004tb-DV for ntpwg@lists.ntp.org; Mon, 11 Jul 2011 15:29:26 +0000 X-ASG-Debug-ID: 1310398148-11aa0d2b0001-dac64w Received: from SJC-HUB-01.symmetricom.com ([192.168.10.171]) by mail5.symmetricom.com with ESMTP id MjO2N40uRW4W6kbq; Mon, 11 Jul 2011 08:29:08 -0700 (PDT) X-Barracuda-Envelope-From: GDowd@symmetricom.com Received: from SJC-MBX-01.symmetricom.com ([169.254.1.52]) by SJC-HUB-01.symmetricom.com ([::1]) with mapi id 14.01.0289.001; Mon, 11 Jul 2011 08:29:08 -0700 From: Greg Dowd To: Tal Mizrahi , "tictoc@ietf.org" , "ntpwg@lists.ntp.org" Thread-Topic: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-ASG-Orig-Subj: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00 Thread-Index: Acw6QVZgcbH3mJzTRZOF+kYbuNTxSAFnDh3Q Date: Mon, 11 Jul 2011 15:29:08 +0000 Message-ID: <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.18] MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.10.171] X-Barracuda-Start-Time: 1310398148 X-Barracuda-URL: http://192.168.10.96:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at symmetricom.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 X-SA-Exim-Connect-IP: 69.25.98.10 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: btv1==17333bec5a8==GDowd@symmetricom.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7826442224188625338==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org --===============7826442224188625338== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_26FBD265CD8D234EAF41115A180F92BB38AE2BBCSJCMBX01symmetr_" --_000_26FBD265CD8D234EAF41115A180F92BB38AE2BBCSJCMBX01symmetr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is the use model you envision for NTP to support hardware timestamping at t= he edge? In NTP, the addition of an extension field requires the presence = of the MAC. This requires the dissemination and maintenance of keys as wel= l 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 t= he authenticator would fail. Or do you expect this block would have the ke= y 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 a= s 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 add= itional UDP checksum update adds? Is there a model you have in mind? From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Tal Mizrahi Sent: Monday, July 04, 2011 5:01 AM To: tictoc@ietf.org; ntpwg@lists.ntp.org Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-= 00 Hi, I have posted a new draft that discusses Checksum updates in time synchroni= zation protocols. http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00 Comments will be welcome. Thanks. Tal. --_000_26FBD265CD8D234EAF41115A180F92BB38AE2BBCSJCMBX01symmetr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is the use model you e= nvision 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 wo= rk if the NTP packet did  have the MAC?  This extension field wou= ld 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 sim= ply at the edge, I’m not sure how much value this additional UDP chec= ksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-b= ounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-t= railer-00

 

Hi,

 

I have posted a new draft that discusses Checksum up= dates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc= -checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

--_000_26FBD265CD8D234EAF41115A180F92BB38AE2BBCSJCMBX01symmetr_-- --===============7826442224188625338== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============7826442224188625338==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Jul 12 07:45:57 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382D021F8CFE for ; Tue, 12 Jul 2011 07:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.412 X-Spam-Level: X-Spam-Status: No, score=-5.412 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQIrJUdgGg7w for ; Tue, 12 Jul 2011 07:45:55 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 60C1421F8C72 for ; Tue, 12 Jul 2011 07:45:54 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BADDF86D781 for ; Tue, 12 Jul 2011 14:45:53 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 599A886D4F0 for ; Tue, 12 Jul 2011 14:44:29 +0000 (UTC) Received: from galiil.marvell.com ([199.203.130.254]) by mail1.ntp.org with esmtps (TLSv1:RC4-MD5:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QgeC7-000AT1-LD for ntpwg@lists.ntp.org; Tue, 12 Jul 2011 14:44:29 +0000 From: Tal Mizrahi To: Greg Dowd , "tictoc@ietf.org" , "ntpwg@lists.ntp.org" Date: Tue, 12 Jul 2011 17:44:02 +0300 Thread-Topic: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00 Thread-Index: Acw6QVZgcbH3mJzTRZOF+kYbuNTxSAFnDh3QAC/MAoA= Message-ID: <74470498B659FA4687F0B0018C19A89C01223E5F470F@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> In-Reply-To: <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-SA-Exim-Connect-IP: 199.203.130.254 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: talmi@marvell.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8190834664322594865==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org --===============8190834664322594865== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01223E5F470FILMB01marve_" --_000_74470498B659FA4687F0B0018C19A89C01223E5F470FILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your feedback. > In NTP, the addition of an extension field requires the presence of the M= AC. [TM] According to RFC5905 "The extension fields are used to add optional ca= pabilities, for example, the Autokey security protocol". So indeed, the onl= y extension field currently defined is for security purposes, but the curre= nt draft proposes to use a newly defined extension field, independent of th= e 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 no= des. When the MAC is used, it would mean that the intermediate node would h= ave 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 a= dditional 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 pack= et's timestamp field, significantly improving the accuracy. The benefit of = this improvement is negligible if the path between the NTP nodes consists o= f a large number of hops, BUT when there is a small number of hops this imp= rovement is significant. An example use-case I have in mind is in the wirel= ess backhaul, where the RBS and RNC synchronize over a CES, either using PT= P or NTP. When NTP is used in this case, high precision is required, and ca= n benefit from timestamping at the intermediate node. Regards, Tal. From: Greg Dowd [mailto:GDowd@symmetricom.com] Sent: Monday, July 11, 2011 6:29 PM To: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trai= ler-00 Is the use model you envision for NTP to support hardware timestamping at t= he edge? In NTP, the addition of an extension field requires the presence = of the MAC. This requires the dissemination and maintenance of keys as wel= l 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 t= he authenticator would fail. Or do you expect this block would have the ke= y 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 a= s 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 add= itional UDP checksum update adds? Is there a model you have in mind? From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Tal Mizrahi Sent: Monday, July 04, 2011 5:01 AM To: tictoc@ietf.org; ntpwg@lists.ntp.org Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-= 00 Hi, I have posted a new draft that discusses Checksum updates in time synchroni= zation protocols. http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00 Comments will be welcome. Thanks. Tal. --_000_74470498B659FA4687F0B0018C19A89C01223E5F470FILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your feedback.

 

=

> In NTP, the addition of an extension field requires the= presence of the MAC.

[TM] According to R= FC5905 “The extension fields are used to add optional capabilities, f= or example, the Autokey security protocol”. So indeed, the only exten= sion field currently defined is for security purposes, but the current draf= t proposes to use a newly defined extension field, independent of the MAC u= sage.

 

> 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 simp= lifying the implementation of intermediate nodes. When the MAC is used, it = would mean that the intermediate node would have to compute the MAC, and on= ly then to perform the Checksum update.

 

> If you define this simply at the edge, I’m not sure how muc= h value this additional UDP checksum update adds?  Is there a model yo= u have in mind?

[TM] The idea is that the intermediate node (an ASIC/FPGA) ass= igns the packet’s timestamp field, significantly improving the accura= cy. The benefit of this improvement is negligible if the path between the N= TP nodes consists of a large number of hops, BUT when there is a small numb= er of hops this improvement is significant. An example use-case I have in m= ind is in the wireless backhaul, where the RBS and RNC synchronize over a C= ES, 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:GDowd@symmetricom.com]
Sent: Monda= y, July 11, 2011 6:29 PM
To: Tal Mizrahi; tictoc@ietf.org; ntpwg@= lists.ntp.org
Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizr= ahi-tictoc-checksum-trailer-00

 

Is the use model you envision for NTP to support hardware timestampi= ng at the edge?  In NTP, the addition of an extension field requires t= he presence of the MAC.  This requires the dissemination and maintenan= ce 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 w= ould be covered by the MAC and the authenticator would fail.  Or do yo= u expect this block would have the key info and update the MAC as well?&nbs= p; And, how would it work if the MAC isn’t there.  Would the upd= ate not be used?

 

In PTP, there is a TC protocol function which necessitat= es 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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] <= b>On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 A= M
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TI= CTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Hi,

 

I have posted a new draft that discusses Checksum update= s in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00

Comments will be welcome.

<= p class=3DMsoNormal> 

Thanks.<= /o:p>

Tal.

= --_000_74470498B659FA4687F0B0018C19A89C01223E5F470FILMB01marve_-- --===============8190834664322594865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============8190834664322594865==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Jul 12 09:55:48 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24D21F8E48 for ; Tue, 12 Jul 2011 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hkbJ1T-D2Xf for ; Tue, 12 Jul 2011 09:55:44 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 828EC21F8CEC for ; Tue, 12 Jul 2011 09:55:43 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id CE21186D763 for ; Tue, 12 Jul 2011 16:55:42 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 7196A86D4F0 for ; Tue, 12 Jul 2011 16:51:40 +0000 (UTC) Received: from mail5.symmetricom.com ([69.25.98.10]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QggBC-000ObM-Dx for ntpwg@lists.ntp.org; Tue, 12 Jul 2011 16:51:40 +0000 X-ASG-Debug-ID: 1310489479-11aa29700001-dac64w Received: from SJC-HUB-01.symmetricom.com ([192.168.10.171]) by mail5.symmetricom.com with ESMTP id YLpjE2QpzMr7Xa9d; Tue, 12 Jul 2011 09:51:19 -0700 (PDT) X-Barracuda-Envelope-From: GDowd@symmetricom.com Received: from SJC-MBX-01.symmetricom.com ([169.254.1.52]) by SJC-HUB-01.symmetricom.com ([::1]) with mapi id 14.01.0289.001; Tue, 12 Jul 2011 09:51:19 -0700 From: Greg Dowd To: Tal Mizrahi , "tictoc@ietf.org" , "ntpwg@lists.ntp.org" Thread-Topic: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-ASG-Orig-Subj: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00 Thread-Index: Acw6QVZgcbH3mJzTRZOF+kYbuNTxSAFnDh3QAC/MAoAABZq3IA== Date: Tue, 12 Jul 2011 16:51:19 +0000 Message-ID: <26FBD265CD8D234EAF41115A180F92BB38AE37CD@SJC-MBX-01.symmetricom.com> References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <74470498B659FA4687F0B0018C19A89C01223E5F470F@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01223E5F470F@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.18] MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.10.171] X-Barracuda-Start-Time: 1310489479 X-Barracuda-URL: http://192.168.10.96:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at symmetricom.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 X-SA-Exim-Connect-IP: 69.25.98.10 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: btv1==1743a3f939d==GDowd@symmetricom.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4008163966234897004==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org --===============4008163966234897004== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_26FBD265CD8D234EAF41115A180F92BB38AE37CDSJCMBX01symmetr_" --_000_26FBD265CD8D234EAF41115A180F92BB38AE37CDSJCMBX01symmetr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal, The MAC is a necessary component in the current protocol wh= en extensions are present. The parsing of incoming packets uses frame size= as mechanism for determining the code path to take in addition to its obvi= ous utility value in autokey. The relevant section in 5905 is the first se= ntence 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:talmi@marvell.com] Sent: Tuesday, July 12, 2011 7:44 AM To: Greg Dowd; tictoc@ietf.org; ntpwg@lists.ntp.org Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trai= ler-00 Hi Greg, Thanks for your feedback. > In NTP, the addition of an extension field requires the presence of the M= AC. [TM] According to RFC5905 "The extension fields are used to add optional ca= pabilities, for example, the Autokey security protocol". So indeed, the onl= y extension field currently defined is for security purposes, but the curre= nt draft proposes to use a newly defined extension field, independent of th= e 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 no= des. When the MAC is used, it would mean that the intermediate node would h= ave 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 a= dditional 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 pack= et's timestamp field, significantly improving the accuracy. The benefit of = this improvement is negligible if the path between the NTP nodes consists o= f a large number of hops, BUT when there is a small number of hops this imp= rovement is significant. An example use-case I have in mind is in the wirel= ess backhaul, where the RBS and RNC synchronize over a CES, either using PT= P or NTP. When NTP is used in this case, high precision is required, and ca= n benefit from timestamping at the intermediate node. Regards, Tal. From: Greg Dowd [mailto:GDowd@symmetricom.com] Sent: Monday, July 11, 2011 6:29 PM To: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trai= ler-00 Is the use model you envision for NTP to support hardware timestamping at t= he edge? In NTP, the addition of an extension field requires the presence = of the MAC. This requires the dissemination and maintenance of keys as wel= l 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 t= he authenticator would fail. Or do you expect this block would have the ke= y 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 a= s 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 add= itional UDP checksum update adds? Is there a model you have in mind? From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Tal Mizrahi Sent: Monday, July 04, 2011 5:01 AM To: tictoc@ietf.org; ntpwg@lists.ntp.org Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-= 00 Hi, I have posted a new draft that discusses Checksum updates in time synchroni= zation protocols. http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00 Comments will be welcome. Thanks. Tal. --_000_26FBD265CD8D234EAF41115A180F92BB38AE37CDSJCMBX01symmetr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal,

   &nbs= p;            The MA= C is a necessary component in the current protocol when extensions are pres= ent.  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 590= 5 is the first sentence in the NTP Extension Field Format section 7.5.=

In NTPv4, o= ne 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 Mizr= ahi [mailto:talmi@marvell.com]
Sent: Tuesday, July 12, 2011 7:44 AM
To: Greg Dowd; tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checks= um-trailer-00

 

Hi Greg,

 

Thanks for your feedba= ck.

 

> In NTP, the addit= ion of an extension field requires the presence of the MAC.

[TM] According to RFC5= 905 “The extension fields are used to add optional capabilities, for = example, the Autokey security protocol”. So indeed, the only extensio= n field currently defined is for security purposes, but the current draft proposes to use a newly defined extension field, ind= ependent of the MAC usage.

 

> How would this mo= del work if the NTP packet did  have the MAC? <= /p>

[TM] The current draft= is more useful for cases where the MAC is not used, since this draft is ab= out simplifying the implementation of intermediate nodes. When the MAC is u= sed, it would mean that the intermediate node would have to compute the MAC, and only then to perform the Checksum = update.

 

> If you define thi= s 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?<= /span>

[TM] The idea is that = the intermediate node (an ASIC/FPGA) assigns the packet’s timestamp f= ield, 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 min= d 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 Dow= d [mailto:GDowd@symmetricom.com]
Sent: Monday, July 11, 2011 6:29 PM
To: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checks= um-trailer-00

 

Is the use model you e= nvision 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 wo= rk if the NTP packet did  have the MAC?  This extension field wou= ld 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 sim= ply at the edge, I’m not sure how much value this additional UDP chec= ksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-b= ounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-t= railer-00

 

Hi,

 

I have posted a new draft that discusses Checksum up= dates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc= -checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

--_000_26FBD265CD8D234EAF41115A180F92BB38AE37CDSJCMBX01symmetr_-- --===============4008163966234897004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============4008163966234897004==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jul 13 11:00:35 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33B811E808E for ; Wed, 13 Jul 2011 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-EAD3sbm3tB for ; Wed, 13 Jul 2011 11:00:33 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 309F311E808C for ; Wed, 13 Jul 2011 11:00:29 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 528F486D763 for ; Wed, 13 Jul 2011 18:00:28 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 5B70E86D4F0 for ; Wed, 13 Jul 2011 17:54:12 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qh3dH-000F89-Of for ntpwg@lists.ntp.org; Wed, 13 Jul 2011 17:54:12 +0000 Received: from [192.168.1.3] (pool-74-109-5-222.phlapa.fios.verizon.net [74.109.5.222]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 95719736; Wed, 13 Jul 2011 13:53:58 -0400 (EDT) Message-ID: <4E1DDBB6.3020302@udel.edu> Date: Wed, 13 Jul 2011 17:53:58 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Dowd References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> In-Reply-To: <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6514473979875095752==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============6514473979875095752== Content-Type: multipart/alternative; boundary="------------080605000408080406050408" This is a multi-part message in MIME format. --------------080605000408080406050408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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? > > > > > > > > > > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On > Behalf Of Tal Mizrahi > Sent: Monday, July 04, 2011 5:01 AM > To: tictoc@ietf.org; ntpwg@lists.ntp.org > Subject: [TICTOC] [ntpwg] New draft: > draft-mizrahi-tictoc-checksum-trailer-00 > > > > 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. > >------------------------------------------------------------------------ > >_______________________________________________ >ntpwg mailing list >ntpwg@lists.ntp.org >http://lists.ntp.org/listinfo/ntpwg > --------------080605000408080406050408 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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?

 

 

 

 

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

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.


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

--------------080605000408080406050408-- --===============6514473979875095752== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============6514473979875095752==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jul 13 11:32:39 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0072711E80B1 for ; Wed, 13 Jul 2011 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.882 X-Spam-Level: X-Spam-Status: No, score=-4.882 tagged_above=-999 required=5 tests=[AWL=1.715, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U19hUnQPQup for ; Wed, 13 Jul 2011 11:32:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id E03B111E8095 for ; Wed, 13 Jul 2011 11:32:35 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4884486D784 for ; Wed, 13 Jul 2011 18:32:35 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 7185786D4F0 for ; Wed, 13 Jul 2011 18:22:43 +0000 (UTC) Received: from mail5.symmetricom.com ([69.25.98.10]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qh44s-000Fhy-M6 for ntpwg@lists.ntp.org; Wed, 13 Jul 2011 18:22:43 +0000 X-ASG-Debug-ID: 1310581343-11aa455c0001-dac64w Received: from SJC-HUB-01.symmetricom.com ([192.168.10.171]) by mail5.symmetricom.com with ESMTP id lzTyRT7mQcfJcpN6; Wed, 13 Jul 2011 11:22:23 -0700 (PDT) X-Barracuda-Envelope-From: GDowd@symmetricom.com Received: from SJC-MBX-01.symmetricom.com ([169.254.1.52]) by SJC-HUB-01.symmetricom.com ([::1]) with mapi id 14.01.0289.001; Wed, 13 Jul 2011 11:22:23 -0700 From: Greg Dowd To: "David L. Mills" Thread-Topic: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-ASG-Orig-Subj: RE: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 Thread-Index: AQHMQYXYEZ8XM4eYrkOcQ+bAz02RfpTqi38w Date: Wed, 13 Jul 2011 18:22:23 +0000 Message-ID: <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> In-Reply-To: <4E1DDBB6.3020302@udel.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.42] MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.10.171] X-Barracuda-Start-Time: 1310581343 X-Barracuda-URL: http://192.168.10.96:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at symmetricom.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 X-SA-Exim-Connect-IP: 69.25.98.10 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: btv1==175cd238c05==GDowd@symmetricom.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5363305131335859134==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org --===============5363305131335859134== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_26FBD265CD8D234EAF41115A180F92BB38AE4838SJCMBX01symmetr_" --_000_26FBD265CD8D234EAF41115A180F92BB38AE4838SJCMBX01symmetr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The NTPv4 protocol, and the implementation, currently don't have the abilit= y to distinguish an extension from a MAC uniquely. I would rather see a "N= OOP" MAC (with keyid 0 or -1) function defined which would let nodes proces= s and drop the frame with auth failure and not a malformed packet. Looking beyond the protocol state machine, how could we include some indica= tor in the frame that it had been modified? Perhaps we could make some ext= ension 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 poss= ible to distinguish either the number or the timing characteristics of the = elements modifying the time. In a closed point-to-point protocol like tele= com style PTP this is not an issue as the links, and the capabilities of th= e 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 control= led or managed network. It could specifically call out the usage of hardwa= re timestamps where available, the format and/or requirement to generate an= extension, the restrictions on use of authenticators or autokey, the impac= t 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 "Everything should be made as simple as possible, but no simpler" Albert Ei= nstein From: David L. Mills [mailto:mills@udel.edu] Sent: Wednesday, July 13, 2011 10:54 AM To: Greg Dowd Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trai= ler-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 i= n PTP. Dave Greg Dowd wrote: Is the use model you envision for NTP to support hardware timestamping at t= he edge? In NTP, the addition of an extension field requires the presence = of the MAC. This requires the dissemination and maintenance of keys as wel= l 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 t= he authenticator would fail. Or do you expect this block would have the ke= y 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 a= s 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 add= itional UDP checksum update adds? Is there a model you have in mind? From: tictoc-bounces@ietf.org [mailto:ticto= c-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: Monday, July 04, 2011 5:01 AM To: tictoc@ietf.org; ntpwg@lists.ntp.org Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-= 00 Hi, I have posted a new draft that discusses Checksum updates in time synchroni= zation protocols. http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00 Comments will be welcome. Thanks. Tal. ________________________________ _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --_000_26FBD265CD8D234EAF41115A180F92BB38AE4838SJCMBX01symmetr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The NTPv4 protocol, an= d the implementation, currently don’t have the ability to distinguish= an extension from a MAC uniquely.  I would rather see a “NOOP&#= 8221; 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 pro= tocol 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 fiel= d.  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 con= trolled 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 authent= icators 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

"Everything should be made as simple as possible, but n= o simpler" Albert Einstein

From: David L. Mills= [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checks= um-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 i= n PTP.

Dave

Greg Dowd wrote:

Is the use model you e= nvision 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 wo= rk if the NTP packet did  have the MAC?  This extension field wou= ld 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 sim= ply at the edge, I’m not sure how much value this additional UDP chec= ksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-t= railer-00

 

Hi,

 

I have posted a new draft that discusses Checksum up= dates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc= -checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

 





 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/l=
istinfo/ntpwg

 

--_000_26FBD265CD8D234EAF41115A180F92BB38AE4838SJCMBX01symmetr_-- --===============5363305131335859134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============5363305131335859134==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jul 13 12:17:53 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6E311E808C for ; Wed, 13 Jul 2011 12:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.52 X-Spam-Level: X-Spam-Status: No, score=-4.52 tagged_above=-999 required=5 tests=[AWL=2.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s7KsQYhpzsX for ; Wed, 13 Jul 2011 12:17:49 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 114C411E80AF for ; Wed, 13 Jul 2011 12:17:49 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 50B4986D790 for ; Wed, 13 Jul 2011 19:17:46 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 4E2B686D4F0 for ; Wed, 13 Jul 2011 19:08:35 +0000 (UTC) Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qh4nF-000MUW-F2 for ntpwg@lists.ntp.org; Wed, 13 Jul 2011 19:08:35 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=L8p3ac8nKv6jYqFRbFweaH4nIaGCC6Gu5kGPmxWy6MrGHQdFonKAwlXPIAE6vCiU; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qh4n8-0003vQ-Dl for ntpwg@lists.ntp.org; Wed, 13 Jul 2011 15:08:15 -0400 Message-ID: <4E1DED40.7080007@earthlink.net> Date: Wed, 13 Jul 2011 12:08:48 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ntpwg@lists.ntp.org References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> In-Reply-To: <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79db1ae361ab9cd7317261b247ce9b03bb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 X-SA-Exim-Connect-IP: 209.86.89.69 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: tglassey@earthlink.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8103314504959263556==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============8103314504959263556== Content-Type: multipart/alternative; boundary="------------080509090908020609080204" This is a multi-part message in MIME format. --------------080509090908020609080204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/13/2011 11:22 AM, Greg Dowd wrote: > > 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? > You only need this if there is a new set of policies that are to be supported. If so what are the policies to be. > 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 > > "Everything should be made as simple as possible, but no simpler" > Albert Einstein > > *From:*David L. Mills [mailto:mills@udel.edu] > *Sent:* Wednesday, July 13, 2011 10:54 AM > *To:* Greg Dowd > *Cc:* Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org > *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: > > 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:*tictoc-bounces@ietf.org > [mailto:tictoc-bounces@ietf.org] *On Behalf Of *Tal Mizrahi > *Sent:* Monday, July 04, 2011 5:01 AM > *To:* tictoc@ietf.org ; ntpwg@lists.ntp.org > > *Subject:* [TICTOC] [ntpwg] New draft: > draft-mizrahi-tictoc-checksum-trailer-00 > > 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. > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. --------------080509090908020609080204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/13/2011 11:22 AM, Greg Dowd wrote:

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? 

You only need this if there is a new set of policies that are to be supported. If so what are the policies to be.

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

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: David L. Mills [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
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:

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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

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.

 



 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

 


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg


-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.
--------------080509090908020609080204-- --===============8103314504959263556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============8103314504959263556==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jul 13 21:49:22 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241C721F86AC for ; Wed, 13 Jul 2011 21:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84BvTubIqzsU for ; Wed, 13 Jul 2011 21:49:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 2225221F85E2 for ; Wed, 13 Jul 2011 21:49:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A460186D78D for ; Thu, 14 Jul 2011 04:49:15 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 739C586D4F0 for ; Thu, 14 Jul 2011 04:32:29 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QhDax-0006vk-VE for ntpwg@lists.ntp.org; Thu, 14 Jul 2011 04:32:29 +0000 Received: from [192.168.1.3] (pool-74-109-5-222.phlapa.fios.verizon.net [74.109.5.222]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id CA7DE379; Thu, 14 Jul 2011 00:32:14 -0400 (EDT) Message-ID: <4E1E714F.60104@udel.edu> Date: Thu, 14 Jul 2011 04:32:15 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: todd glassey References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> In-Reply-To: <4E1DED40.7080007@earthlink.net> X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4724586152325720074==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============4724586152325720074== Content-Type: multipart/alternative; boundary="------------020409010409060109020102" This is a multi-part message in MIME format. --------------020409010409060109020102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit todd, A careful read of the specification should give you comfort that the parsing rules do distinguish between an extension field and a MAC. In particular, the rules permit one or more extension fields without a MAC. The only requirement is that a MAC, if present, must be the last field. Dave todd glassey wrote: > On 7/13/2011 11:22 AM, Greg Dowd wrote: > >> 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? >> > You only need this if there is a new set of policies that are to be > supported. If so what are the policies to be. > >> 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 >> >> "Everything should be made as simple as possible, but no simpler" >> Albert Einstein >> >> From: David L. Mills [mailto:mills@udel.edu] >> Sent: Wednesday, July 13, 2011 10:54 AM >> To: Greg Dowd >> Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org >> 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: >> >> 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: tictoc-bounces@ietf.org >> [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi >> Sent: Monday, July 04, 2011 5:01 AM >> To: tictoc@ietf.org ; ntpwg@lists.ntp.org >> >> Subject: [TICTOC] [ntpwg] New draft: >> draft-mizrahi-tictoc-checksum-trailer-00 >> >> >> >> 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. >> >> >> >>------------------------------------------------------------------------ >> >> >> >> >> >> >>_______________________________________________ >> >>ntpwg mailing list >> >>ntpwg@lists.ntp.org >> >>http://lists.ntp.org/listinfo/ntpwg >> >> >> >> >>_______________________________________________ >>ntpwg mailing list >>ntpwg@lists.ntp.org >>http://lists.ntp.org/listinfo/ntpwg >> > > >-- >Todd S. Glassey >This is from my personal email account and any materials from this account come with personal disclaimers. > >Further I OPT OUT of any and all commercial emailings. > > >------------------------------------------------------------------------ > >_______________________________________________ >ntpwg mailing list >ntpwg@lists.ntp.org >http://lists.ntp.org/listinfo/ntpwg > --------------020409010409060109020102 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit todd,

A careful read of the specification should give you comfort that the parsing rules do distinguish between an extension field and a MAC. In particular, the rules permit one or more extension fields without a MAC. The only requirement is that a MAC, if present, must be the last field.

Dave

todd glassey wrote:
On 7/13/2011 11:22 AM, Greg Dowd wrote:

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? 

You only need this if there is a new set of policies that are to be supported. If so what are the policies to be.

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

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: David L. Mills [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
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:

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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

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.

 


    
 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

 


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg


-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings. 
  

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

--------------020409010409060109020102-- --===============4724586152325720074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============4724586152325720074==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jul 14 07:10:20 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9195F21F89FF for ; Thu, 14 Jul 2011 07:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8S25mwBp7+4 for ; Thu, 14 Jul 2011 07:10:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE5A21F8959 for ; Thu, 14 Jul 2011 07:10:15 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C274986D763 for ; Thu, 14 Jul 2011 14:09:58 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 53CC386D4F0 for ; Thu, 14 Jul 2011 13:44:46 +0000 (UTC) Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QhMDQ-000KHt-Nw for ntpwg@lists.ntp.org; Thu, 14 Jul 2011 13:44:46 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZeopWC/oQxwO5W801b34AE4pWTai4nHBDSEFNO1BV14Ezdvq1UEkVlCZxbDRp9+C; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QhMDJ-00085e-VJ; Thu, 14 Jul 2011 09:44:26 -0400 Message-ID: <4E1EF2DB.80802@earthlink.net> Date: Thu, 14 Jul 2011 06:44:59 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "David L. Mills" References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> In-Reply-To: <4E1E714F.60104@udel.edu> X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec797bdcf446a8de373b593e05556b1dc715350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-SA-Exim-Connect-IP: 209.86.89.66 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: tglassey@earthlink.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8073122673536897237==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============8073122673536897237== Content-Type: multipart/alternative; boundary="------------070600050508090206030006" This is a multi-part message in MIME format. --------------070600050508090206030006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/13/2011 9:32 PM, David L. Mills wrote: > todd, > > A careful read of the specification should give you comfort that the > parsing rules do distinguish between an extension field and a MAC. In > particular, the rules permit one or more extension fields without a > MAC. The only requirement is that a MAC, if present, must be the last > field. Yes David - of course they do. I was talking about the idea of designing the protocol based on specific policies it delivered something totally to the group at this point but something that needs to happen. Todd > > Dave > > todd glassey wrote: >> On 7/13/2011 11:22 AM, Greg Dowd wrote: >>> >>> 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? >>> >> You only need this if there is a new set of policies that are to be >> supported. If so what are the policies to be. >> >>> 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 >>> >>> "Everything should be made as simple as possible, but no simpler" >>> Albert Einstein >>> >>> *From:*David L. Mills [mailto:mills@udel.edu] >>> *Sent:* Wednesday, July 13, 2011 10:54 AM >>> *To:* Greg Dowd >>> *Cc:* Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org >>> *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: >>> >>> 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:*tictoc-bounces@ietf.org >>> [mailto:tictoc-bounces@ietf.org] *On Behalf Of *Tal Mizrahi >>> *Sent:* Monday, July 04, 2011 5:01 AM >>> *To:* tictoc@ietf.org ; ntpwg@lists.ntp.org >>> >>> *Subject:* [TICTOC] [ntpwg] New draft: >>> draft-mizrahi-tictoc-checksum-trailer-00 >>> >>> 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. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> _______________________________________________ >>> ntpwg mailing list >>> ntpwg@lists.ntp.org >>> http://lists.ntp.org/listinfo/ntpwg >>> >>> >>> _______________________________________________ >>> ntpwg mailing list >>> ntpwg@lists.ntp.org >>> http://lists.ntp.org/listinfo/ntpwg >> >> >> -- >> Todd S. Glassey >> This is from my personal email account and any materials from this account come with personal disclaimers. >> >> Further I OPT OUT of any and all commercial emailings. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> ntpwg mailing list >> ntpwg@lists.ntp.org >> http://lists.ntp.org/listinfo/ntpwg > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. --------------070600050508090206030006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/13/2011 9:32 PM, David L. Mills wrote:
todd,

A careful read of the specification should give you comfort that the parsing rules do distinguish between an extension field and a MAC. In particular, the rules permit one or more extension fields without a MAC. The only requirement is that a MAC, if present, must be the last field.
Yes David - of course they do. I was talking about the idea of designing the protocol based on specific policies it delivered something totally to the group at this point but something that needs to happen.

Todd

Dave

todd glassey wrote:
On 7/13/2011 11:22 AM, Greg Dowd wrote:

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? 

You only need this if there is a new set of policies that are to be supported. If so what are the policies to be.

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

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: David L. Mills [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
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:

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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

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.

 


    
 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

 


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg


-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings. 
  

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.
--------------070600050508090206030006-- --===============8073122673536897237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============8073122673536897237==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jul 14 09:09:20 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33D921F8D12 for ; Thu, 14 Jul 2011 09:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBN5bSOKue9E for ; Thu, 14 Jul 2011 09:09:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id C35B821F8D1F for ; Thu, 14 Jul 2011 09:09:15 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 2CA3186D83E for ; Thu, 14 Jul 2011 16:09:15 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id B9C6886D4F0 for ; Thu, 14 Jul 2011 15:50:31 +0000 (UTC) Received: from mail-vw0-f41.google.com ([209.85.212.41]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QhOBA-00083b-3I for ntpwg@lists.ntp.org; Thu, 14 Jul 2011 15:50:31 +0000 Received: by vws4 with SMTP id 4so405756vws.14 for ; Thu, 14 Jul 2011 08:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; bh=wLUDSiHdaD+euC8a4ZhNFWvl0TBWDUU7RzpVMgy0Fu4=; b=KCAkXH8HhitqcvrzXRe2l0wzJXzVgQ3mnocmJWZVFnOiwVEXVSS6Vjq3uwodhDzEZn N0F3GUGHJAwqGVivi5kpY15L/k0ducI8vzKRmCEQWx9GKcJGatuBaR8lrjPkJhEdr3hp IMqmGsPri1Ll2ViWrFbCoN2OO2U+QCG5v7Fjc= Received: by 10.52.90.106 with SMTP id bv10mr2493245vdb.142.1310658613795; Thu, 14 Jul 2011 08:50:13 -0700 (PDT) Received: from kodonog-mac.local (d-74-214-49-212.cpe.metrocast.net [74.214.49.212]) by mx.google.com with ESMTPS id es2sm238933vbb.19.2011.07.14.08.50.12 (version=SSLv3 cipher=OTHER); Thu, 14 Jul 2011 08:50:12 -0700 (PDT) Message-ID: <4E1F1033.3000308@pobox.com> Date: Thu, 14 Jul 2011 11:50:11 -0400 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: tictoc@ietf.org, NTP Working Group X-SA-Exim-Connect-IP: 209.85.212.41 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kodonog@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] draft agenda for ietf81 tictoc meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: kodonog@pobox.com List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Folks, Below is a draft agenda for the upcoming tictoc meeting. Please send Yaakov and I any changes and additions as soon as possible. Regards, Karen IETF-81 TICTOC WG Agenda ======================== Thursday, 28 July 2011, 1520-1720 EDT (1940 - 2140 UTC / 1220 - 1420 PDT) 1. Administrivia and Agenda Bashing 2. ITU-T SG15/Q13 update 3. IPsec security for packet based synchronization draft-xu-tictoc-ipsec-security-for-synchronization-01 4. Time Synchronization Protocol Security Requirements 5. Precision Time Protocol Version 2 (PTPv2) Management Information Base draft-ietf-tictoc-ptp-mib-00 6. Transporting PTP messages (1588) over MPLS Networks draft-ietf-tictoc-1588overmpls-01 7. UDP Checksum Trailer in Timing Protocols draft-mizrahi-tictoc-checksum-trailer-00.txt 8. Network Time Mechanisms for Improving Computer Clock Accuracy draft-marlow-tictoc-computer-clock-accuracy-00 9. Additional NTP Discussion Topics 10. Wrap-up / Way Forward _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jul 14 09:42:01 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7721F8D31 for ; Thu, 14 Jul 2011 09:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.072 X-Spam-Level: X-Spam-Status: No, score=-5.072 tagged_above=-999 required=5 tests=[AWL=1.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjZhbr6w9-h3 for ; Thu, 14 Jul 2011 09:41:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3407E21F8D07 for ; Thu, 14 Jul 2011 09:41:56 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 676F786D844 for ; Thu, 14 Jul 2011 16:41:55 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id DB2F186D4F0 for ; Thu, 14 Jul 2011 16:11:01 +0000 (UTC) Received: from mail5.symmetricom.com ([69.25.98.10]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QhOUx-000BTB-Bh for ntpwg@lists.ntp.org; Thu, 14 Jul 2011 16:11:01 +0000 X-ASG-Debug-ID: 1310659836-11aa57ae0003-dac64w Received: from SJC-HUB-01.symmetricom.com ([192.168.10.171]) by mail5.symmetricom.com with ESMTP id 0e4U3PkFEzPERWVU; Thu, 14 Jul 2011 09:10:39 -0700 (PDT) X-Barracuda-Envelope-From: GDowd@symmetricom.com Received: from SJC-MBX-01.symmetricom.com ([169.254.1.52]) by SJC-HUB-01.symmetricom.com ([::1]) with mapi id 14.01.0289.001; Thu, 14 Jul 2011 09:10:38 -0700 From: Greg Dowd To: "David L. Mills" Thread-Topic: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-ASG-Orig-Subj: RE: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 Thread-Index: AQHMQeFiZOq92daqI0ey0azU1UMp15Tr/Low Date: Thu, 14 Jul 2011 16:10:38 +0000 Message-ID: <26FBD265CD8D234EAF41115A180F92BB38AE5335@SJC-MBX-01.symmetricom.com> References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> In-Reply-To: <4E1E714F.60104@udel.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.42] MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.10.171] X-Barracuda-Start-Time: 1310659839 X-Barracuda-URL: http://192.168.10.96:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at symmetricom.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 X-SA-Exim-Connect-IP: 69.25.98.10 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: btv1==176bdfc4b6c==GDowd@symmetricom.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ntpwg@lists.ntp.org" Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3534903059691720101==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org --===============3534903059691720101== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_26FBD265CD8D234EAF41115A180F92BB38AE5335SJCMBX01symmetr_" --_000_26FBD265CD8D234EAF41115A180F92BB38AE5335SJCMBX01symmetr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When you say specification, do you mean something other than the RFC5905 do= cument? Here is the RFC language. The relevant section in 5905 is the first sentence in the NTP Extension Fie= ld 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. Greg Dowd gdowd at symmetricom dot com (antispam format) Symmetricom, Inc. www.symmetricom.com "Everything should be made as simple as possible, but no simpler" Albert Ei= nstein From: ntpwg-bounces+gdowd=3Dsymmetricom.com@lists.ntp.org [mailto:ntpwg-bou= nces+gdowd=3Dsymmetricom.com@lists.ntp.org] On Behalf Of David L. Mills Sent: Wednesday, July 13, 2011 9:32 PM To: todd glassey Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trai= ler-00 todd, A careful read of the specification should give you comfort that the parsin= g rules do distinguish between an extension field and a MAC. In particular,= the rules permit one or more extension fields without a MAC. The only requ= irement is that a MAC, if present, must be the last field. Dave todd glassey wrote: On 7/13/2011 11:22 AM, Greg Dowd wrote: The NTPv4 protocol, and the implementation, currently don't have the abilit= y to distinguish an extension from a MAC uniquely. I would rather see a "N= OOP" MAC (with keyid 0 or -1) function defined which would let nodes proces= s and drop the frame with auth failure and not a malformed packet. Looking beyond the protocol state machine, how could we include some indica= tor in the frame that it had been modified? You only need this if there is a new set of policies that are to be support= ed. If so what are the policies to be. 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 cor= rection field. It is not possible to distinguish either the number or the = timing characteristics of the elements modifying the time. In a closed poi= nt-to-point protocol like telecom style PTP this is not an issue as the lin= ks, 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 specificall= y call out the usage of hardware timestamps where available, the format and= /or requirement to generate an extension, the restrictions on use of authen= ticators 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 "Everything should be made as simple as possible, but no simpler" Albert Ei= nstein From: David L. Mills [mailto:mills@udel.edu] Sent: Wednesday, July 13, 2011 10:54 AM To: Greg Dowd Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.o= rg Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trai= ler-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 i= n PTP. Dave Greg Dowd wrote: Is the use model you envision for NTP to support hardware timestamping at t= he edge? In NTP, the addition of an extension field requires the presence = of the MAC. This requires the dissemination and maintenance of keys as wel= l 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 t= he authenticator would fail. Or do you expect this block would have the ke= y 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 a= s 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 add= itional UDP checksum update adds? Is there a model you have in mind? From: tictoc-bounces@ietf.org [mailto:ticto= c-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: Monday, July 04, 2011 5:01 AM To: tictoc@ietf.org; ntpwg@lists.ntp.org Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-= 00 Hi, I have posted a new draft that discusses Checksum updates in time synchroni= zation protocols. http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00 Comments will be welcome. Thanks. Tal. ________________________________ _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg -- Todd S. Glassey This is from my personal email account and any materials from this account = come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ________________________________ _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --_000_26FBD265CD8D234EAF41115A180F92BB38AE5335SJCMBX01symmetr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When you say specifica= tion, do you mean something other than the RFC5905 document?  Here is = the RFC language.

 

The relevant section i= n 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.<= o:p>

 

 

Greg Dowd

gdowd at symmetricom dot com (antispam format)

Symmetricom, Inc.

www.symmetricom.com

"Everything should be made as simple as possible, but n= o simpler" Albert Einstein

From: ntpwg-bounces&= #43;gdowd=3Dsymmetricom.com@lists.ntp.org [mailto:ntpwg-bounces+gdowd=3Dsymmetricom.com@lists.ntp.org] On Beh= alf Of David L. Mills
Sent: Wednesday, July 13, 2011 9:32 PM
To: todd glassey
Cc: ntpwg@lists.ntp.org
Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checks= um-trailer-00

 

todd,

A careful read of the specification should give you comfort that the parsin= g rules do distinguish between an extension field and a MAC. In particular,= the rules permit one or more extension fields without a MAC. The only requ= irement is that a MAC, if present, must be the last field.

Dave

todd glassey wrote:

On 7/13/2011 11:22 AM, Greg Dowd wrote: <= /p>

The NTPv4 protocol, an= d the implementation, currently don’t have the ability to distinguish= an extension from a MAC uniquely.  I would rather see a “NOOP&#= 8221; 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 pro= tocol state machine, how could we include some indicator in the frame that = it had been modified? 

You only need this if there is a new= set of policies that are to be supported. If so what are the policies to b= e.


Perhaps we could make = some extension mandatory?  One issue with the way TCs work in PTP is t= hat they are all doing a read-modify-write against the correction field.&nb= sp; It is not possible to distinguish either the number or the timing characteristics of the elements modifying the time.&n= bsp; 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-d= efined and managed.  In NTP, it would be useful to develop a “profile” which would define this NTP a= pplication over a controlled or managed network.  It could specificall= y 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 th= e dispersion/root distance fields, etc.

 

 

 

"Everything should be made as simple as possible, but n= o simpler" Albert Einstein

From: David L. Mills= [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org<= /a>; ntpwg@lists.ntp.org
Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checks= um-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 i= n PTP.

Dave

Greg Dowd wrote:


Is the use model you e= nvision 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 wo= rk if the NTP packet did  have the MAC?  This extension field wou= ld 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 sim= ply at the edge, I’m not sure how much value this additional UDP chec= ksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-t= railer-00

 

Hi,

 

I have posted a new draft that discusses Checksum up= dates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc= -checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

 





 
 
    
 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/l=
istinfo/ntpwg

 

 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/l=
istinfo/ntpwg




-- 
Todd S. Glassey
This is from my personal email account and any materials from this acc=
ount come with personal disclaimers. 
 
Further I OPT OUT of any and all commercial emailings. 

  


 









 


_______________________________________________


ntpwg mailing list


ntpwg@lists.ntp.org


http://lists.ntp.org/l=
istinfo/ntpwg


 
--_000_26FBD265CD8D234EAF41115A180F92BB38AE5335SJCMBX01symmetr_-- --===============3534903059691720101== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============3534903059691720101==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jul 14 22:13:48 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FDB21F86B1 for ; Thu, 14 Jul 2011 22:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQVhR4nk6uDj for ; Thu, 14 Jul 2011 22:13:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id B40BE21F865D for ; Thu, 14 Jul 2011 22:13:44 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 28BBD86D765 for ; Fri, 15 Jul 2011 05:13:43 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 116B486D4F0 for ; Fri, 15 Jul 2011 04:51:24 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QhaMn-000JQb-Ew for ntpwg@lists.ntp.org; Fri, 15 Jul 2011 04:51:24 +0000 Received: from [192.168.1.3] (pool-74-109-5-222.phlapa.fios.verizon.net [74.109.5.222]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 1ECC8F1F; Fri, 15 Jul 2011 00:51:08 -0400 (EDT) Message-ID: <4E1FC73D.1080003@udel.edu> Date: Fri, 15 Jul 2011 04:51:09 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: todd glassey References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> <4E1EF2DB.80802@earthlink.net> In-Reply-To: <4E1EF2DB.80802@earthlink.net> X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1160525921235639760==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============1160525921235639760== Content-Type: multipart/alternative; boundary="------------060704050601090506020600" This is a multi-part message in MIME format. --------------060704050601090506020600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit todd, I have not the slightest clue what you are advocaiting, but it is probably not anNTP extension field. Dave todd glassey wrote: > On 7/13/2011 9:32 PM, David L. Mills wrote: > >> todd, >> >> A careful read of the specification should give you comfort that the >> parsing rules do distinguish between an extension field and a MAC. In >> particular, the rules permit one or more extension fields without a >> MAC. The only requirement is that a MAC, if present, must be the last >> field. > > Yes David - of course they do. I was talking about the idea of > designing the protocol based on specific policies it delivered > something totally to the group at this point but something that needs > to happen. > > Todd > >> >> Dave >> >> todd glassey wrote: >> >>> On 7/13/2011 11:22 AM, Greg Dowd wrote: >>> >>>> 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? >>>> >>> You only need this if there is a new set of policies that are to be >>> supported. If so what are the policies to be. >>> >>>> 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 >>>> >>>> "Everything should be made as simple as possible, but no simpler" >>>> Albert Einstein >>>> >>>> From: David L. Mills [mailto:mills@udel.edu] >>>> Sent: Wednesday, July 13, 2011 10:54 AM >>>> To: Greg Dowd >>>> Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org >>>> 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: >>>> >>>> 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: tictoc-bounces@ietf.org >>>> [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi >>>> Sent: Monday, July 04, 2011 5:01 AM >>>> To: tictoc@ietf.org ; ntpwg@lists.ntp.org >>>> >>>> Subject: [TICTOC] [ntpwg] New draft: >>>> draft-mizrahi-tictoc-checksum-trailer-00 >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>> >>>>ntpwg mailing list >>>> >>>>ntpwg@lists.ntp.org >>>> >>>>http://lists.ntp.org/listinfo/ntpwg >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>ntpwg mailing list >>>>ntpwg@lists.ntp.org >>>>http://lists.ntp.org/listinfo/ntpwg >>>> >>> >>> >>>-- >>>Todd S. Glassey >>>This is from my personal email account and any materials from this account come with personal disclaimers. >>> >>>Further I OPT OUT of any and all commercial emailings. >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>ntpwg mailing list >>>ntpwg@lists.ntp.org >>>http://lists.ntp.org/listinfo/ntpwg >>> >> > > >-- >Todd S. Glassey >This is from my personal email account and any materials from this account come with personal disclaimers. > >Further I OPT OUT of any and all commercial emailings. > > --------------060704050601090506020600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit todd,

I have not the slightest clue what you are advocaiting, but it is probably not anNTP extension field.

Dave

todd glassey wrote:
On 7/13/2011 9:32 PM, David L. Mills wrote:
todd,

A careful read of the specification should give you comfort that the parsing rules do distinguish between an extension field and a MAC. In particular, the rules permit one or more extension fields without a MAC. The only requirement is that a MAC, if present, must be the last field.
Yes David - of course they do. I was talking about the idea of designing the protocol based on specific policies it delivered something totally to the group at this point but something that needs to happen.

Todd

Dave

todd glassey wrote:
On 7/13/2011 11:22 AM, Greg Dowd wrote:

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? 

You only need this if there is a new set of policies that are to be supported. If so what are the policies to be.

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

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: David L. Mills [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
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:

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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

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.

 


    
 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

 


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg


-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings. 
  

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.

--------------060704050601090506020600-- --===============1160525921235639760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1160525921235639760==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jul 15 10:28:59 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D9321F8B99 for ; Fri, 15 Jul 2011 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2Wxlnd21wMS for ; Fri, 15 Jul 2011 10:28:55 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 510C021F8B97 for ; Fri, 15 Jul 2011 10:28:51 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 143E586D768 for ; Fri, 15 Jul 2011 17:28:48 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 6A16886D4F0 for ; Fri, 15 Jul 2011 17:00:34 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QhlkS-000Omq-7c for ntpwg@lists.ntp.org; Fri, 15 Jul 2011 17:00:34 +0000 Received: from [192.168.1.3] (pool-74-109-5-222.phlapa.fios.verizon.net [74.109.5.222]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id A366FE6; Fri, 15 Jul 2011 13:00:18 -0400 (EDT) Message-ID: <4E207223.9080207@udel.edu> Date: Fri, 15 Jul 2011 17:00:19 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Dowd References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE5335@SJC-MBX-01.symmetricom.com> In-Reply-To: <26FBD265CD8D234EAF41115A180F92BB38AE5335@SJC-MBX-01.symmetricom.com> X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ntpwg@lists.ntp.org" Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5027934945650982030==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============5027934945650982030== Content-Type: multipart/alternative; boundary="------------080803000609030103010709" This is a multi-part message in MIME format. --------------080803000609030103010709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Greg, The document from whch the spec was derifed is now six years old, but that is not the point. The parser can now deal with the absence of a MAC, as well as hash algorithms of both 16 and 20 octets. Dave: > When you say specification, do you mean something other than the > RFC5905 document? Here is the RFC language. > > > > 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. > > > > > > Greg Dowd > > gdowd at symmetricom dot com (antispam format) > > Symmetricom, Inc. > > www.symmetricom.com > > "Everything should be made as simple as possible, but no simpler" > Albert Einstein > > From: ntpwg-bounces+gdowd=symmetricom.com@lists.ntp.org > [mailto:ntpwg-bounces+gdowd=symmetricom.com@lists.ntp.org] On Behalf > Of David L. Mills > Sent: Wednesday, July 13, 2011 9:32 PM > To: todd glassey > Cc: ntpwg@lists.ntp.org > Subject: Re: [ntpwg] [TICTOC] New draft: > draft-mizrahi-tictoc-checksum-trailer-00 > > > > todd, > > A careful read of the specification should give you comfort that the > parsing rules do distinguish between an extension field and a MAC. In > particular, the rules permit one or more extension fields without a > MAC. The only requirement is that a MAC, if present, must be the last > field. > > Dave > > todd glassey wrote: > > On 7/13/2011 11:22 AM, Greg Dowd wrote: > > 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? > > You only need this if there is a new set of policies that are to be > supported. If so what are the policies to be. > > > 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 > > "Everything should be made as simple as possible, but no simpler" > Albert Einstein > > From: David L. Mills [mailto:mills@udel.edu] > Sent: Wednesday, July 13, 2011 10:54 AM > To: Greg Dowd > Cc: Tal Mizrahi; tictoc@ietf.org ; > ntpwg@lists.ntp.org > 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: > > > 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: tictoc-bounces@ietf.org > [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi > Sent: Monday, July 04, 2011 5:01 AM > To: tictoc@ietf.org ; ntpwg@lists.ntp.org > > Subject: [TICTOC] [ntpwg] New draft: > draft-mizrahi-tictoc-checksum-trailer-00 > > > > 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. > > > >------------------------------------------------------------------------ > > > > > > > > > > > > >_______________________________________________ > >ntpwg mailing list > >ntpwg@lists.ntp.org > >http://lists.ntp.org/listinfo/ntpwg > > > > > >_______________________________________________ > >ntpwg mailing list > >ntpwg@lists.ntp.org > >http://lists.ntp.org/listinfo/ntpwg > > > > >-- > >Todd S. Glassey > >This is from my personal email account and any materials from this account come with personal disclaimers. > > > >Further I OPT OUT of any and all commercial emailings. > > > > > >------------------------------------------------------------------------ > > > > > > >_______________________________________________ > >ntpwg mailing list > >ntpwg@lists.ntp.org > >http://lists.ntp.org/listinfo/ntpwg > > > --------------080803000609030103010709 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Greg,

The document from whch the spec was derifed is now six years old, but that is not the point. The parser can now deal with the absence of a MAC, as well as hash algorithms of both 16 and 20 octets.

Dave:

When you say specification, do you mean something other than the RFC5905 document?  Here is the RFC language.

 

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.

 

 

Greg Dowd

gdowd at symmetricom dot com (antispam format)

Symmetricom, Inc.

www.symmetricom.com

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: ntpwg-bounces+gdowd=symmetricom.com@lists.ntp.org [mailto:ntpwg-bounces+gdowd=symmetricom.com@lists.ntp.org] On Behalf Of David L. Mills
Sent: Wednesday, July 13, 2011 9:32 PM
To: todd glassey
Cc: ntpwg@lists.ntp.org
Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

todd,

A careful read of the specification should give you comfort that the parsing rules do distinguish between an extension field and a MAC. In particular, the rules permit one or more extension fields without a MAC. The only requirement is that a MAC, if present, must be the last field.

Dave

todd glassey wrote:

On 7/13/2011 11:22 AM, Greg Dowd wrote:

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? 

You only need this if there is a new set of policies that are to be supported. If so what are the policies to be.


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

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: David L. Mills [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
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:


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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

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.

 


  
 
 
    
 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

 

 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg




-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 
 
Further I OPT OUT of any and all commercial emailings. 
  
 


  
 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

 


--------------080803000609030103010709-- --===============5027934945650982030== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============5027934945650982030==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jul 15 11:29:04 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164A721F8B8A for ; Fri, 15 Jul 2011 11:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.559 X-Spam-Level: X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgF3l2lXFDVK for ; Fri, 15 Jul 2011 11:29:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 818FB21F8B86 for ; Fri, 15 Jul 2011 11:28:59 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 898E586D784 for ; Fri, 15 Jul 2011 18:28:58 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id F274B86D4F0 for ; Fri, 15 Jul 2011 18:02:53 +0000 (UTC) Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qhmik-0005jM-Ju for ntpwg@lists.ntp.org; Fri, 15 Jul 2011 18:02:53 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fMm4v5LwcybesUtqGuDauMRqB/htRhAsGh/GnE2mpk9Q34GFVpiMpr0lp72BP1Fx; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qhmie-0006Ct-6T; Fri, 15 Jul 2011 14:02:32 -0400 Message-ID: <4E2080D7.8000701@earthlink.net> Date: Fri, 15 Jul 2011 11:03:03 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "David L. Mills" References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> In-Reply-To: <4E1E714F.60104@udel.edu> X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79ec413bfbd18eb8b888888d49cfc00cfb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 X-SA-Exim-Connect-IP: 209.86.89.62 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: tglassey@earthlink.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3963897672918119651==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============3963897672918119651== Content-Type: multipart/alternative; boundary="------------040006010205020101000104" This is a multi-part message in MIME format. --------------040006010205020101000104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/13/2011 9:32 PM, David L. Mills wrote: > todd, > > A careful read of the specification should give you comfort that the > parsing rules do distinguish between an extension field and a MAC. yes they do... > In particular, the rules permit one or more extension fields without a > MAC. The only requirement is that a MAC, if present, must be the last > field. yes, and that's fine but there are policy control models which may want more. The real issues is what specific functional policies NTP is setup to implement. This is something that you and I have argued about since we split on the first AutoKEY draft way back when. I look at NTP as a source of evidence -that's what I am after - documenting the evidence models possible with NTP for compliance practices. Todd > Dave > > todd glassey wrote: >> On 7/13/2011 11:22 AM, Greg Dowd wrote: >>> >>> 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? >>> >> You only need this if there is a new set of policies that are to be >> supported. If so what are the policies to be. >> >>> 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 >>> >>> "Everything should be made as simple as possible, but no simpler" >>> Albert Einstein >>> >>> *From:*David L. Mills [mailto:mills@udel.edu] >>> *Sent:* Wednesday, July 13, 2011 10:54 AM >>> *To:* Greg Dowd >>> *Cc:* Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org >>> *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: >>> >>> 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:*tictoc-bounces@ietf.org >>> [mailto:tictoc-bounces@ietf.org] *On Behalf Of *Tal Mizrahi >>> *Sent:* Monday, July 04, 2011 5:01 AM >>> *To:* tictoc@ietf.org ; ntpwg@lists.ntp.org >>> >>> *Subject:* [TICTOC] [ntpwg] New draft: >>> draft-mizrahi-tictoc-checksum-trailer-00 >>> >>> 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. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> _______________________________________________ >>> ntpwg mailing list >>> ntpwg@lists.ntp.org >>> http://lists.ntp.org/listinfo/ntpwg >>> >>> >>> _______________________________________________ >>> ntpwg mailing list >>> ntpwg@lists.ntp.org >>> http://lists.ntp.org/listinfo/ntpwg >> >> >> -- >> Todd S. Glassey >> This is from my personal email account and any materials from this account come with personal disclaimers. >> >> Further I OPT OUT of any and all commercial emailings. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> ntpwg mailing list >> ntpwg@lists.ntp.org >> http://lists.ntp.org/listinfo/ntpwg > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. --------------040006010205020101000104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/13/2011 9:32 PM, David L. Mills wrote:
todd,

A careful read of the specification should give you comfort that the parsing rules do distinguish between an extension field and a MAC.
yes they do...
In particular, the rules permit one or more extension fields without a MAC. The only requirement is that a MAC, if present, must be the last field.
yes, and that's fine but there are policy control models which may want more. The real issues is what specific functional policies NTP is setup to implement. This is something that you and I have argued about since we split on the first AutoKEY draft way back when.

I look at NTP as a source of evidence -that's what I am after - documenting the evidence models possible with NTP for compliance practices.

Todd

Dave

todd glassey wrote:
On 7/13/2011 11:22 AM, Greg Dowd wrote:

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? 

You only need this if there is a new set of policies that are to be supported. If so what are the policies to be.

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

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: David L. Mills [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
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:

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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

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.

 


    
 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

 


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg


-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings. 
  

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.
--------------040006010205020101000104-- --===============3963897672918119651== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============3963897672918119651==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jul 15 11:30:23 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAA921F8BA4 for ; Fri, 15 Jul 2011 11:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh7i2z5BJpdf for ; Fri, 15 Jul 2011 11:30:20 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7F21F8BA2 for ; Fri, 15 Jul 2011 11:30:20 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A89FC86DA6C for ; Fri, 15 Jul 2011 18:30:19 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 8359E86D4F0 for ; Fri, 15 Jul 2011 18:06:41 +0000 (UTC) Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QhmmR-0005k9-1N for ntpwg@lists.ntp.org; Fri, 15 Jul 2011 18:06:41 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BkV9FvvxQoHkqx+LSxySsMWPvkc6LrVKarEmNbjVKlmXNp5C7vPCOL/lwc1d9use; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QhmmL-0001wJ-AP for ntpwg@lists.ntp.org; Fri, 15 Jul 2011 14:06:21 -0400 Message-ID: <4E2081BC.3030602@earthlink.net> Date: Fri, 15 Jul 2011 11:06:52 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ntpwg@lists.ntp.org References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> <4E1EF2DB.80802@earthlink.net> In-Reply-To: <4E1EF2DB.80802@earthlink.net> X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a289b37949f7a90c8d6f02c7b99e30ff350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 X-SA-Exim-Connect-IP: 209.86.89.67 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: tglassey@earthlink.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0286567569602471281==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============0286567569602471281== Content-Type: multipart/alternative; boundary="------------000607080400060008010104" This is a multi-part message in MIME format. --------------000607080400060008010104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/14/2011 6:44 AM, todd glassey wrote: > On 7/13/2011 9:32 PM, David L. Mills wrote: >> todd, >> >> A careful read of the specification should give you comfort that the >> parsing rules do distinguish between an extension field and a MAC. In >> particular, the rules permit one or more extension fields without a >> MAC. The only requirement is that a MAC, if present, must be the last >> field. > Yes David - of course they do. I was talking about the idea of > designing the protocol based on specific policies it delivered > something totally to the group at this point but something that needs > to happen. > > Todd > > What I am suggesting Dave is that its time to do that formal review on what NTP is and what proof of operations it delivers formally, and in that process documenting that as a WG we understand what policies NTP can and cannot be use to deploy. You of course know them all by heart as the father of the protocol but 99.999% of the audit world doesn't. Worse 99.999% of the Admins also don't either but that is a different issue IMHO. Todd >> >> Dave >> >> todd glassey wrote: >>> On 7/13/2011 11:22 AM, Greg Dowd wrote: >>>> >>>> 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? >>>> >>> You only need this if there is a new set of policies that are to be >>> supported. If so what are the policies to be. >>> >>>> 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 >>>> >>>> "Everything should be made as simple as possible, but no simpler" >>>> Albert Einstein >>>> >>>> *From:*David L. Mills [mailto:mills@udel.edu] >>>> *Sent:* Wednesday, July 13, 2011 10:54 AM >>>> *To:* Greg Dowd >>>> *Cc:* Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org >>>> *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: >>>> >>>> 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:*tictoc-bounces@ietf.org >>>> [mailto:tictoc-bounces@ietf.org] *On Behalf Of *Tal Mizrahi >>>> *Sent:* Monday, July 04, 2011 5:01 AM >>>> *To:* tictoc@ietf.org ; ntpwg@lists.ntp.org >>>> >>>> *Subject:* [TICTOC] [ntpwg] New draft: >>>> draft-mizrahi-tictoc-checksum-trailer-00 >>>> >>>> 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. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> ntpwg mailing list >>>> ntpwg@lists.ntp.org >>>> http://lists.ntp.org/listinfo/ntpwg >>>> >>>> >>>> _______________________________________________ >>>> ntpwg mailing list >>>> ntpwg@lists.ntp.org >>>> http://lists.ntp.org/listinfo/ntpwg >>> >>> >>> -- >>> Todd S. Glassey >>> This is from my personal email account and any materials from this account come with personal disclaimers. >>> >>> Further I OPT OUT of any and all commercial emailings. >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> ntpwg mailing list >>> ntpwg@lists.ntp.org >>> http://lists.ntp.org/listinfo/ntpwg >> > > > -- > Todd S. Glassey > This is from my personal email account and any materials from this account come with personal disclaimers. > > Further I OPT OUT of any and all commercial emailings. > > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. --------------000607080400060008010104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/14/2011 6:44 AM, todd glassey wrote:
On 7/13/2011 9:32 PM, David L. Mills wrote:
todd,

A careful read of the specification should give you comfort that the parsing rules do distinguish between an extension field and a MAC. In particular, the rules permit one or more extension fields without a MAC. The only requirement is that a MAC, if present, must be the last field.
Yes David - of course they do. I was talking about the idea of designing the protocol based on specific policies it delivered something totally to the group at this point but something that needs to happen.

Todd


What I am suggesting Dave is that its time to do that formal review on what NTP is and what proof of operations it delivers formally, and in that process documenting that as a WG we understand what policies NTP can and cannot be use to deploy.

You of course know them all by heart as the father of the protocol but 99.999% of the audit world doesn't. Worse 99.999% of the Admins also don't either but that is a different issue IMHO.

Todd


Dave

todd glassey wrote:
On 7/13/2011 11:22 AM, Greg Dowd wrote:

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? 

You only need this if there is a new set of policies that are to be supported. If so what are the policies to be.

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

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: David L. Mills [mailto:mills@udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc@ietf.org; ntpwg@lists.ntp.org
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:

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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc@ietf.org; ntpwg@lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

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.

 


    
 
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

 


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg


-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings. 
  

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings. 


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg


-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.
--------------000607080400060008010104-- --===============0286567569602471281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============0286567569602471281==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jul 15 12:48:04 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A7721F8C68 for ; Fri, 15 Jul 2011 12:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07r1Kvt99z8S for ; Fri, 15 Jul 2011 12:48:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2C21F8C64 for ; Fri, 15 Jul 2011 12:48:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 55A6B86D78E for ; Fri, 15 Jul 2011 19:47:59 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 0BE2D86D760 for ; Fri, 15 Jul 2011 19:27:58 +0000 (UTC) Received: from [198.22.153.9] (helo=[10.60.111.32]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qho37-000Fye-BH; Fri, 15 Jul 2011 19:27:55 +0000 Message-ID: <4E2094A9.6040702@ntp.org> Date: Fri, 15 Jul 2011 15:27:37 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: todd glassey References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> <4E2080D7.8000701@earthlink.net> In-Reply-To: <4E2080D7.8000701@earthlink.net> X-Enigmail-Version: 1.1.1 X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: tglassey@earthlink.net, mills@udel.edu, ntpwg@lists.ntp.org 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 Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On 7/15/2011 2:03 PM, todd glassey wrote: > On 7/13/2011 9:32 PM, David L. Mills wrote: >> todd, >> >> A careful read of the specification should give you comfort that the >> parsing rules do distinguish between an extension field and a MAC. > yes they do... >> In particular, the rules permit one or more extension fields without a >> MAC. The only requirement is that a MAC, if present, must be the last >> field. > yes, and that's fine but there are policy control models which may want > more. The real issues is what specific functional policies NTP is setup > to implement. This is something that you and I have argued about since > we split on the first AutoKEY draft way back when. Protocol is not the place for policy. That's an admin/management role. You cannot dictate policy anywhere and doesn't belong in the protocol. You can design your own policy distribution protocol if you want that that has nothing to do with NTP. > I look at NTP as a source of evidence -that's what I am after - > documenting the evidence models possible with NTP for compliance practices. NTP cannot be used as a source of evidence, there are just too many ways of spoofing a timestamp without evidence of tampering. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sat Jul 16 13:32:11 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4021E21F88A0 for ; Sat, 16 Jul 2011 13:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8syFBOJBJq4 for ; Sat, 16 Jul 2011 13:32:10 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 4009521F888A for ; Sat, 16 Jul 2011 13:32:09 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id DBFB286D772 for ; Sat, 16 Jul 2011 20:32:08 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 7E1CC86D41E for ; Sat, 16 Jul 2011 20:12:15 +0000 (UTC) Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QiBDY-0002Jb-70; Sat, 16 Jul 2011 20:12:15 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=F21orkoUvPD3/OfZIHMjrtpW8WDk5v8lmG/t9U2AONjAiilqzOYBWvzD5ptlX7ro; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QiBDR-0001p9-Vw; Sat, 16 Jul 2011 16:11:58 -0400 Message-ID: <4E21F0AC.4060208@earthlink.net> Date: Sat, 16 Jul 2011 13:12:28 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Danny Mayer References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> <4E2080D7.8000701@earthlink.net> <4E2094A9.6040702@ntp.org> In-Reply-To: <4E2094A9.6040702@ntp.org> X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec795c951c8c71becfa1a6fc0bc33469a9d6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-SA-Exim-Connect-IP: 209.86.89.63 X-SA-Exim-Rcpt-To: mayer@ntp.org, ntpwg@lists.ntp.org X-SA-Exim-Mail-From: tglassey@earthlink.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On 7/15/2011 12:27 PM, Danny Mayer wrote: > On 7/15/2011 2:03 PM, todd glassey wrote: >> On 7/13/2011 9:32 PM, David L. Mills wrote: >>> todd, >>> >>> A careful read of the specification should give you comfort that the >>> parsing rules do distinguish between an extension field and a MAC. >> yes they do... >>> In particular, the rules permit one or more extension fields without a >>> MAC. The only requirement is that a MAC, if present, must be the last >>> field. >> yes, and that's fine but there are policy control models which may want >> more. The real issues is what specific functional policies NTP is setup >> to implement. This is something that you and I have argued about since >> we split on the first AutoKEY draft way back when. > Protocol is not the place for policy. That's an admin/management role. No Danny - POLICY is what the PROTOCOL IMPLEMENTS. There is no way around this no matter how you try and cover it up. The policy is what the protocol is set up to implement. The structure of the controls that are in place are what provide the policy implementations. > You cannot dictate policy anywhere and doesn't belong in the protocol. Yes you can... the Protocol must implement USE MODELS which are defined by the policy. > You can design your own policy distribution protocol if you want that > that has nothing to do with NTP. Right... >> I look at NTP as a source of evidence -that's what I am after - >> documenting the evidence models possible with NTP for compliance practices. > NTP cannot be used as a source of evidence, there are just too many ways > of spoofing a timestamp without evidence of tampering. > > Danny > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sat Jul 16 20:02:43 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED5221F8763 for ; Sat, 16 Jul 2011 20:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e290DOtJwG-U for ; Sat, 16 Jul 2011 20:02:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id E967C21F875E for ; Sat, 16 Jul 2011 20:02:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BCEEE86D76D for ; Sun, 17 Jul 2011 03:02:39 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id A547186D75D for ; Sun, 17 Jul 2011 02:30:54 +0000 (UTC) Received: from mx04.gis.net ([208.218.130.12]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QiH7z-000KjQ-Mc for ntpwg@lists.ntp.org; Sun, 17 Jul 2011 02:30:54 +0000 Received: from [10.10.10.102] ([108.1.141.26]) by mx04.gis.net; Sat, 16 Jul 2011 22:27:40 -0400 Message-ID: <4E22494D.9030503@ntp.org> Date: Sat, 16 Jul 2011 22:30:37 -0400 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: todd glassey References: <74470498B659FA4687F0B0018C19A89C01223E573C5A@IL-MB01.marvell.com> <26FBD265CD8D234EAF41115A180F92BB38AE2BBC@SJC-MBX-01.symmetricom.com> <4E1DDBB6.3020302@udel.edu> <26FBD265CD8D234EAF41115A180F92BB38AE4838@SJC-MBX-01.symmetricom.com> <4E1DED40.7080007@earthlink.net> <4E1E714F.60104@udel.edu> <4E2080D7.8000701@earthlink.net> <4E2094A9.6040702@ntp.org> <4E21F0AC.4060208@earthlink.net> In-Reply-To: <4E21F0AC.4060208@earthlink.net> X-Enigmail-Version: 1.1.1 X-SA-Exim-Connect-IP: 208.218.130.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org 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 Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mayer@ntp.org List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On 7/16/2011 4:12 PM, todd glassey wrote: > On 7/15/2011 12:27 PM, Danny Mayer wrote: >> On 7/15/2011 2:03 PM, todd glassey wrote: >>> yes, and that's fine but there are policy control models which may want >>> more. The real issues is what specific functional policies NTP is setup >>> to implement. This is something that you and I have argued about since >>> we split on the first AutoKEY draft way back when. >> Protocol is not the place for policy. That's an admin/management role. > No Danny - POLICY is what the PROTOCOL IMPLEMENTS. There is no way > around this no matter how you try and cover it up. The policy is what > the protocol is set up to implement. The structure of the controls that > are in place are what provide the policy implementations. That means that you have no understanding of what the NTP protocol implements. >> You cannot dictate policy anywhere and doesn't belong in the protocol. > Yes you can... the Protocol must implement USE MODELS which are defined > by the policy. No, the protocol only defines how data is transferred but there is no requirement about how it gets used at the receiving end. You cannot dictate that. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sun Jul 17 13:32:41 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3D221F86D6 for ; Sun, 17 Jul 2011 13:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVG8424P+NoN for ; Sun, 17 Jul 2011 13:32:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8725D21F85FE for ; Sun, 17 Jul 2011 13:32:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 01C0486D7D9 for ; Sun, 17 Jul 2011 20:32:38 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from stenn.ntp.org (stenn.ntp.org [IPv6:2001:4f8:fff7:1::30]) by lists.ntp.org (Postfix) with ESMTP id 61DA886D75F; Sun, 17 Jul 2011 20:04:06 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QiXZO-0000KF-7B; Sun, 17 Jul 2011 13:04:06 -0700 To: Dave Hart In-reply-to: References: Comments: In-reply-to Dave Hart message dated "Sun, 17 Jul 2011 06:35:06 -0000." X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 22) Mime-Version: 1.0 (generated by tm-edit 1.8) Date: Sun, 17 Jul 2011 13:04:06 -0700 From: Harlan Stenn Message-Id: Cc: ntpwg@lists.ntp.org, questions@lists.ntp.org, hackers@lists.ntp.org Subject: Re: [ntpwg] [ntp:hackers] disabling or removing mode 7 (ntpdc) support from ntpd X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mode 6 and mode 7 *should* have been included in the NTPv4 spec. There is effort underway to get them back. I have no problem with mode 7 - it is a vendor-specific way to interact with an NTP daemon. Granted, I haven't heard of anybody else ever using it. Mode 7 has traditionaly been a binary protocol, while Mode 6 has been an ASCII protocol. There is no *requirement* that mode 7 use a binary protocol. Mode 6 stuff SHOULD be documented and specified by the RFC. It MAY be OK to carve out some space in this specification for vendor-specific usage. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sun Jul 17 16:47:57 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EE021F89B8 for ; Sun, 17 Jul 2011 16:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDM6p+J6OPMD for ; Sun, 17 Jul 2011 16:47:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEE721F898F for ; Sun, 17 Jul 2011 16:47:56 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B77FE86D78D for ; Sun, 17 Jul 2011 23:47:55 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id B685E86D75F for ; Sun, 17 Jul 2011 23:19:28 +0000 (UTC) Received: from mail-ww0-f51.google.com ([74.125.82.51]) by mail1.ntp.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QiacI-0005ux-0V for ntpwg@lists.ntp.org; Sun, 17 Jul 2011 23:19:28 +0000 Received: by wwj26 with SMTP id 26so1918891wwj.32 for ; Sun, 17 Jul 2011 16:19:11 -0700 (PDT) Received: by 10.227.133.147 with SMTP id f19mr225637wbt.27.1310944751097; Sun, 17 Jul 2011 16:19:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.41.200 with HTTP; Sun, 17 Jul 2011 16:18:50 -0700 (PDT) In-Reply-To: References: From: Dave Hart Date: Sun, 17 Jul 2011 23:18:50 +0000 Message-ID: To: ntpwg@lists.ntp.org X-SA-Exim-Connect-IP: 74.125.82.51 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hart@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Fwd: disabling or removing mode 7 (ntpdc) support from ntpd X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org SGFybGFuIGFza2VkIG1lIHRvIHBvc3QgdGhpcyBtZXNzYWdlIHRvIG50cHdnQCBhcyB3ZWxsLgoK Q2hlZXJzLApEYXZlIEhhcnQKCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0t LQpGcm9tOiBEYXZlIEhhcnQgPGhhcnRAbnRwLm9yZz4KRGF0ZTogU3VuLCBKdWwgMTcsIDIwMTEg YXQgMDY6MzUKU3ViamVjdDogZGlzYWJsaW5nIG9yIHJlbW92aW5nIG1vZGUgNyAobnRwZGMpIHN1 cHBvcnQgZnJvbSBudHBkClRvOiBxdWVzdGlvbnNAbGlzdHMubnRwLm9yZywgaGFja2Vyc0BsaXN0 cy5udHAub3JnCgoKSSB3b3VsZCBsaWtlIHRvIHJlbW92ZSBzdXBwb3J0IGZvciBudHBkYydzIG1v ZGUgNyBtYW5hZ2VtZW50IGZyb20gbnRwZAppbiBudHAtZGV2IHNvb24uCgpXaGF0IGlzIHdyb25n IHdpdGggbnRwZGMncyBtb2RlIDcgb24td2lyZSBwcm90b2NvbD8gwqBJdCdzIGNvbXBsZXgsCmZy YWdpbGUsIGFuZCByZXF1aXJlcyBhIGxhcmdlIGFtb3VudCBvZiB0ZWRpb3VzLCBlcnJvci1wcm9u ZQptYXJzaGFsbGluZyBhbmQgdW5tYXJzaGFsbGluZyBjb2RlIGluIGJvdGggbnRwZCBhbmQgbnRw ZGMuIMKgTW9yZW92ZXIsCndpdGggdGhlIHJlbGVhc2UgaW4gdGhlIG5leHQgZGF5IG9yIHNvIG9m IDQuMi43cDE5MSwgSSBjbGFpbSBpdCBpcwp3aG9sbHkgcmVkdW5kYW50IHdpdGggbnRwcS4gwqBU aGF0IGlzLCBJIGJlbGlldmUgYXMgb2YgbnRwZCA0LjIuN3AxOTEsCmV2ZXJ5dGhpbmcgdGhhdCBj YW4gYmUgZG9uZSB2aWEgbnRwZGMgYW5kIGl0cyBtb2RlIDcgbWFuYWdlbWVudAp0cmFmZmljIGNh biBub3cgYmUgYWNjb21wbGlzaGVkIHdpdGggdGhlIHNpbXBsZXIgYW5kIHNhZmVyIG1vZGUgNgpy ZXF1ZXN0cyBpc3N1ZWQgYnkgbnRwcS4gwqBQbGVhc2UgZmlsZSBidWdzIG9yIG90aGVyd2lzZSBh bGVydCB1cyBpZgp5b3UgZmluZCBvdGhlcndpc2UuCgooQXMgYW4gYXNpZGUsIGluIDQuMi42IGFu ZCBlYXJsaWVyLCBtb2RlIDcgbWFuYWdlbWVudCBwYWNrZXRzIGFyZQppc3N1ZWQgYnkgbnRwZCdz IGludHJlcyBETlMgY29kZSB0byBzcGluIHVwIHNlcnZlciBhc3NvY2lhdGlvbnMgYWZ0ZXIKcmVz b2x2aW5nIGFuIElQIGFkZHJlc3MsIHZpYSAxMjcuMC4wLjE6MTIzLiDCoFRoYXQgbWVhbnMgaW4g NC4yLjYsCnNpbXBseSByaXBwaW5nIG91dCBzdXBwb3J0IGZvciBtb2RlIDcgd291bGQgYWxzbyBy aXAgb3V0IHN1cHBvcnQgZm9yCnNwZWNpZnlpbmcgc2VydmVycyBieSBuYW1lIHJhdGhlciB0aGFu IG51bWVyaWMgSVAgYWRkcmVzcy4gwqBTaW5jZQplYXJseSBpbiB0aGUgNC4yLjcgY3ljbGUsIHRo ZSBuZXcgaW50cmVzIGNvZGUgaW4gbnRwZCBkb2VzIG5vdCByZWx5IG9uCm1vZGUgNywgaW5jaWRl bnRhbGx5IGFsc28gZW5hYmxpbmcgSVB2Ni1vbmx5IG9wZXJhdGlvbiBpbiB0aGVvcnkuKQoKV2h5 IGlzIG50cHEncyBtb2RlIDYgcHJvdG9jb2wgcHJlZmVyYWJsZT8gwqBJdCBpcyBsYXJnZWx5IHRl eHQtYmFzZWQsCndoZXJlIG1vZGUgNyB1c2VzIGJpbmFyeSByZXF1ZXN0cyBhbmQgcmVzcG9uc2Vz IGVhY2ggcmVxdWlyaW5nCmxlbmd0aHksIGVycm9yLXByb25lIG1hcnNoYWxsaW5nIGFuZCBieXRl LXN3YXBwaW5nIGNvZGUgaW4gYm90aCBudHBkCmFuZCBudHBkYy4gwqBUeXBpY2FsbHkgbmV3IGNh cGFiaWxpdHkgY2FuIGJlIGFkZGVkIHRvIG50cHEgd2l0aG91dCBhbnkKcHJvdG9jb2wgd29yaywg d2hpbGUgZWFjaCBhZGRpdGlvbiBvciBjaGFuZ2UgdG8gbnRwZGMgdHlwaWNhbGx5CnJlcXVpcmVz IG5ldyBiaW5hcnkgcmVxdWVzdCBhbmQgcmVzcG9uc2UgcGFja2V0IGRlZmluaXRpb25zLiDCoEFs c28sCnRoYW5rcyB0byB0aGUgcHJlZmVyZW5jZSBmb3IgbnRwcSwgbnRwZGMgaGFzIG5vdCBiZWVu IGFzIHdlbGwKbWFpbnRhaW5lZCwgdGhvdWdoIGl0J3MgZmFyZWQgYmV0dGVyIHRoYW4gbnRwZGF0 ZS4KClRvIHNlZSBmb3IgeW91cnNlbGYgdGhlIGluZmxleGliaWxpdHkgYW5kIHJlc3VsdGFudCBj b2RlIGJsb2F0IG9mIHRoZQptb2RlIDcgcHJvdG9jb2wsIHRha2UgYSBsb29rIGF0IGVpdGhlciBu dHBkYy9udHBkY19vcHMuYyBvcgpudHBkL250cF9yZXF1ZXN0LmMgZm9jdXNpbmcgb24gaG93IHN1 cHBvcnQgd2FzIGFkZGVkIGZvciBJUHY2J3MKMTI4LWJpdCBhZGRyZXNzZXMgb24gdG9wIG9mIHRo ZSBleGlzdGluZyAzMi1iaXQgSVB2NCBwcm92aXNpb25zLgoKVW5saWtlIHRoZSBzaXR1YXRpb24g d2l0aCBudHBkYXRlLCBJIGRvIG5vdCBwcm9wb3NlIHJlbW92aW5nIHRoZSBudHBkYwpjb2RlIGFu eXRpbWUgc29vbi4gwqBJdCB3aWxsIHJldGFpbiB1dGlsaXR5IGZvciBtYW5hZ2luZyBvbGRlciBu dHBkCmluc3RhbmNlcyBmb3Igc29tZSB0aW1lIHRvIGNvbWUsIGFzIHdpdGggNC4yLjYgYW5kIGVh cmxpZXIsIHNvbWUKbWFuYWdlbWVudCBjYXBhYmlsaXRpZXMgd2VyZSBvbmx5IGF2YWlsYWJsZSB2 aWEgbnRwZGMgKGZvciBleGFtcGxlLApxdWVyeWluZyBuZXR3b3JrIGludGVyZmFjZXMgdXNlZCBi eSBudHBkLCBvciBmZXRjaGluZyB0aGUgcmVjZW50CmNsaWVudCBhZGRyZXNzIGxpc3QpLiDCoE9u IHRoZSBvdGhlciBoYW5kLCBJJ20gc3Ryb25nbHkgaW4gZmF2b3Igb2YKbG9zaW5nIHRoZSBtb2Rl IDcgc3VwcG9ydCBjb2RlIGluIG50cGQvbnRwX3JlcXVlc3QuYywgd2hpY2ggaXMKdm9sdW1pbm91 cywgZXJyb3ItcHJvbmUsIGFuZCByZWR1bmRhbnQuCgpPbmUgd2F5IGZvcndhcmQgd291bGQgYmUg dG8gc2ltcGx5IHJpcCBvdXQgbnRwX3JlcXVlc3QuYyBhbmQgY2FsbCBpdApkb25lLiDCoFNvbWUg bWlnaHQgYmUgaGFwcGllciB3aXRoIGEgdHJhbnNpdGlvbiBwZXJpb2Qgd2hlcmUgc3VwcG9ydApm b3IgbW9kZSA3IGNvdWxkIGJlIGV4cGxpY2l0bHkgY29uZmlndXJlZCwgc3VjaCBhcyB3aXRoIGEg aHlwb3RoZXRpY2FsCiJlbmFibGUgbnRwZGMiIGluIG50cC5jb25mLiDCoEkgd291bGQgcHJlZmVy IHRoZSBmb3JtZXIsIGJ1dCBhcyBhIG50cGQKbWFpbnRhaW5lciBteSBwZXJzcGVjdGl2ZSBpcyBi aWFzZWQuIMKgV2hhdCBkbyB5b3UgdGhpbms/CgpDaGVlcnMsCkRhdmUgSGFydApfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpudHB3ZyBtYWlsaW5nIGxpc3QK bnRwd2dAbGlzdHMubnRwLm9yZwpodHRwOi8vbGlzdHMubnRwLm9yZy9saXN0aW5mby9udHB3Zw== From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 18 09:35:36 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D9521F8B89 for ; Mon, 18 Jul 2011 09:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.659 X-Spam-Level: X-Spam-Status: No, score=-5.659 tagged_above=-999 required=5 tests=[AWL=0.940, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8zu7QHy9Unw for ; Mon, 18 Jul 2011 09:35:32 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8354521F8B52 for ; Mon, 18 Jul 2011 09:35:31 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id DBDCE86D77D for ; Mon, 18 Jul 2011 16:35:29 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id CF00486D4F0 for ; Mon, 18 Jul 2011 16:06:35 +0000 (UTC) Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QiqKu-000Ipz-09 for ntpwg@lists.ntp.org; Mon, 18 Jul 2011 16:06:35 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sjGueSIkFYNYHiVHrI46uTlxakmUlr/uQJRi6O5nqZ64itsXP8nhiGRZJ3j8UZLs; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QiqKn-0002wS-HP for ntpwg@lists.ntp.org; Mon, 18 Jul 2011 12:06:17 -0400 Message-ID: <4E245A18.3010302@earthlink.net> Date: Mon, 18 Jul 2011 09:06:48 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ntpwg@lists.ntp.org References: In-Reply-To: X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec797495316cad6df1cbf1a1f668b79465e9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 X-SA-Exim-Connect-IP: 209.86.89.70 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: tglassey@earthlink.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Fwd: disabling or removing mode 7 (ntpdc) support from ntpd X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On 7/17/2011 4:18 PM, Dave Hart wrote: > Harlan asked me to post this message to ntpwg@ as well. > > Cheers, > Dave Hart > > ---------- Forwarded message ---------- > From: Dave Hart > Date: Sun, Jul 17, 2011 at 06:35 > Subject: disabling or removing mode 7 (ntpdc) support from ntpd > To: questions@lists.ntp.org, hackers@lists.ntp.org > > > I would like to remove support for ntpdc's mode 7 management from ntpd > in ntp-dev soon. No... It needs to stay for compatibility unless the parties who are shipping the code are planning on EOLing NTPDC > What is wrong with ntpdc's mode 7 on-wire protocol? It's complex, > fragile, and requires a large amount of tedious, error-prone > marshalling and unmarshalling code in both ntpd and ntpdc. This is because of a sloppy build world. > Moreover, > with the release in the next day or so of 4.2.7p191, I claim it is > wholly redundant with ntpq. Its not redundant but rather a binary interface. As you note there is a text interface with NTPQ but that is text base. > That is, I believe as of ntpd 4.2.7p191, > everything that can be done via ntpdc and its mode 7 management > traffic can now be accomplished with the simpler and safer mode 6 > requests issued by ntpq. Yes this is true - but so what? NTPDATE and SNTP exist pretty well together. > Please file bugs or otherwise alert us if > you find otherwise. > > (As an aside, in 4.2.6 and earlier, mode 7 management packets are > issued by ntpd's intres DNS code to spin up server associations after > resolving an IP address, via 127.0.0.1:123. That means in 4.2.6, > simply ripping out support for mode 7 would also rip out support for > specifying servers by name rather than numeric IP address. Since > early in the 4.2.7 cycle, the new intres code in ntpd does not rely on > mode 7, incidentally also enabling IPv6-only operation in theory.) > > Why is ntpq's mode 6 protocol preferable? It is largely text-based, > where mode 7 uses binary requests and responses each requiring > lengthy, error-prone marshalling and byte-swapping code in both ntpd > and ntpdc. I think that the binary format is useful however. > Typically new capability can be added to ntpq without any > protocol work, while each addition or change to ntpdc typically > requires new binary request and response packet definitions. Also, > thanks to the preference for ntpq, ntpdc has not been as well > maintained, though it's fared better than ntpdate. > > To see for yourself the inflexibility and resultant code bloat of the > mode 7 protocol, take a look at either ntpdc/ntpdc_ops.c or > ntpd/ntp_request.c focusing on how support was added for IPv6's > 128-bit addresses on top of the existing 32-bit IPv4 provisions. > > Unlike the situation with ntpdate, I do not propose removing the ntpdc > code anytime soon. It will retain utility for managing older ntpd > instances for some time to come, as with 4.2.6 and earlier, some > management capabilities were only available via ntpdc (for example, > querying network interfaces used by ntpd, or fetching the recent > client address list). On the other hand, I'm strongly in favor of > losing the mode 7 support code in ntpd/ntp_request.c, which is > voluminous, error-prone, and redundant. > > One way forward would be to simply rip out ntp_request.c and call it > done. Some might be happier with a transition period where support > for mode 7 could be explicitly configured, such as with a hypothetical > "enable ntpdc" in ntp.conf. I would prefer the former, but as a ntpd > maintainer my perspective is biased. What do you think? > > Cheers, > Dave Hart > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From Wany@lloydstsb.org Tue Jul 26 05:34:34 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahfae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahfae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA9921F8C3D for ; Tue, 26 Jul 2011 05:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.783 X-Spam-Level: **** X-Spam-Status: No, score=4.783 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, AWL=0.578, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, DNS_FROM_RFC_DSN=1.495, GB_I_LETTER=-2, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wN4I4xpLfVF for ; Tue, 26 Jul 2011 05:34:33 -0700 (PDT) Received: from post.tl.ru (mail.rclink.ru [193.194.153.13]) by ietfa.amsl.com (Postfix) with ESMTP id 54BCE21F8BFE for ; Tue, 26 Jul 2011 05:34:30 -0700 (PDT) Received: from user-ac6dc1597f (unknown [173.245.80.10]) (Authenticated sender: komrat@tl.ru) by post.tl.ru (Postfix) with ESMTP id 84F20417A7 for ; Tue, 26 Jul 2011 12:38:42 +0400 (MSD) From: "Wan Yonghong" Subject: Compliment of the day To: ietfarch-ntp-archives-ahfae6za@ietfa.amsl.com Content-Type: multipart/alternative; boundary="IwpXUZeNvaj03JhtIqr=_jBR81aBYkdWhJ0" MIME-Version: 1.0 Reply-To: wanyonghong101@gmail.com Date: Tue, 26 Jul 2011 16:38:42 +0800 Message-Id: <20110726083846.84F20417A7@post.tl.ru> This is a multi-part message in MIME format --IwpXUZeNvaj03JhtIqr=_jBR81aBYkdWhJ0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable - This mail is in HTML. Some elements may be ommited in plain text. - Compliment of the day, I am Mrs. Wan Yonghong, a staff of Lloyd s TSB Group Plc. here in Hong Kong attached with private Banking Services ; I have secured a business proposal for you. Should you be interested please reach me back, so i can provide you wi= th more details of my proposal. Your earliest response to this letter will be appreciated. Yours Sincerely, Wan Yonghong. %first Name& --IwpXUZeNvaj03JhtIqr=_jBR81aBYkdWhJ0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Compliment of the day,

I am Mrs. Wan Yonghong, a staff of= Lloyd s TSB Group Plc. here in Hong= Kong attached with private Banking Services; I have secured a business proposal for you.

= Should you be interested please reach me back, so i can provide you wi= th more details of my proposal.

Your earliest response to this = letter will be appreciated.

Yours Sincerely,
Wan Yonghong.
%first Name&
--IwpXUZeNvaj03JhtIqr=_jBR81aBYkdWhJ0-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jul 28 07:55:16 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A997821F8B97 for ; Thu, 28 Jul 2011 07:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCYQ5tvob8Lo for ; Thu, 28 Jul 2011 07:55:15 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id EFDF621F8C15 for ; Thu, 28 Jul 2011 07:55:06 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 9A24C86D787 for ; Thu, 28 Jul 2011 14:55:05 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 421E386D41E for ; Thu, 28 Jul 2011 14:53:25 +0000 (UTC) Received: from mail-vw0-f44.google.com ([209.85.212.44]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QmRxZ-000H9P-43 for ntpwg@lists.ntp.org; Thu, 28 Jul 2011 14:53:25 +0000 Received: by vws12 with SMTP id 12so2169817vws.3 for ; Thu, 28 Jul 2011 07:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=yx3PEkAms7oE6UxFhTMA24I3KskCFIHhq4TayxCMOLg=; b=wjk3aUx2UDV3S9gWup2kyr3l0kYepQmBWlfkxz6SF8LGjAh1GtLDLFZFO7l3gkoGYC KQ/U+F169kuNGeiKtPbbUxCWreRpBWkYqVq9XUA78Ar21Ybc7ihG7WZfPzZJk3J5zZk1 pDmJt8HxkPppAogC9RuNYtGZIep4Q4YbLT0qA= Received: by 10.52.23.10 with SMTP id i10mr118567vdf.317.1311864786596; Thu, 28 Jul 2011 07:53:06 -0700 (PDT) Received: from dhcp-26a8.meeting.ietf.org (dhcp-26a8.meeting.ietf.org [130.129.38.168]) by mx.google.com with ESMTPS id f8sm509989vdw.7.2011.07.28.07.53.05 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 07:53:05 -0700 (PDT) Message-ID: <4E3177D0.3050205@pobox.com> Date: Thu, 28 Jul 2011 10:53:04 -0400 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: NTP Working Group X-SA-Exim-Connect-IP: 209.85.212.44 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kodonog@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Fwd: reminder and remote participation information for today's meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: kodonog@pobox.com List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Folks, As previously discussed, there will be a face to face meeting of the tictoc wg here at IETF 81. Note that I am cross-posting this to the ntp wg as well as there is related discussions there. For remote participation, there is an audio stream to listen and a jabber channel for submitting comments/questions. The easiest way to directly access the information is: http://tools.ietf.org/agenda/81/ General information is available at: http://www.ietf.org/meeting/81/remote-participation.html IETF-81 TICTOC WG Agenda ======================== Thursday, 28 July 2011, 1520-1720 EDT (1940 - 2140 UTC / 1220 - 1420 PDT) 1. Administrivia and Agenda Bashing 2. ITU-T SG15/Q13 update 3. IPsec security for packet based synchronization draft-xu-tictoc-ipsec-security-for-synchronization-01 4. Time Synchronization Protocol Security Requirements 5. Precision Time Protocol Version 2 (PTPv2) Management Information Base draft-ietf-tictoc-ptp-mib-00 6. Transporting PTP messages (1588) over MPLS Networks draft-ietf-tictoc-1588overmpls-01 7. UDP Checksum Trailer in Timing Protocols draft-mizrahi-tictoc-checksum-trailer-00.txt 8. Network Time Mechanisms for Improving Computer Clock Accuracy draft-marlow-tictoc-computer-clock-accuracy-00 9. Additional NTP Discussion Topics 10. Wrap-up / Way Forward _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg