Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)
"Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com> Wed, 01 July 2015 14:55 UTC
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A891A8912 for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Wed, 1 Jul 2015 07:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCMnQoIIhBYb for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Wed, 1 Jul 2015 07:55:52 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5C1A8AF0 for <ntp-archives-ahFae6za@lists.ietf.org>; Wed, 1 Jul 2015 07:55:39 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7B1FB86DB53 for <ntp-archives-ahFae6za@lists.ietf.org>; Wed, 1 Jul 2015 14:55: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 E1CC986D643 for <ntpwg@lists.ntp.org>; Wed, 1 Jul 2015 14:55:33 +0000 (UTC)
Received: from [58.251.152.64] (helo=szxga01-in.huawei.com) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <anil.sn@huawei.com>) id 1ZAJQ6-000Aum-2L; Wed, 01 Jul 2015 14:55:33 +0000
Received: from 172.24.2.119 (EHLO nkgeml402-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQL16210; Wed, 01 Jul 2015 22:54:59 +0800 (CST)
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.155]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 1 Jul 2015 22:54:52 +0800
From: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>
To: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>, "mayer@ntp.org" <mayer@ntp.org>, Anil Kumar <anil.ietf@gmail.com>, Tal Mizrahi <talmi@marvell.com>, Karen O'Donoghue <odonoghue@isoc.org>, "ntpwg@lists.ntp.org" <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)
Thread-Index: AdCzNT97wwMopLF7SfaglIyzNlo4Z///w4MAgAAAdoCAAKL2gP//c3CA//4p2SA=
Date: Wed, 01 Jul 2015 14:54:52 +0000
Message-ID: <327562D94EA7BF428CD805F338C31EF06B5B0C7C@nkgeml512-mbx.china.huawei.com>
References: <a55c427404b444bf93d4f9bff62f513f@IL-EXCH01.marvell.com> <5592D18A.7030901@ntp.org> <CAC38=VGf0EmcvGAaJ6X-goq-H0jFNhiNMvx40c0H4mJaotvQCQ@mail.gmail.com> <55935AA1.6050108@ntp.org> <327562D94EA7BF428CD805F338C31EF06B5AEB6D@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <327562D94EA7BF428CD805F338C31EF06B5AEB6D@nkgeml512-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.212.150]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-SA-Exim-Connect-IP: 58.251.152.64
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org, mayer@ntp.org
X-SA-Exim-Mail-From: anil.sn@huawei.com
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Subject: Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <http://lists.ntp.org/pipermail/ntpwg/>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Sender: ntpwg <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
Backward compatibility analysis for M-BIT in Extension field types. IANA alloctes new Extension field value : 0x800a for More Bit and 0x000a without more bit for new extension NTPv4 Server (Autokey) NTPv4 client(Autokey + New Extension) Case 1: Process the packet <---- NTP Header + Autokey Extension [0x0102] Steps : a) Check NTP packet size is more than NTP Header size b) Check packet size without header which is more than NTP MAC size c) Check field type if matching as whole with Autokey filed types d) Now parse NTP filed type as per autokey Case 2: Process the packet <---- NTP Header + New Extension [0x000a] Steps : a) Check NTP packet size is more than NTP Header size b) Check packet size without header which is more than NTP MAC size c) Check field type if matching as whole with Autokey filed types d) Now parse NTP filed type More Bit (No more bit) e) after excluding NTP header + NTP extension if size is more than 0 then if check remaining size is more than MAC size then drop the packet f) Process new extension as per new extension RFC Case 3: Process the packet <---- NTP Header + Autokey Extension [0x0102] + New Extension [0x000a] Steps : a) Check NTP packet size is more than NTP Header size b) Check packet size without header which is more than NTP MAC size c) Check field type if matching as whole with Autokey filed types d) Now parse NTP filed type as per Autokey e) Check packet size without header and Autokey extension which is more than NTP MAC size f) Check field type if matching as whole with Autokey filed types g) Now parse NTP filed type More Bit (No more bit) h) after excluding NTP header + Autokey Extension + NTP extension if size is more than 0 then if check remaining size is more than MAC size then drop the packet i) Process new extension as per new extension RFC Case 4: Process the packet <---- NTP Header + Autokey Extension [0x0102] + New Extension [0x000a] + MAC Steps : a) Check NTP packet size is more than NTP Header size b) Check packet size without header which is more than NTP MAC size c) Check field type if matching as whole with Autokey filed types d) Now parse NTP filed type as per Autokey e) Check packet size without header and Autokey extension which is more than NTP MAC size f) Check field type if matching as whole with Autokey filed types g) Now parse NTP filed type More Bit (No more bit) h) after excluding NTP header + Autokey Extension + NTP extension if size is more than 0 then if check remaining size is more than MAC size then drop the packet i) Process new extension as per new extension RFC j) Process MAC (This is done at the beginning to authenticate packet) Case 5: Process the packet <---- NTP Header + Autokey Extension [0x0102] + New Extension 1 [0x800a] + New Extension 2 [0x000b] Steps : a) Check NTP packet size is more than NTP Header size b) Check packet size without header which is more than NTP MAC size c) Check field type if matching as whole with Autokey filed types d) Now parse NTP filed type as per Autokey e) Check packet size without header and Autokey extension which is more than NTP MAC size f) Check field type if matching as whole with Autokey filed types g) Now parse NTP filed type More Bit (More bit) h) Process new extension as per new extension 1 RFC i) Now parse NTP filed type More Bit (No More bit) j) Process new extension as per new extension 2 RFC k) after excluding NTP header + Autokey Extension + NTP extension 1 + NTP extension 2 if size is more than 0 then if check remaining size is more than MAC size then drop the packet Case 6: Process the packet <---- NTP Header + Autokey Extension [0x0102] + New Extension 1 [0x800a] + New Extension 2 [0x000b] + MAC Steps : a) Check NTP packet size is more than NTP Header size b) Check packet size without header which is more than NTP MAC size c) Check field type if matching as whole with Autokey filed types d) Now parse NTP filed type as per autokey e) Check packet size without header and autokey extension which is more than NTP MAC size f) Check field type if matching as whole with Autokey filed types g) Now parse NTP filed type More Bit (More bit) h) Process new extension as per new extension 1 RFC i) Now parse NTP filed type More Bit (No More bit) j) Process new extension as per new extension 2 RFC k) after excluding NTP header + Autokey Extension + NTP extension 1 + NTP extension 2 if size is more than 0 then if check remaining size is more than MAC size then drop the packet l) Process MAC (This is done at the beginning to authenticate packet) As per Current IANA https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml NTP Extension Field Types 0x0002 No-Operation Request 0x8002 No-Operation Response 0xC002 No-Operation Error Response 0x0102 Association Message Request 0x8102 Association Message Response 0xC102 Association Message Error Response 0x0202 Certificate Message Request 0x8202 Certificate Message Response 0xC202 Certificate Message Error Response 0x0302 Cookie Message Request 0x8302 Cookie Message Response 0xC302 Cookie Message Error Response 0x0402 Autokey Message Request 0x8402 Autokey Message Response 0xC402 Autokey Message Error Response 0x0502 Leapseconds Message Request 0x8502 Leapseconds Message Response 0xC502 Leapseconds Message Error Response 0x0602 Sign Message Request 0x8602 Sign Message Response 0xC602 Sign Message Error Response 0x0702 IFF Identity Message Request 0x8702 IFF Identity Message Response 0xC702 IFF Identity Message Error Response 0x0802 GQ Identity Message Request 0x8802 GQ Identity Message Response 0xC802 GQ Identity Message Error Response 0x0902 MV Identity Message Request 0x8902 MV Identity Message Response 0xC902 MV Identity Message Error Response Thanks & Regards Anil S N "Be liberal in what you accept, and conservative in what you send" - Jon Postel > -----Original Message----- > From: ntpwg [mailto:ntpwg-bounces+anil.sn=huawei.com@lists.ntp.org] On > Behalf Of Anil Kumar S N (VRP Network BL) > Sent: 01 July 2015 09:27 > To: mayer@ntp.org; Anil Kumar; Tal Mizrahi; Karen O'Donoghue; > ntpwg@lists.ntp.org; tictoc@ietf.org > Subject: Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer- > 01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt) > > I believe RFC is not specific to ntpd, sntp, ntpdate, ntimed, Windows, > Time, chrony etc... > All above has to follow RFC, So if conformance is with RFC is ultimate > reasoning. > > I will publish detailed analysis on behavior NTPv3/NTPv4 with respect > to M-Bit. > The problem is that while designing extension addition padding issue > should have been taken care, We are trying to solve it. This is an > honest attempt. > > I discussed with our network solution team, in real network most of > devices use only NTPv3 and they are not even willing to move into NTPv4 > as NTPv3 is serving their purpose. > Moving into New version is not the only solution to all the issues. > We need some improvements in current NTPv4 too. > > Core network is easy to upgrade as there will be less device using NTP, > if we move towards Access ring the number of devices are huge. > > The point is coustmer is willing to move NTPv5 if we can provide them > only with very attractive/convincing features with integrated > diagnostic tools, Since each server at the access ring is handling huge > number of clients, if there is a flapping in server. Server receives > burst of client requests. One of the requirements came for solution > team is to find as many servers as possible dynamically (with out > multicast) and narrow down to stable servers. Administrator should be > able select one of the best server. > > Selecting server : histroy of stability, challenge is trustability & > current load. > > So I feel we need to solve issue by issue. Lets not differintiate small > or big. > > Thanks & Regards > Anil S N > > "Be liberal in what you accept, and conservative in what you send" - > Jon Postel > > > > > -----Original Message----- > > From: Danny Mayer [mailto:mayer@ntp.org] > > Sent: 01 July 2015 08:43 > > To: Anil Kumar; Tal Mizrahi; Anil Kumar S N (VRP Network BL); Karen > > O'Donoghue; ntpwg@lists.ntp.org; tictoc@ietf.org > > Subject: Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum- > trailer- > > 01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt) > > > > On 6/30/2015 1:29 PM, Anil Kumar wrote: > > > If issue is backward compatibility I will prove it, if new > > > extensions Field type is not conflicting with autokey. It has no > issues. > > > > > > > How are you intending to check ntpd, sntp, ntpdate, ntimed, Windows > > Time, chrony, and a vast number of clients? > > > > Let us solve the real problem rather than coming up with hacks that > > will be almost impossible to do right. > > > > Danny > > > > > > On Tue, Jun 30, 2015, 10:55 PMÂ Danny Mayer <mayer@ntp.org > > > <mailto:mayer@ntp.org>> wrote: > > > > > > On 6/30/2015 9:15 AM, Tal Mizrahi wrote: > > > > Hi Anil, > > > > > > > > Thanks for the prompt response. > > > > > > > >> I support this draft, But how about more Bit incorporating > in > > > field type, Tal let me know your view. > > > > > > > > The checksum trailer draft requests IANA to allocate an > > extension > > > field type. > > > > Note that: > > > > (1) In unauthenticated mode, the checksum trailer extension > > field > > > is the last one. > > > > (2) In authenticated mode, the checksum trailer extension > > > field > > is > > > followed by the MAC / Autokey extension field. > > > > > > > > The suggested M-bit in > > > draft-choudharykumar-ntp-ntpv4-extended-extensions indicates > > whether > > > the current extension field is the last or not. > > > > So once the checksum trailer draft has an allocated extension > > > field type, its most significant bit will be fixed to either 0 > > > or > > 1, > > > but cannot cover both case (1) and case (2) above. > > > > > > > > A possible way to resolve this is to have two types allocated > > in > > > the checksum trailer draft, one for case (1), and another for > > case > > > (2). The two types would be identical, except for the most > > > significant bit. This would allow future compatibility with the > > > M-bit, if adopted. > > > > > > > > A question to the WG: do we want to provision for the > potential > > > adoption of the M-bit? > > > > > > > > > > No. It doesn't solve the problem for which they want it in a > > backward > > > compatible way. > > > > > > Danny > > > > > > > > > _______________________________________________ > > > ntpwg mailing list > > > ntpwg@lists.ntp.org <mailto:ntpwg@lists.ntp.org> > > > http://lists.ntp.org/listinfo/ntpwg > > > > > _______________________________________________ > 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
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Tal Mizrahi
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Anil Kumar S N (VRP Network BL)
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Danny Mayer
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Anil Kumar
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Danny Mayer
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Anil Kumar S N (VRP Network BL)
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Anil Kumar S N (VRP Network BL)
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Danny Mayer
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Danny Mayer
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Anil Kumar S N (VRP Network BL)
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Anil Kumar S N (VRP Network BL)
- Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-check… Danny Mayer