Subject: [ntpwg] Fwd: Re: Fwd: [TICTOC] reminder for remote participation in today's tictoc meeting

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 08 Jun 2011 23:09:45 -0400

Folks,

This came to me personally, and I neglected to send it on to the ntp and 
tictoc wg lists. My apologies for the delay. The question before us is 
whether or not the interleave capability should be properly documented 
and where the resources will come from to complete the effort.

Karen

-------- Original Message --------
Subject: 	Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in 
today's tictoc meeting
Date: 	Tue, 12 Apr 2011 18:18:43 +0000
From: 	David L. Mills <[email-masked]>
To: 	[email-masked]

Karen,

The following is in response to the ID you distributed. I offer it as a 
candidate for distribution to th eWG members.

Dave

This internet draft describes experiments using the interleaved 
broadcast mode recently incorporated in the NTP reference 
implementation. The experiments do not include the interleaved symmetric 
mode, which provides similar functionality in peer-to-peer 
configurations. For reference, these modes, their relevance to PTP and 
related information are discussed in detail in Chapters 15 through 17 of 
the book "Network Time Synchronization - the Network Time Protocol on 
Earth and in Space, Second Edition, CRC Press 2011, as cited on my web 
page www.eedis.udel.edu/~mills. However, most of the information 
relevant to the followings discussion can be found in the white papers 
at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the 
documents "Analysis and Simulation of the NTP On-Wire Protocol" and 
"Security Analysis of the NTP Protocol." Both of these documents 
represent an update since the book was published late last year.

Readers may wonder why these documents have not been published as an 
update to the protocol specification RFC-5905, which would have been the 
expectation several years ago in the adolescent Internet. However, the 
effort necessary to publish an ID with figures, tables and equations is 
nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 
over the last five years of publishing effort is not sustainable. Thus, 
unless some collaboration, perhaps the TICTOC working group, chose to 
publish them as IDs, I will not commit that adventure myself.

First some nomenclature that may help in the following discussion. 
Timestamps captured for the clock discipline are classed as hardstamps, 
drivestamps and softstamps. Softstamps are captured during the course of 
user-space processing; they may be corrupted by operating system and 
device latencies, as well as transmission delays. Drivestamps are 
captured during the packet interrupt routines, so are much less affected 
by operating system scheduling and competition with other programs. 
Hardstamps are captured by dedicated hardware means, typically in the 
PHY layer of the network interface card (NIC). While the details vary, 
the typical intercept point is the media independent interface (MII), 
which monitors the frame level interface on a character by character 
basis. The capture means is usuallt a field-programmable gate array 
(FPGA) that parses the packeet, inserts timestamp data and recomputes 
the UDP checksum.

The interleaved capability was originally not intended for NTP, but for 
the Proximity-1 protocol specified by the Consultive Committee on Space 
Data systems (CCSDS). The Proximity-1 protocol is designed for 
communication between spacecraft in the vicinity of Mars and for future 
missions in the vicinity of the Moon. Space data links are often 
operated at very low data rates compared to typical Ethernet links. 
Typical rates range from 1 kb/s to 256 kb/s with very different data 
rates in each direction. Due to various queuing and transmission 
operations, the output delay can reach 30 s, so it is imparities that 
timestamps be captured close to the PHY layer. In the Proximity-1 
desing, hardstamps are captured upon the passage of the ASM code 
combination at the beginning of each transmitted frame..

Queuing and transmission delays are not the only contributors to space 
data link delay. Reed-Solomon and convolutional encoding delays can be a 
large contribution to the link delay; however, these delays are a 
constant contribution to the lightwave transmission delay. These 
contributions -- up to many seconds -- can dwarf the lightwave 
transmission delays.

In the NTP interleaved design, drivestamps are captured in the device 
interrupt routine - on input immediately after the frame has been 
received and before copying to an input buffer; on output shortly after 
the frame has been transmitted and before the buffer is released for the 
following input or output frame. This can become rather awkward in the 
case of NICs of the PCNET architecture, as data are copied directly from 
user space to device buffers directed by DMA descriptors. Drivestamps 
have been used on input for many years, but for output this is possible 
only using the interleaved modes. The result avoids the latencies due to 
the message digest computation, Autokey protocol data units, output 
queuing and frame transmissions, typically some 10-40 microseconds.

It should be obvious from the documents that a primary motivation for 
the NTP interleaved design was protection from network errors and 
intruder attack. The detailed analysis and simulation are designed to 
demonstrate resistance to common corruptions such as dropped or 
duplicate packets and possible bogus attacks. The NTP design includes a 
four-level security model, the lower two levels might be considered for 
a PTP application. This is one of the most important difference between 
the PTP and NTP protocol designs; however, the NTP design might be 
considered overkill in a sheltered, isolated Ethernet network.

Careful observers may notice an interesting anomaly with the interleaved 
broadcast mode. The preliminary volley intended to measure the roundtrip 
time uses basic mode, not interleaved mode. The reason for this requires 
some explanation. In times of old, the dominant concern was the 6-bone, 
an international consortium of multicast application developers. In that 
context with historic multicast configurations, including DVMRP and PIM, 
the multicast spanning tree was far different than the unicast spanning 
tree. Therefore, the preliminary volley was important to estimate the 
offset of the multicast server to the multicast client and thus the 
apparent one-way delay. In principle, with adroit protocolmanship, it 
would be possible to change the protocol to measure the interleaved 
roundtrip delay, which would be more appropriate for modern high-speed 
Ethernet networks.

Karen O'Donoghue wrote:
>
>
> -------- Original Message --------
> Subject: 	[TICTOC] reminder for remote participation in today's tictoc 
> meeting
> Date: 	Thu, 31 Mar 2011 09:56:35 +0200
> From: 	Karen O'Donoghue <[email-masked]>
> Reply-To: 	[email-masked]
> Organization: 	ISOC
> To: 	[email-masked], NTP Working Group <[email-masked]>
>
>
>
> Folks,
>
> This is a reminder that the tictoc working group will meet today from
> 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF
> meeting (http://tools.ietf.org/agenda/80/) has links for the drafts,
> presentations, jabber chat room, and audio streaming to facilitate
> remote participation.
>
> Regards,
> Karen
>
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>    
> ------------------------------------------------------------------------
>
> _______________________________________________
> ntpwg mailing list
> [email-masked]
> http://lists.ntp.org/listinfo/ntpwg

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 08 Jun 2011 22:39:16 -0700

Karen wrote:

> The question before us is whether or not the interleave capability
> should be properly documented

Yes

> and where the resources will come from to complete the effort.

Good question.

H

---

From: Danny Mayer <[email-masked]>
Date: Thu, 09 Jun 2011 07:53:07 -0400

It's not just interleave capability that needs to be added, but also:

1) mode 6 (public) command control packets which is documented in RFC
1305 but got dropped when obsoleting it;
2) add support for SHA-nnn to replace MD5 for FIPS compliance (see Rich
Schmidt's bug report);
3) The work your former group has been doing that was presented at the
last IETF meeting in Prague, if it's worth standardizing.

I seem to remember a few other issues that we had discussed but I can't
think of them right now.

Danny

On 6/8/2011 11:09 PM, Karen O'Donoghue wrote:
> contributions – up to many seconds – can dwarf the lightwave
> transmission delays.
>

---

From: "Marlow, David T CIV NSWCDD, W64" <[email-masked]>
Date: Thu, 9 Jun 2011 16:38:24 -0400

Danny and All,
   The work Tim Plunkett discussed at the last IETF meeting in Prague (draft-marlow-tictoc-computer-clock-accuracy-00.txt) included some results from preliminary experiments with NTP Interleave that is in NTP version 4.2.6.  We got some modest improvements over previous experiments which used earlier NTP versions without Interleave.   Further experimentation is needed, but we were wondering if others have data that Interleave provides a sufficient increase in performance (or another category) to standardize it?

   Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Danny Mayer
Sent: Thursday, June 09, 2011 7:53
To: [email-masked]
Cc: NTP Working Group; [email-masked]; David L. Mills
Subject: Re: [TICTOC] [ntpwg] Fwd: Re: Fwd: reminder for remote participation in today's tictoc meeting

Danny

On 6/8/2011 11:09 PM, Karen O'Donoghue wrote:
> contributions - up to many seconds - can dwarf the lightwave
> transmission delays.
>

---

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 09 Jun 2011 18:11:56 -0400

Danny,

You are absolutely correct. I was just referring to the forwarded 
message from Dave Mills...

Folks, there are a number of items that need to be done. I'd love to 
have some volunteers to help work on these.

Karen

On 6/9/11 7:53 AM, Danny Mayer wrote:
>> From: 	David L. Mills<[email-masked]>
>> To: 	[email-masked]
>>
>>
>>
>> Karen,
>>
>>> From: 	Karen O'Donoghue<[email-masked]>
>>> To: 	[email-masked], NTP Working Group<[email-masked]>
>>>
>>>
>>>
>>> Folks,
>>>

---

From: todd glassey <[email-masked]>
Date: Fri, 10 Jun 2011 08:32:10 -0700

On 6/9/2011 3:11 PM, Karen O'Donoghue wrote:
>> Schmidt's bug report); o
I actually would like to add another interface for a HSM to handle the 
specific cryptographic services. I have a couple of architectures in 
mind which would allow several of the FIPS-140-2/Level 3 Token Systems 
to be used with the model.

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

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 10 Jun 2011 16:29:48 +0000

Karen,

Danny's list does not involve a lot of work except the interleaved 
issue. In my recent message I raised the issue that the current 
calibration round does not use interleaved mode, so the roundtrip 
measurement is not precise. I have updated the white paper onwire.html 
at the NTP project site www.eecis.udel.edu/~mills/ntp.html to fix this. 
Note that the revised code is not in the reference implementation. The 
reason for that is that the revised description is vulnerable to a 
wiretap attack, while the original code is not. Therefore, there is a 
choice between best accuracy and best defense against the bad guys.

As for additional experiments on interlaaved performance, there is data 
in the book on LAN measurements. Additional experiments are easy to do, 
especially as the output delay is revealed on the ntpq billboards. While 
probably not of primary interest, the improvement when Autokey extension 
fields are involved is dramatic.

The PTB folks have expressed interest in the Autokey facilities and have 
found a middleman vulnerability that may be hard to fix. I have updated 
the whit paper security.html at the NTP project site and have uncovered 
another middleman vulnerability having to do with the identity 
exchanges. This one is easy to fix, as outline in the document. 
Additional discussion on the cookie vulnerability would be welcome.

Dave

Dave