tictoc - Thursday, 28 July 2011

tictoc

tictoc@jabber.ietf.org

Thursday, 28 July 2011< ^ >

Room Configuration

GMT+0
[17:20:39] danny joins the room
[17:20:45] danny leaves the room
[19:06:34] Ron Cohen joins the room
[19:07:10] Ron Cohen leaves the room
[19:12:35] Ron Cohen joins the room
[19:18:24] Karen O'Donoghue joins the room
[19:20:16] danny joins the room
[19:20:29] <danny> bit sparse in here!
[19:21:48] <Karen O'Donoghue> in here as well…
[19:21:54] <Karen O'Donoghue> welcome danny and ron
[19:22:05] <danny> where is everybody?
[19:22:23] <danny> how many in the room?
[19:22:33] <Karen O'Donoghue> about 15
[19:22:57] <Karen O'Donoghue> i think harlan and dave hart may be joining remotely as well
[19:23:32] <danny> they were indicating that they would be. I signalled them a few minutes ago
[19:25:30] Martini joins the room
[19:35:46] <Karen O'Donoghue> Danny, can you hear him?
[19:36:30] <Ron Cohen> I can hardly hear the presenter.
[19:36:32] <Karen O'Donoghue> we've moved to the "IPsec security for packet based synchronization" presentation
[19:36:47] <Karen O'Donoghue> is that better
[19:37:01] <danny> yes
[19:37:08] Hayim joins the room
[19:37:31] <Ron Cohen> Need to increase the volume somehow
[19:37:55] <danny> I have no problem with the volume
[19:38:09] <Karen O'Donoghue> ok.
[19:38:34] <Karen O'Donoghue> slides are available at: http://tools.ietf.org/wg/tictoc/agenda
[19:38:55] <Karen O'Donoghue> he is on slide 3
[19:39:12] <danny> why are they encrypting in the first place? are the timestamps secret?
[19:40:39] awgy joins the room
[19:41:41] <Karen O'Donoghue> I'll ask in a secon
[19:42:47] Martini leaves the room
[19:43:23] lllmartini joins the room
[19:43:39] <danny> harlan is having trouble getting in here
[19:44:03] <Karen O'Donoghue> oh… that's too bad… any chance you can channel him…
[19:44:44] <danny> XMPP is not my area! :)
[19:44:47] davehart joins the room
[19:45:03] <danny> at least dave made it
[19:46:18] <davehart> I mmay have to relay something for Harlan Stenn
[19:47:15] <danny> I on the channel with Harlan
[19:51:13] <danny> encryption introduces additional delays and jitter
[19:53:48] <davehart> good point about a priority tag being abused for other traffic
[19:54:06] <danny> yep
[20:03:24] <davehart> is the current discussion rgarding one of the drafts in tictoc-drafts.pdf? which ?
[20:03:53] <Karen O'Donoghue> Precision Time Protocol Version 2 (PTPv2) Management Information Base
draft-ietf-tictoc-ptp-mib-00 <http://tools.ietf.org/html?draft=draft-ietf-tictoc-ptp-mib-00>
[20:04:03] <davehart> thanks Karen
[20:04:09] <danny> PTP Mib
[20:08:36] <danny> who is talking?
[20:10:26] <danny> can you tell us who that is?
[20:10:46] <Karen O'Donoghue> Greg Dowd was talking about the MIB...
[20:11:24] <Karen O'Donoghue> Yaakov is now talking about MPLS
[20:11:40] <Karen O'Donoghue> the 1588 encapsulation in MPLS
[20:11:52] <Karen O'Donoghue> Transporting PTP messages (1588) over MPLS Networks
draft-ietf-tictoc-1588overmpls-01 <http://tools.ietf.org/html?draft=draft-ietf-tictoc-1588overmpls-01>
[20:11:52] <danny> there was someone else before Yaakov
[20:12:23] <Karen O'Donoghue> now it is Luca Martini …
[20:12:29] <danny> right
[20:17:12] <Karen O'Donoghue> this is Giles (not something...)
[20:21:53] <danny> but does the carrier's carrier care?
[20:24:56] <Ron Cohen> Figure 2: 1588 over PW encapsulation shows entropy label. How does entropy works together with PTP?
[20:31:54] <davehart> Section 4.5 of draft-mizrahi-tictoc-checksum-trailer-00.txt claims transparent intereoperabiity with existing implementations, and it seems plausible. Has it been tested by sending NTP traffic with UDP checksum trailer extension to existing ntpd, and verified simiilar response as to NTP traffic w/o extension?
[20:32:06] awgy leaves the room
[20:33:24] <davehart> Also this is the first I've heard of MITM modification of NTP timestamps, can anyone point to examples of this practice?
[20:33:39] <danny> IEEE 1588 v2
[20:33:51] <Karen O'Donoghue> dave - i'll ask your questions at the end of his presentation
[20:34:00] <davehart> thanks Danny, any others?
[20:34:09] <davehart> Karen, great, that's what I was hoping for
[20:36:35] <danny> MAC does not really require authentication. See RFC 5905
[20:36:41] awgy joins the room
[20:38:26] Hayim leaves the room: Computer went to sleep
[20:39:38] lllmartini leaves the room
[20:40:30] <davehart> I suspect ntpd does ignore extensions properly, I also suspect other implementations (including two generations of 'sntp' util in NTP ref. impl. dist. probably would not properly handle a response including extension. Is it expected replies to requests lacking UDP checksum trailer extension will or will not have said extension?
[20:42:14] <Ron Cohen> Is it true that if you the NTP (or OWAMP/TWAMP) CPU would set a zero timestamp on transmit, the intermediate device could update the checksum field itself and will not need the extension?
[20:42:26] <Karen O'Donoghue> sorry Dave… I can't read…
[20:42:39] <danny> it should not care about UDP checksums
[20:42:58] <danny> the drivers would reject bad checksums
[20:43:23] <Ron Cohen> Is it true that if NTP (or OWAMP/TWAMP) CPU would send a zero timestamp on transmit, the intermediate device could update the checksum field itself and will not need the extension?
[20:43:27] guenterr3 joins the room
[20:46:14] <davehart> my question relates to existing client, unaware of UDP checksum trailer, sends NTP request to new, extension-capable server, will new server omit extension from response?
[20:47:06] <davehart> presumably so, but it should be spelled out I think in draft. Will followup in email.
[20:47:12] <danny> it would probably send the extension. The client if it was unaware would ignore the checksum trailer
[20:48:02] <davehart> I agree, Danny, ideally, but I fear non-ntpd implementations lack code to skip extensions
[20:50:57] <danny> there are already plenty of broken implementations out there. We cannot force them to change but it would make them fix the code or use something else.
[20:55:30] <davehart> Section 4.2 of draft-marlow-tictoc-computer-clock-accuracy-00.txt (that is, using PTP hardware support to get better received timestamp) seems promising and I am interested in pursuing. Is hardware-assisted receive timestamping available to non-PTP traffic today? What would be needed to enable that in the future?
[20:56:00] <davehart> sorry, better received timestamp for _NTP packets_
[20:56:40] <davehart> repeated, to edit: Section 4.2 of draft-marlow-tictoc-computer-clock-accuracy-00.txt (that is, using PTP hardware support to get better received timestamp of NTP traffic) seems promising and I am interested in pursuing. Is hardware-assisted receive timestamping available to non-PTP traffic today? What would be needed to enable that in the future?
[20:57:17] <danny> interleave is what dave mills implemented for this
[20:58:21] <davehart> sure, and in draft are preliminary results which were only slightly better than non-interleaved, but as speaeker said, need to try symmetric interleaved, prelim tests were broadcast interleaved
[20:59:31] <Ron Cohen> Who is talking now?
[20:59:38] <Karen O'Donoghue> sorry tim plunkett...
[20:59:46] <Karen O'Donoghue> previously was dave marlow
[21:01:19] <Karen O'Donoghue> Greg Dowd
[21:01:33] <Karen O'Donoghue> I really need a real jabber scribe…
[21:01:48] <danny> pay for my ticket!
[21:02:08] <Karen O'Donoghue> :-)
[21:07:13] <danny> harlan says that there are some changes to mode 6 since then
[21:07:37] <danny> harlan says that it should include mode 7 also
[21:07:40] <davehart> Not mode 7 I hope (ntpdc), only mode 6 (ntpq)
[21:07:47] <davehart> exactly what was said :)
[21:07:54] <danny> tell that to harlan!
[21:08:16] <danny> he asked me to send that
[21:09:11] <davehart> mode 7 is fragile, involves lots of code, not extensible in reasonble terms, and involves hand-rolled marshalling for every operation
[21:09:22] <danny> harlan offering to work on the RFC
[21:09:43] <davehart> in 1305 mode 7 was defined as vendor-specific and specifically not standardized
[21:09:47] <danny> mode 7 was always vendor specific
[21:10:13] <danny> yep
[21:12:19] <danny> by Rich Schmidt of USNO
[21:13:03] <Karen O'Donoghue> Greg Dowd..
[21:14:18] <davehart> today other digest algorithms are supported by NTP for symmetric authentication (not autokey)
[21:14:33] <davehart> that includes time transfer as well as authenticating mode 6 & 7
[21:15:06] <davehart> I should say I don't know about autokey, I know other digests work for symmetric
[21:15:35] <danny> no. USNO
[21:16:01] <davehart> ntpd 4.2.6 is first ntpd that supports other than MD5 for symmetric
[21:16:21] <davehart> first -stable version that is
[21:17:17] lllmartini joins the room
[21:17:32] <davehart> repeating to edit: ntpd as of 4.2.6 supports any digest algorithm openssl provides, and is tested for symmetric authentication using non-MD5 digests
[21:17:39] <danny> there was something other than a bug. It was a protocol problem if I remember correctly
[21:20:16] <danny> probably need to explicitly test SHA-256 and document results
[21:20:42] <davehart> my comments were specific to symmetric auth. DLM thinks autokey can use other digest algorithms but I do not know of any tests of that.
[21:20:56] <danny> right
[21:21:28] <davehart> symmetric auth is when "key" is specified on server line in ntp.conf, or when ntpq/ntpdc prompt for password for authentication-required operations
[21:22:06] <davehart> sorry DLM = Dr. David L. Mills
[21:23:07] <davehart> Thank you for your scribing service Karen!
[21:23:22] <Karen O'Donoghue> you're welcome …
[21:24:04] <davehart> I wish you had help but your work was more than satisfactory, and much appreciated
[21:26:27] Karen O'Donoghue leaves the room
[21:27:51] danny leaves the room
[21:28:06] awgy leaves the room
[21:28:21] davehart leaves the room: offline
[21:30:06] guenterr3 leaves the room
[21:30:15] guenterr3 joins the room
[21:32:36] guenterr3 leaves the room
[21:35:26] Ron Cohen leaves the room
[21:39:50] Karen O'Donoghue joins the room
[21:40:51] lllmartini leaves the room
[22:54:49] Karen O'Donoghue leaves the room