Subject: Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Wed, 1 Jul 2015 14:54:52 +0000

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=[email-masked]] On
> Behalf Of Anil Kumar S N (VRP Network BL)
> Sent: 01 July 2015 09:27
> To: [email-masked]; Anil Kumar; Tal Mizrahi; Karen O'Donoghue;
> [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent: 01 July 2015 08:43
> > To: Anil Kumar; Tal Mizrahi; Anil Kumar S N (VRP Network BL); Karen
> > O'Donoghue; [email-masked]; [email-masked]
> > 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 <[email-masked]
> > > <mailto:[email-masked]>> 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
> > >     [email-masked] <mailto:[email-masked]>
> > >     http://lists.ntp.org/listinfo/ntpwg
> > >
> 
> _______________________________________________
> ntpwg mailing list
> [email-masked]
> http://lists.ntp.org/listinfo/ntpwg
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Wed, 01 Jul 2015 11:28:55 -0400

On 6/30/2015 11:57 PM, Anil Kumar S N (VRP Network BL) wrote:
> 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 know that but you cannot be sure you won't break things if you don't
check the most widely used implementations of NTP.

> 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. 
> 

You cannot solve it in NTPv4 because you cannot signal this change in
any way to any NTPv4 system that don't know about it. While I agree that
we should relax the requirements on the length of the extension field,
servers that don't know about this change will drop the packet because
it doesn't conform to the existing requirements for extension field sizes.

> 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. 

That's always been true and going to a new version of NTP won't change
that. On the other hand vendors who don't moved to the newer versions of
NTP won't get the benefit of all the changes, enhancements and bug fixes
but then most network devices are only interested in setting their own
time and don't care if the time received contains unknown extra information.

> We need some improvements in current NTPv4 too.

The problem is that you lose a lot of servers if the extension field
does not comply with existing standards. They will drop the packet.

> 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 customer 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.

Can you explain what you mean by 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.

The problem with that idea is that the Adminstrator rarely knows enough
to choose the right server. The selection rules in NTP are complicated
and they would need to know a great deal about NTP to be able to choose
a server. But it gets worse. What's a good server at one instance of
time is a bad server the next. NTP is designed to select the best server
at each point in time and use it and change it as conditions change. An
administrator is never going to be doing that. For most administrators,
it's set and forget and move on to the next task. NTP (at least the
reference implementation) is good at making those decisions for the
administrator.

> 
> Selecting server : histroy of stability, challenge is trustability & current load.
> 

Which changes from moment to moment. past performance is not an
indicator of future performance. If you need trustability you should be
using autokey or similar technologies.

> So I feel we need to solve issue by issue. Lets not differintiate small or big.
> 

It's the details that kill you.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 01 Jul 2015 22:11:42 -0400

> Backward compatibility analysis for M-BIT in Extension field types.

This is the wrong thread to lay out your ideas. You need to create a
separate thread.

The proposal would cause problems for Tal's draft since he would have to
go back and update any previous Extension Fields (I seem to remember
that this needs to be last) to change something in that extension field.
This would be true for ALL extension fields. This is really a bad idea.
It causes unnecessary extra processing.

Danny

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 2 Jul 2015 04:01:53 +0000

> check the most widely used implementations of NTP.

 [Anil >>] I have posted a mail with analysis for backward compatibility 
Let me know if you find any issues with respect to backward compatibility

> it doesn't conform to the existing requirements for extension field
[Anil >>]  Servers understand only Autokey now as per IANA, So Autokey 
is untouched, For any new extension if they follow M-bit then there is 
no issues and if server dosent understand new extension anyways server
is gonna drop packet irrespective of M-Bit

> devices use only NTPv3 and
[Anil >>] I feel if we introduce new version, we must make sure 
They move into NTPv5 not because of compulsion instead new features 
Available. NTPv3 is so stable that it has proved its correctness from 
Years. People are happy with NTPv3.

> does not comply with existing standards. They will drop the packet.
[Anil >>] Server will never initiate NTP messages, So there should be 
A way that client and server negotiate what they support. This is tricky 
because backward compatibility has to be supported.

> Can you explain what you mean by flapping in server?

 [Anil >>] Yes, In access network NTP server is loaded with ntp client 
Packets or its server's response packets. For the sake of correctness NTP 
server process first N packets rest of the packets are droped due to incorrect 
timestamping this case is when there is no hardware timestamping. 
This could be one of the reason where server looses its server and
In response to client says server is unsync. When server synchronized 
To its server again clients will get synchronized to server.

The main reason is in the network they will not have many servers,
As per ntp RFC at least three servers are expected for correctness of 
Server selection but administrators will have two servers where one is 
Preferred. But these two servers are parallel servers (Same level, same staratum), 
which is synchronized to same server.

One more reason that NTP servers goes to sync and unsync due to step adjustment
is server running with poor hardware, or to be specific very very old device.

> reference implementation) is good at making those decisions for the

[Anil >>] 
I agree administrator can't make this decision, but he can't feel handicapped. 
I believe in NTP selection procedure, But the problem which I would to address 
for them is by giving options. Somehow client should get to know all the NTP 
servers available in the network which is cleared NTP selection process.
These must be candidate for administrator. Here Administrator cant select 
Just based on looking at IP address, He has to give some more information 
About servers which will make him feel confidant on selecting one of the server.

> using autokey or similar technologies.
[Anil >>]  I don't think any major vendors even have autokey in their release till now.
Huawei has autokey but not even one customer is using inspite of hundreds of thousands 
Routers are running NTP. We should understand what difficulties they are facing and why 
They don't want to use Autokey.

Success of new protocol lies in number of interested people to use it. 

> It's the details that kill you.
[Anil >>]  There are lot more complicated protocols in the network with 
100's of extensions. I am routing background, I know how complicated BGP and OSPF is.
This is just adding a bit to field type. So that new extension are added and used with ease.

Thanks & Regards
Anil S N

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 2 Jul 2015 04:16:23 +0000

Sorry Danny, Better late than never. I would be the last person who wishes to
Block someone's idea or draft from adopting. I would humbly request Tal 
This one time to update draft since tal has option to update now.

When autokey was designed the padding constraint should have been removed.
And I also strongly feel only one field type value should have been assigned to 
Autokey, instead 30 filed type values is been awarded, extra details such as 
Sub-autokey message type should have been moved inside the extension body. 

these are the decisions must be taken at the initial phase.

Lets discuss below statement based on merits and de merits of the M-Bit.
" This is really a bad idea. It causes unnecessary extra processing."
I hear above point on every reply of yours :) I am use to it :) 

I will Give a analysis on current processing and with M-Bit processing which 
Would take more processing and more packet size. Based on it let the community 
decide.

Thanks & Regards
Anil S N

> From: ntpwg [mailto:ntpwg-bounces+anilkumarsn=[email-masked]]
> On Behalf Of Danny Mayer
> Sent: 02 July 2015 07:42
> To: Anil Kumar S N (VRP Network BL); Anil Kumar; Tal Mizrahi; Karen
> The proposal would cause problems for Tal's draft since he would have
> to go back and update any previous Extension Fields (I seem to remember
> > Process the packet	<----	NTP Header + Autokey Extension [0x0102] +
> New Extension 1 [0x800a] + New Extension 2  [0x000b]
> > Steps :
> > Process the packet	<----	NTP Header + Autokey Extension [0x0102] +
> New Extension 1 [0x800a] + New Extension 2  [0x000b] + MAC
> > Steps :
> >> From: ntpwg [mailto:ntpwg-bounces+anil.sn=[email-masked]]
> >> On Behalf Of Anil Kumar S N (VRP Network BL)
> >> Sent: 01 July 2015 09:27
> >> 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...
> >> devices use only NTPv3 and they are not even willing to move into
> >> NTPv4 as NTPv3 is serving their purpose.
> >> 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.
> >>
> >> 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

---

From: Danny Mayer <[email-masked]>
Date: Thu, 02 Jul 2015 17:04:46 -0400

> Let me know if you find any issues with respect to backward compatibility

The analysis needs to be in its own thread and has nothing to do with
the checksum trailer draft.

> is gonna drop packet irrespective of M-Bit

You mean that IANA is the only place you should look?

> Years. People are happy with NTPv3.

I believe that Dave Mills has a paper somewhere about the problems with
v3 and why he went to v4.

> because backward compatibility has to be supported.

All servers are also clients so that argument doesn't hold water.

> About servers which will make him feel confidant on selecting one of the server.

The administrator already makes a decision by choosing a list of servers
in the configuration file or dynamically adding them if necessary. Most
admins do this went setting up a system but once they have chosen they
forget all about it and never come back. That's the reality.

> This is just adding a bit to field type. So that new extension are added and used with ease.

I know and that's not JUST adding a bit. The amount of testing is
enormous in addition to everything else.

Danny