From yaakov_s@rad.com Thu Mar 4 08:32:04 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CB23A8B48 for ; Thu, 4 Mar 2010 08:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w657XHzj37IT for ; Thu, 4 Mar 2010 08:32:02 -0800 (PST) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id BAB703A8D34 for ; Thu, 4 Mar 2010 08:32:00 -0800 (PST) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 04 Mar 2010 18:32:01 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Thu, 4 Mar 2010 18:32:00 +0200 From: Yaakov Stein To: "tictoc@ietf.org" Date: Thu, 4 Mar 2010 18:32:00 +0200 Thread-Topic: TICTOC Slots for IETF 77 - Anaheim Thread-Index: Acq7uDbMR98WcvcPR++31+gP4ggkZg== Message-ID: <48E7911F78327A449A9FB9563766728642A6E312@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB9563766728642A6E312exrad4adradcoil_" MIME-Version: 1.0 Subject: [TICTOC] TICTOC Slots for IETF 77 - Anaheim X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:32:04 -0000 --_000_48E7911F78327A449A9FB9563766728642A6E312exrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Anyone who wants a slot for the upcoming meeting should email Stewart and m= yself detailing the subject, a draft name if one exists, time required, and prese= nter. However, we expect the bulk of the session to be devoted to discussion of t= he future of the WG. Y(J)S --_000_48E7911F78327A449A9FB9563766728642A6E312exrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Anyone who wants a slot for the upcoming meeting shoul= d email Stewart and myself

detailing the subject, a draft name if one exists, tim= e required, and presenter.

 

However, we expect the bulk of the session to be devot= ed to discussion of the future of the WG.

 

Y(J)S

 

--_000_48E7911F78327A449A9FB9563766728642A6E312exrad4adradcoil_-- From yaakov_s@rad.com Wed Mar 17 09:24:54 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5BB128C118 for ; Wed, 17 Mar 2010 09:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[AWL=-1.772, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UREdPj0H5ZZr for ; Wed, 17 Mar 2010 09:24:52 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id 93ADB28C0E5 for ; Wed, 17 Mar 2010 09:23:15 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 17 Mar 2010 18:23:23 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 17 Mar 2010 18:23:22 +0200 From: Yaakov Stein To: "tictoc@ietf.org" Date: Wed, 17 Mar 2010 18:23:20 +0200 Thread-Topic: TICTOC Slots for IETF 77 - Anaheim Thread-Index: AcrF7iiNYVuea8cxQ3aayJg0IwIiYQ== Message-ID: <48E7911F78327A449A9FB9563766728642D23702@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB9563766728642D23702exrad4adradcoil_" MIME-Version: 1.0 Subject: [TICTOC] TICTOC Slots for IETF 77 - Anaheim X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 16:24:54 -0000 --_000_48E7911F78327A449A9FB9563766728642D23702exrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have not received any requests for talks at the TICTOC meeting. The subjects that we want to focus on are : * Timing flows over MPLS (MPLS-TP?) [I will show a few slides on this top= ic] * Auto discovery of on-path support and routing time transfer packets over = those paths * Extensions to (now approved) NTPv4 (e.g., Dave's follow-up messages) * Requirements for next generation NTP (e.g. profiles, higher accuracy, glo= bal mechanisms) Anyone who wants a slot for the upcoming meeting should email Stewart and m= yself detailing the subject, a draft name if one exists, time required, and prese= nter. However, we expect the bulk of the session to be devoted to discussion of t= he future of the WG. Y(J)S --_000_48E7911F78327A449A9FB9563766728642D23702exrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have not received any requests for talks at the TICT= OC meeting.

 

The subjects that we want to focus on are :=

 

* Timing flows over MP= LS (MPLS-TP?)   [I will show a few slides on this topic]<= /p>

* Auto discovery of on= -path support and routing time transfer packets over those paths

* Extensions to (now a= pproved) NTPv4 (e.g., Dave's follow-up messages)

* Requirements for nex= t generation NTP (e.g. profiles, higher accuracy, global mechanisms)

 

Anyone who wants a slot for the upcoming meeting shoul= d email Stewart and myself

detailing the subject, a draft name if one exists, tim= e required, and presenter.

 

However, we expect the bulk of the session to be devot= ed to discussion of the future of the WG.

 

Y(J)S

 

--_000_48E7911F78327A449A9FB9563766728642D23702exrad4adradcoil_-- From yaakov_s@rad.com Mon Mar 22 16:13:20 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD29528C20F for ; Mon, 22 Mar 2010 16:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.046 X-Spam-Level: X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AETjPicJrfoQ for ; Mon, 22 Mar 2010 16:13:11 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id BCE6028C20E for ; Mon, 22 Mar 2010 16:13:07 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 23 Mar 2010 01:13:26 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Tue, 23 Mar 2010 01:13:25 +0200 From: Yaakov Stein To: "tictoc@ietf.org" Date: Tue, 23 Mar 2010 01:13:21 +0200 Thread-Topic: tomorrow's meeting Thread-Index: AcrKFUPtSo9BsqS5QWGzXTMyfJ8wmA== Message-ID: <48E7911F78327A449A9FB9563766728642E0FAED@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB9563766728642E0FAEDexrad4adradcoil_" MIME-Version: 1.0 Subject: [TICTOC] tomorrow's meeting X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 23:13:20 -0000 --_000_48E7911F78327A449A9FB9563766728642E0FAEDexrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, Tomorrow's meeting will be a crucial one for TICTOC, so I hope everyone wil= l be able to attend. In fact, tomorrow's meeting will be more like a BOF (or the inverse of a BOF - which is FOB, as in FOB watch, as is suitable fo= r a timing WG). I have uploaded my slides to the meeting materials site, so you can see the= m ahead of time. Y(J)S --_000_48E7911F78327A449A9FB9563766728642E0FAEDexrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

Tomorrow's meeting will be a crucial one for TICTOC, s= o I hope everyone will be able to attend.

 

In fact, tomorrow's meeting will be more like a BOF

(or the inverse of a BOF – which is FOB, as in F= OB watch, as is suitable for a timing WG).

 

I have uploaded my slides to the meeting materials sit= e, so you can see them ahead of time.

 

 

Y(J)S

 

--_000_48E7911F78327A449A9FB9563766728642E0FAEDexrad4adradcoil_-- From antti.pietilainen@nsn.com Wed Mar 24 04:47:59 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B7C3A6852 for ; Wed, 24 Mar 2010 04:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhsATTufpr77 for ; Wed, 24 Mar 2010 04:47:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 382B03A6405 for ; Wed, 24 Mar 2010 04:47:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2OBmCGb023364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Mar 2010 12:48:12 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2OBmBYo012308; Wed, 24 Mar 2010 12:48:11 +0100 Received: from FIESEXC014.nsn-intra.net ([10.159.0.22]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 12:48:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 13:48:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security and management of IEEE1588 (PTP) Thread-Index: AcrLR+CW4JHVtmReRCivJ/Pyq0QHnA== From: "Pietilainen, Antti (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 24 Mar 2010 11:48:11.0464 (UTC) FILETIME=[E1305C80:01CACB47] Cc: Greg Dowd Subject: [TICTOC] Security and management of IEEE1588 (PTP) X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 11:47:59 -0000 Hi Greg, I went through your presentations in the TICTOC meeting. The work items are valid. However, I would like to raise discussion of the suitable standards group in the case of telecom profiles of PTP. My viewpoint is a mobile network vendor's. Security Frequency synchronization without on-path support: 3GPP has specified the use of IPSEC for securing mobile backhaul if necessary. PTP can use the same IPSEC tunnels that are set up for the rest of the base station traffic. Thus, no new security methods are needed at least considering mobile backhaul. In the case of time synchronization with on-path support, if security-enabled, all PTP nodes need to authenticate their immediate neighbors in terms of synchronization. On the other hand, the data traffic rather needs end-to-end security, moreover with end-to-end encryption. Therefore, probably a separate security solution is needed for PTP. There is already an experimental annex in PTP, which covers security for PTP in general - i.e. not only for PTP/UDP/IP stack but also PTP/Ethernet stack. The solution has been verified by security experts of NIST. TICTOC should not declare itself as the owner of PTP security unless the timing community requests it. Management ITU-T Q13/SG15 has decided that management is out of scope of the PTP telecom profile for the time being. Telecom vendors have incorporated the management of packet timing into their network management systems. I don't see that the telecom companies have done a mistake in standards work that needs to be corrected by TICTOC. Surely it is possible to raise the management issue again in Q13 if needed. Conclusion I propose that the possible security & management work carried out in TICTOC would not concern telecom usage of PTP unless IETF and ITU decide together to do otherwise.=20 Best regards, Antti Antti Pietilainen Nokia Siemens Networks Mobile transport research Linnoitustie 6 02600 ESPOO Finland tel. +358-71-8036660 =20 From yaakov_s@rad.com Wed Mar 24 05:07:35 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4601D3A67E2 for ; Wed, 24 Mar 2010 05:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5i198Y9XNIw for ; Wed, 24 Mar 2010 05:07:32 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id 73B713A67CF for ; Wed, 24 Mar 2010 05:07:29 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 24 Mar 2010 14:07:49 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 24 Mar 2010 14:07:47 +0200 From: Yaakov Stein To: "Pietilainen, Antti (NSN - FI/Espoo)" , Greg Dowd Date: Wed, 24 Mar 2010 14:07:44 +0200 Thread-Topic: Security and management of IEEE1588 (PTP) Thread-Index: AcrLR+CW4JHVtmReRCivJ/Pyq0QHnAAAUZ1Q Message-ID: <48E7911F78327A449A9FB9563766728642E91311@exrad4.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tictoc@ietf.org" Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP) X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 12:07:35 -0000 > Frequency synchronization without on-path support: 3GPP has specified > the use of IPSEC for securing mobile backhaul if necessary. PTP can use > the same IPSEC tunnels that are set up for the rest of the base station > traffic. Thus, no new security methods are needed at least considering > mobile backhaul. > In the case of time synchronization with on-path support, if > security-enabled, all PTP nodes need to authenticate their immediate > neighbors in terms of synchronization. On the other hand, the data > traffic rather needs end-to-end security, moreover with end-to-end > encryption. Therefore, probably a separate security solution is needed > for PTP. There is already an experimental annex in PTP, which covers > security for PTP in general - i.e. not only for PTP/UDP/IP stack but > also PTP/Ethernet stack. The solution has been verified by security > experts of NIST. TICTOC should not declare itself as the owner of PTP > security unless the timing community requests it. Antti - I'm sorry, but I can't quite parse these statements. Saying that timing flows will go through the same IPsec tunnels as data basically says that there are no timing-specific security mechanisms being used. That is precisely what we want to address. In our requirements work we already came to the conclusion that there was no pressing reason for encrypting timing packets, and tunneling them through IPsec may be useful for anti-tampering - but comes at a price of performance degradation. Saying that the security experts from NIST (whom I respect a great deal) have looked at this and are happy is also close to meaningless. Security experts are not necessarily timing experts (and vice versa), and I have yet to see the security experts address the security issues that have already been well documented by the NTP community. TICTOC is not declaring itself the owner of anything. In particular, at this point I believe that most of us want to avoid focusing on mobile backhauling,=20 and while 1588 is one of the possible timing protocols, it is not our only or main interest. Y(J)S From yaakov_s@rad.com Wed Mar 24 05:21:42 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D753A6818 for ; Wed, 24 Mar 2010 05:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.131 X-Spam-Level: ** X-Spam-Status: No, score=2.131 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_80=2, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j1ih9XN3iVA for ; Wed, 24 Mar 2010 05:21:37 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id A8CC93A6852 for ; Wed, 24 Mar 2010 05:21:26 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 24 Mar 2010 14:21:45 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 24 Mar 2010 14:21:44 +0200 From: Yaakov Stein To: "tictoc@ietf.org" Date: Wed, 24 Mar 2010 14:21:41 +0200 Thread-Topic: protocol independent timing MIB Thread-Index: AcrLTI8DNY/9MeJ6TSiUST9XNsY+rw== Message-ID: <48E7911F78327A449A9FB9563766728642E91344@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB9563766728642E91344exrad4adradcoil_" MIME-Version: 1.0 Subject: [TICTOC] protocol independent timing MIB X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 12:21:43 -0000 --_000_48E7911F78327A449A9FB9563766728642E91344exrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I just wanted to follow up on an idea that arose yesterday during discussio= n of Greg's management presentation. I think that developing a standard protocol independent timing management e= ntity would be a really good thing to do. In particular, such an information base could hold more detailed informatio= n than simply "PRC", or "stratum 2" or "wristwatch", and could be used by possible client= s to make more informed decisions as to which server to pick. Such a MIB could hold the following kinds of information : identification (name/ID) types of timing supported (none, frequency, uncalibrated time, ToD) supported timing functionality (grandmaster, server, TC, BC, ...) to what this timing is traceable (local hydrogen maser, GPS, ..., sundial) history of lock (hourly ?) supported protocols (SyncE, NTPv3, NTPv4, 1588v1, 1588v2, CTP, TTP, sercos,= ...) mean delay to upstream master, server, or peer measured asymmetries current UTC offset dispersion over the past few days port states, time domains, ... etc. and would have traps for loss of lock events. There could also be protocol dependent parts, holding internals that may be= needed. Comments ? Y(J)S --_000_48E7911F78327A449A9FB9563766728642E91344exrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I just wanted to follow up on an idea that arose yeste= rday during discussion of Greg's management presentation.

 

I think that developing a standard protocol independen= t timing management entity would be a really good thing to do.

 

In particular, such an information base could hold mor= e detailed information than simply

"PRC", or "stratum 2" or "wristwatch", and could be used by possible clients to make more informed

decisions as to which server to pick.

 

Such a MIB could hold the following kinds of informati= on :

 

identification (name/ID)

types of timing supported (none, frequency, uncalibrat= ed time, ToD)

supported timing functionality (grandmaster, server, T= C, BC, …)

to what this timing is traceable (local hydrogen maser= , GPS, …, sundial)

history of lock (hourly ?)

supported protocols (SyncE, NTPv3, NTPv4, 1588v1, 1588= v2, CTP, TTP, sercos, …)

mean delay to upstream master, server, or peer

measured asymmetries

current UTC offset

dispersion over the past few days

port states, time domains, …

etc.

 

and would have traps for loss of lock events.

 

There could also be protocol dependent parts, holding internals that may be needed.

 

Comments ?

 

Y(J)S

 

--_000_48E7911F78327A449A9FB9563766728642E91344exrad4adradcoil_-- From yaakov_s@rad.com Wed Mar 24 05:28:04 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3DD33A65A6 for ; Wed, 24 Mar 2010 05:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bYzi+V8ZcU9 for ; Wed, 24 Mar 2010 05:27:59 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id 358403A6359 for ; Wed, 24 Mar 2010 05:27:56 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 24 Mar 2010 14:28:15 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 24 Mar 2010 14:28:14 +0200 From: Yaakov Stein To: "Pietilainen, Antti (NSN - FI/Espoo)" , Greg Dowd Date: Wed, 24 Mar 2010 14:28:11 +0200 Thread-Topic: [TICTOC] Security and management of IEEE1588 (PTP) Thread-Index: AcrLTXd/PSL/2VA+T7SQ4rgApIshAA== Message-ID: <48E7911F78327A449A9FB9563766728642E9135B@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB9563766728642E9135Bexrad4adradcoil_" MIME-Version: 1.0 Cc: "tictoc@ietf.org" Subject: [TICTOC] Security and management of IEEE1588 (PTP) X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 12:28:04 -0000 --_000_48E7911F78327A449A9FB9563766728642E9135Bexrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > ITU-T Q13/SG15 has decided that management is out of scope of the PTP tel= ecom profile for the time being. > Telecom vendors have incorporated the management of packet timing into th= eir network management systems. So we can understand that this subject is not being handled by the ITU, and that if there is interest in the IETF community that there is no confli= ct of interest here ? That is reassuring. > I don't see that the telecom companies have done a mistake in standards w= ork that needs to be corrected by TICTOC. But the telecom companies is not the only community of interest here, in fact, it is probably not the main one. In addition, working on MIBs in particular is traditionally an IETF functio= n - you will note that even for many ITU defined protocols, the MIBs are done h= ere. > Surely it is possible to raise the management issue again in Q13 if neede= d. Of course, if we DO decide to work on this we would appreciate if Q13 would= consult with us first. Y(J)S --_000_48E7911F78327A449A9FB9563766728642E9135Bexrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> ITU-T Q13/SG15 has decided that management is = out of scope of the PTP telecom profile for the time being.

> Telecom vendors have incorporated the manageme= nt of packet timing into their network management systems.

 

So we can understand that this subject is not being handled by the ITU,

and that if there is interest in the IETF community= that there is no conflict of interest here ?

 

That is reassuring.

 

> I don't see that the telecom companies have do= ne a mistake in standards work that needs to be corrected by TICTOC. =

 

But the telecom companies is not the only community= of interest here,

in fact, it is probably not the main one.

 

In addition, working on MIBs in particular is traditionally an IETF function –

you will note that even for many ITU defined protoc= ols, the MIBs are done here.

 

> Surely it is possible to raise the management = issue again in Q13 if needed.

 

Of course, if we DO decide to work on this we would appreciate if Q13 would consult with us first.

 

Y(J)S

 

--_000_48E7911F78327A449A9FB9563766728642E9135Bexrad4adradcoil_-- From antti.pietilainen@nsn.com Wed Mar 24 07:06:14 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CA83A6A40 for ; Wed, 24 Mar 2010 07:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.761 X-Spam-Level: X-Spam-Status: No, score=0.761 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6F9hsM2N9eu for ; Wed, 24 Mar 2010 07:06:09 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D4F3A3A6A4E for ; Wed, 24 Mar 2010 07:06:02 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2OE6LQ7004292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Mar 2010 15:06:21 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2OE6JqW001907; Wed, 24 Mar 2010 15:06:20 +0100 Received: from FIESEXC014.nsn-intra.net ([10.159.0.22]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 15:06:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACB5B.2DA232FB" Date: Wed, 24 Mar 2010 16:06:19 +0200 Message-ID: In-Reply-To: <48E7911F78327A449A9FB9563766728642E9135B@exrad4.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] Security and management of IEEE1588 (PTP) Thread-Index: AcrLTXd/PSL/2VA+T7SQ4rgApIshAAACupMg References: <48E7911F78327A449A9FB9563766728642E9135B@exrad4.ad.rad.co.il> From: "Pietilainen, Antti (NSN - FI/Espoo)" To: "ext Yaakov Stein" , "Greg Dowd" X-OriginalArrivalTime: 24 Mar 2010 14:06:20.0451 (UTC) FILETIME=[2DCF6730:01CACB5B] Cc: tictoc@ietf.org Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP) X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 14:06:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACB5B.2DA232FB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaakov, My main worry is that TICTOC starts to define something and claim it is part of PTP telecom profile without the consent of Q13. Management of PTP is not necessarily out of scope of Q13 even if this is the case for the first version of telecom profile.=20 Best regards, Antti ________________________________ From: ext Yaakov Stein [mailto:yaakov_s@rad.com]=20 Sent: Wednesday, March 24, 2010 2:28 PM To: Pietilainen, Antti (NSN - FI/Espoo); Greg Dowd Cc: tictoc@ietf.org Subject: [TICTOC] Security and management of IEEE1588 (PTP) > ITU-T Q13/SG15 has decided that management is out of scope of the PTP telecom profile for the time being.=20 > Telecom vendors have incorporated the management of packet timing into their network management systems.=20 =20 So we can understand that this subject is not being handled by the ITU, and that if there is interest in the IETF community that there is no conflict of interest here ? =20 That is reassuring. =20 > I don't see that the telecom companies have done a mistake in standards work that needs to be corrected by TICTOC.=20 =20 But the telecom companies is not the only community of interest here, in fact, it is probably not the main one. =20 In addition, working on MIBs in particular is traditionally an IETF function - you will note that even for many ITU defined protocols, the MIBs are done here. =20 > Surely it is possible to raise the management issue again in Q13 if needed. =20 Of course, if we DO decide to work on this we would appreciate if Q13 would consult with us first. =20 Y(J)S =20 ------_=_NextPart_001_01CACB5B.2DA232FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Yaakov,
My=20 main worry is that TICTOC starts to define something and claim it is = part of PTP=20 telecom profile without the consent of Q13. Management of PTP is = not=20 necessarily out of scope of Q13 even if this is the case for the = first=20 version of telecom profile.
Best regards, Antti

From: ext Yaakov Stein = [mailto:yaakov_s@rad.com]=20
Sent: Wednesday, March 24, 2010 2:28 PM
To: = Pietilainen,=20 Antti (NSN - FI/Espoo); Greg Dowd
Cc:=20 tictoc@ietf.org
Subject: [TICTOC] Security and management of = IEEE1588=20 (PTP)

> ITU-T Q13/SG15 has decided that management = is out of=20 scope of the PTP telecom profile for the time being.

> Telecom vendors have incorporated the = management of=20 packet timing into their network management systems.

 

So we can understand that this subject is not = being=20 handled by the ITU,

and that if there is interest in the IETF = community that=20 there is no conflict of interest here ?

 

That is reassuring.

 

> I don't see that the telecom companies have = done a=20 mistake in standards work that needs to be corrected by TICTOC. =

 

But the telecom companies is not the only = community of=20 interest here,

in fact, it is probably not the main = one.

 

In addition, working on MIBs in particular is=20 traditionally an IETF function –

you will note that even for many ITU defined = protocols,=20 the MIBs are done here.

 

> Surely it is possible to raise the = management issue=20 again in Q13 if needed.

 

Of course, if we DO decide to work on this we = would=20 appreciate if Q13 would consult with us first.

 

Y(J)S

 

------_=_NextPart_001_01CACB5B.2DA232FB-- From David.T.Chen@motorola.com Wed Mar 24 09:26:00 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9C63A6A75 for ; Wed, 24 Mar 2010 09:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZGnzT2rvOrQ for ; Wed, 24 Mar 2010 09:25:59 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 5B9173A68F9 for ; Wed, 24 Mar 2010 09:25:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: David.T.Chen@motorola.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1269447976!22948644!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 1884 invoked from network); 24 Mar 2010 16:26:17 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-10.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Mar 2010 16:26:17 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o2OGQGgh014657 for ; Wed, 24 Mar 2010 09:26:16 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o2OGQGr5008721 for ; Wed, 24 Mar 2010 11:26:16 -0500 (CDT) Received: from de01exm71.ds.mot.com (de01exm71.am.mot.com [10.176.8.27]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o2OGQFtr008712 for ; Wed, 24 Mar 2010 11:26:15 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 12:25:53 -0400 Message-ID: <1788B3A69D2F54439B2A10D9D779063F065CC350@de01exm71.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [TICTOC] Security and management of IEEE1588 (PTP) thread-index: AcrLR+uvCEngY19aRS2PzfSxqK1VtwAJagWA From: "Chen David-QA5646" To: X-CFilter-Loop: Reflected Cc: tictoc@ietf.org Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP) X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:26:00 -0000 Hi! Antti: I have been monitoring the TICTOC activities for quite some time and I do not recall whether the apparent conflict between PTP TC (Transparent Clock) feature and the IPSEC for securing mobile backhaul. To implement PTP Transparent Clock, a network node needs to be able to identify the PTP packet (e.g., through a Protocol ID) and calculate its residence time. It then need to insert the residence time when the PTP packet exits the node. With IPSEC, PTP packet may not be able to be identified. I believe this issue must have been discussed in the past TICTOC meetings but I must have just overlooked it. Appreciate if you can provide some quick feedback on this very matter. Thanks and best regards, David David T. Chen, PhD Distinguished Member of Technical Staff Networks Advanced Technologies Enterprise Mobility Solutions and Networks Motorola Inc. +1-847-632-2664 David.T.Chen@motorola.com ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Mar 2010 13:48:10 +0200 From: "Pietilainen, Antti (NSN - FI/Espoo)" Subject: [TICTOC] Security and management of IEEE1588 (PTP) To: Cc: Greg Dowd Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Greg, I went through your presentations in the TICTOC meeting. The work items are valid. However, I would like to raise discussion of the suitable standards group in the case of telecom profiles of PTP. My viewpoint is a mobile network vendor's. Security Frequency synchronization without on-path support: 3GPP has specified the use of IPSEC for securing mobile backhaul if necessary. PTP can use the same IPSEC tunnels that are set up for the rest of the base station traffic. Thus, no new security methods are needed at least considering mobile backhaul. In the case of time synchronization with on-path support, if security-enabled, all PTP nodes need to authenticate their immediate neighbors in terms of synchronization. On the other hand, the data traffic rather needs end-to-end security, moreover with end-to-end encryption. Therefore, probably a separate security solution is needed for PTP. There is already an experimental annex in PTP, which covers security for PTP in general - i.e. not only for PTP/UDP/IP stack but also PTP/Ethernet stack. The solution has been verified by security experts of NIST. TICTOC should not declare itself as the owner of PTP security unless the timing community requests it. Management ITU-T Q13/SG15 has decided that management is out of scope of the PTP telecom profile for the time being. Telecom vendors have incorporated the management of packet timing into their network management systems. I don't see that the telecom companies have done a mistake in standards work that needs to be corrected by TICTOC. Surely it is possible to raise the management issue again in Q13 if needed. Conclusion I propose that the possible security & management work carried out in TICTOC would not concern telecom usage of PTP unless IETF and ITU decide together to do otherwise.=20 Best regards, Antti Antti Pietilainen Nokia Siemens Networks Mobile transport research Linnoitustie 6 02600 ESPOO Finland tel. +358-71-8036660 =20 ------------------------------ _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc End of TICTOC Digest, Vol 40, Issue 4 ************************************* From yaakov_s@rad.com Wed Mar 24 09:35:28 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB0C3A6BC9 for ; Wed, 24 Mar 2010 09:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[AWL=1.633, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NudNpEvnxXzX for ; Wed, 24 Mar 2010 09:35:24 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id 332483A6838 for ; Wed, 24 Mar 2010 09:35:18 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 24 Mar 2010 18:35:22 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 24 Mar 2010 18:35:22 +0200 From: Yaakov Stein To: "Pietilainen, Antti (NSN - FI/Espoo)" , Greg Dowd Date: Wed, 24 Mar 2010 18:35:18 +0200 Thread-Topic: [TICTOC] Security and management of IEEE1588 (PTP) Thread-Index: AcrLTXd/PSL/2VA+T7SQ4rgApIshAAACupMgAAXdnmA= Message-ID: <48E7911F78327A449A9FB9563766728642E91617@exrad4.ad.rad.co.il> References: <48E7911F78327A449A9FB9563766728642E9135B@exrad4.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB9563766728642E91617exrad4adradcoil_" MIME-Version: 1.0 Cc: "tictoc@ietf.org" Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP) X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:35:28 -0000 --_000_48E7911F78327A449A9FB9563766728642E91617exrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Antti TICTOC will not declare anything to be part of Q13's 1588 telecom profile. Y(J)S From: Pietilainen, Antti (NSN - FI/Espoo) [mailto:antti.pietilainen@nsn.com= ] Sent: Wednesday, March 24, 2010 16:06 To: Yaakov Stein; Greg Dowd Cc: tictoc@ietf.org Subject: RE: [TICTOC] Security and management of IEEE1588 (PTP) Hi Yaakov, My main worry is that TICTOC starts to define something and claim it is par= t of PTP telecom profile without the consent of Q13. Management of PTP is n= ot necessarily out of scope of Q13 even if this is the case for the first v= ersion of telecom profile. Best regards, Antti ________________________________ From: ext Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, March 24, 2010 2:28 PM To: Pietilainen, Antti (NSN - FI/Espoo); Greg Dowd Cc: tictoc@ietf.org Subject: [TICTOC] Security and management of IEEE1588 (PTP) > ITU-T Q13/SG15 has decided that management is out of scope of the PTP tel= ecom profile for the time being. > Telecom vendors have incorporated the management of packet timing into th= eir network management systems. So we can understand that this subject is not being handled by the ITU, and that if there is interest in the IETF community that there is no confli= ct of interest here ? That is reassuring. > I don't see that the telecom companies have done a mistake in standards w= ork that needs to be corrected by TICTOC. But the telecom companies is not the only community of interest here, in fact, it is probably not the main one. In addition, working on MIBs in particular is traditionally an IETF functio= n - you will note that even for many ITU defined protocols, the MIBs are done h= ere. > Surely it is possible to raise the management issue again in Q13 if neede= d. Of course, if we DO decide to work on this we would appreciate if Q13 would= consult with us first. Y(J)S --_000_48E7911F78327A449A9FB9563766728642E91617exrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Antti<= /p>

 =

TICTOC will not declare = anything to be part of Q13's 1588 telecom profile.

 =

Y(J)S<= /p>

 =

From: Pietilainen, = Antti (NSN - FI/Espoo) [mailto:antti.pietilainen@nsn.com]
Sent: Wednesday, March 24, 2010 16:06
To: Yaakov Stein; Greg Dowd
Cc: tictoc@ietf.org
Subject: RE: [TICTOC] Security and management of IEEE1588 (PTP)=

 

Hi Yaakov,

My main worry is that TICTOC starts to define something and cla= im it is part of PTP telecom profile without the consent of Q13. Management of PTP is not necessarily out of scope of Q13 even if this is the ca= se for the first version of telecom profile.

Best regards, Antti

 

From: ext Yaakov Stein [mailto:yaakov_s@rad.c= om]
Sent: Wednesday, March 24, 2010 2:28 PM
To: Pietilainen, Antti (NSN - FI/Espoo); Greg Dowd
Cc: tictoc@ietf.org
Subject: [TICTOC] Security and management of IEEE1588 (PTP)

> ITU-T Q13/SG15 has decided that management is = out of scope of the PTP telecom profile for the time being.

> Telecom vendors have incorporated the manageme= nt of packet timing into their network management systems.

 

So we can understand that this subject is not being handled by the ITU,

and that if there is interest in the IETF community= that there is no conflict of interest here ?

 

That is reassuring.

 

> I don't see that the telecom companies have do= ne a mistake in standards work that needs to be corrected by TICTOC. =

 

But the telecom companies is not the only community= of interest here,

in fact, it is probably not the main one.

 

In addition, working on MIBs in particular is traditionally an IETF function –

you will note that even for many ITU defined protoc= ols, the MIBs are done here.

 

> Surely it is possible to raise the management = issue again in Q13 if needed.

 

Of course, if we DO decide to work on this we would appreciate if Q13 would consult with us first.

 

Y(J)S

 

--_000_48E7911F78327A449A9FB9563766728642E91617exrad4adradcoil_-- From yaakov_s@rad.com Wed Mar 24 09:43:45 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E8D3A6C02 for ; Wed, 24 Mar 2010 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0VO-ftS4XGx for ; Wed, 24 Mar 2010 09:43:41 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id B035F3A6C15 for ; Wed, 24 Mar 2010 09:43:33 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 24 Mar 2010 18:43:52 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 24 Mar 2010 18:43:52 +0200 From: Yaakov Stein To: Chen David-QA5646 , "antti.pietilainen@nsn.com" Date: Wed, 24 Mar 2010 18:43:47 +0200 Thread-Topic: [TICTOC] Security and management of IEEE1588 (PTP) Thread-Index: AcrLR+uvCEngY19aRS2PzfSxqK1VtwAJagWAAACgZUA= Message-ID: <48E7911F78327A449A9FB9563766728642E91626@exrad4.ad.rad.co.il> References: <1788B3A69D2F54439B2A10D9D779063F065CC350@de01exm71.ds.mot.com> In-Reply-To: <1788B3A69D2F54439B2A10D9D779063F065CC350@de01exm71.ds.mot.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tictoc@ietf.org" Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP) X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:43:45 -0000 David This is yet another consequence of the layer violation inherent in TCs. Even without encryption, if the packet is modified on-the-fly=20 integrity assurance mechanisms will cause a TC-updated packet to be discard= ed. Of course, the packets may not even be identifiable due to encryption,=20 but were we to open and close encryption along the way the added delay and = jitter would become intolerable. =20 Furthermore, a true timing-specific security mechanism needs to=20 ensure that the traceability of the timing flow, i.e., not only authenticat= e the source, but check that the received packet took the expected path. Furthermore, security certificates have time of validity - but if the timin= g flow is bringing this time there is an obvious attack here that has to be handle= d. In past TICTOC meetings we have discussed some of these issues, none of which are addressed in any way by putting timing flows inside IPsec= . (In fact, I don't see any useful gain by doing that, but much harm.) Y(J)S -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Chen David-QA5646 Sent: Wednesday, March 24, 2010 18:26 To: antti.pietilainen@nsn.com Cc: tictoc@ietf.org Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP) Hi! Antti: I have been monitoring the TICTOC activities for quite some time and I do not recall whether the apparent conflict between PTP TC (Transparent Clock) feature and the IPSEC for securing mobile backhaul. To implement PTP Transparent Clock, a network node needs to be able to identify the PTP packet (e.g., through a Protocol ID) and calculate its residence time. It then need to insert the residence time when the PTP packet exits the node. With IPSEC, PTP packet may not be able to be identified. I believe this issue must have been discussed in the past TICTOC meetings but I must have just overlooked it. Appreciate if you can provide some quick feedback on this very matter. Thanks and best regards, David David T. Chen, PhD Distinguished Member of Technical Staff Networks Advanced Technologies Enterprise Mobility Solutions and Networks Motorola Inc. +1-847-632-2664 David.T.Chen@motorola.com ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Mar 2010 13:48:10 +0200 From: "Pietilainen, Antti (NSN - FI/Espoo)" Subject: [TICTOC] Security and management of IEEE1588 (PTP) To: Cc: Greg Dowd Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Greg, I went through your presentations in the TICTOC meeting. The work items are valid. However, I would like to raise discussion of the suitable standards group in the case of telecom profiles of PTP. My viewpoint is a mobile network vendor's. Security Frequency synchronization without on-path support: 3GPP has specified the use of IPSEC for securing mobile backhaul if necessary. PTP can use the same IPSEC tunnels that are set up for the rest of the base station traffic. Thus, no new security methods are needed at least considering mobile backhaul. In the case of time synchronization with on-path support, if security-enabled, all PTP nodes need to authenticate their immediate neighbors in terms of synchronization. On the other hand, the data traffic rather needs end-to-end security, moreover with end-to-end encryption. Therefore, probably a separate security solution is needed for PTP. There is already an experimental annex in PTP, which covers security for PTP in general - i.e. not only for PTP/UDP/IP stack but also PTP/Ethernet stack. The solution has been verified by security experts of NIST. TICTOC should not declare itself as the owner of PTP security unless the timing community requests it. Management ITU-T Q13/SG15 has decided that management is out of scope of the PTP telecom profile for the time being. Telecom vendors have incorporated the management of packet timing into their network management systems. I don't see that the telecom companies have done a mistake in standards work that needs to be corrected by TICTOC. Surely it is possible to raise the management issue again in Q13 if needed. Conclusion I propose that the possible security & management work carried out in TICTOC would not concern telecom usage of PTP unless IETF and ITU decide together to do otherwise.=20 Best regards, Antti Antti Pietilainen Nokia Siemens Networks Mobile transport research Linnoitustie 6 02600 ESPOO Finland tel. +358-71-8036660 =20 ------------------------------ _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc End of TICTOC Digest, Vol 40, Issue 4 ************************************* _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From antti.pietilainen@nsn.com Wed Mar 24 10:38:34 2010 Return-Path: X-Original-To: tictoc@core3.amsl.com Delivered-To: tictoc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F093A6C59 for ; Wed, 24 Mar 2010 10:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTwK9oV7NacX for ; Wed, 24 Mar 2010 10:38:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id DDF233A6C28 for ; Wed, 24 Mar 2010 10:38:31 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2OHcoqT027472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Mar 2010 18:38:50 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2OHcj8u029413; Wed, 24 Mar 2010 18:38:50 +0100 Received: from FIESEXC014.nsn-intra.net ([10.159.0.22]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 18:38:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 19:38:46 +0200 Message-ID: In-Reply-To: <1788B3A69D2F54439B2A10D9D779063F065CC350@de01exm71.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] Security and management of IEEE1588 (PTP) Thread-Index: AcrLR+uvCEngY19aRS2PzfSxqK1VtwAJagWAAAH3MKA= References: <1788B3A69D2F54439B2A10D9D779063F065CC350@de01exm71.ds.mot.com> From: "Pietilainen, Antti (NSN - FI/Espoo)" To: "ext Chen David-QA5646" X-OriginalArrivalTime: 24 Mar 2010 17:38:47.0755 (UTC) FILETIME=[DBCBA1B0:01CACB78] Cc: tictoc@ietf.org Subject: Re: [TICTOC] Security and management of IEEE1588 (PTP) X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:38:34 -0000 Hi David, In the 3GPP way of using IPSEC, the payload is encrypted. Thus, intermediate nodes cannot access the timing packet without decrypting all traffic in that IPSEC tunnel. The end-to-end security would be partly compromized if a large number of intermediate nodes would be authorized to decrypt the content. Some security mechanisms allow only the two endpoints participate in the encryption/decryption. Thus, maybe it is impossible to access the packets on the way. If the PTP packets are put in a separate IPSEC tunnel without encryption, then the time stamp fields could be changed without decryption. Regardless, the TCs need to be authenticated and they need to carry out key exchange so that they can change the correction field and the integrity check code to correspond to the new time value in the correction field. =20 In case of PTP TC and BC =20 -----Original Message----- From: ext Chen David-QA5646 [mailto:David.T.Chen@motorola.com]=20 Sent: Wednesday, March 24, 2010 6:26 PM To: Pietilainen, Antti (NSN - FI/Espoo) Cc: tictoc@ietf.org Subject: RE: [TICTOC] Security and management of IEEE1588 (PTP) Hi! Antti: I have been monitoring the TICTOC activities for quite some time and I do not recall whether the apparent conflict between PTP TC (Transparent Clock) feature and the IPSEC for securing mobile backhaul. To implement PTP Transparent Clock, a network node needs to be able to identify the PTP packet (e.g., through a Protocol ID) and calculate its residence time. It then need to insert the residence time when the PTP packet exits the node. With IPSEC, PTP packet may not be able to be identified. I believe this issue must have been discussed in the past TICTOC meetings but I must have just overlooked it. Appreciate if you can provide some quick feedback on this very matter. Thanks and best regards, David David T. Chen, PhD Distinguished Member of Technical Staff Networks Advanced Technologies Enterprise Mobility Solutions and Networks Motorola Inc. +1-847-632-2664 David.T.Chen@motorola.com ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Mar 2010 13:48:10 +0200 From: "Pietilainen, Antti (NSN - FI/Espoo)" Subject: [TICTOC] Security and management of IEEE1588 (PTP) To: Cc: Greg Dowd Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Greg, I went through your presentations in the TICTOC meeting. The work items are valid. However, I would like to raise discussion of the suitable standards group in the case of telecom profiles of PTP. My viewpoint is a mobile network vendor's. Security Frequency synchronization without on-path support: 3GPP has specified the use of IPSEC for securing mobile backhaul if necessary. PTP can use the same IPSEC tunnels that are set up for the rest of the base station traffic. Thus, no new security methods are needed at least considering mobile backhaul. In the case of time synchronization with on-path support, if security-enabled, all PTP nodes need to authenticate their immediate neighbors in terms of synchronization. On the other hand, the data traffic rather needs end-to-end security, moreover with end-to-end encryption. Therefore, probably a separate security solution is needed for PTP. There is already an experimental annex in PTP, which covers security for PTP in general - i.e. not only for PTP/UDP/IP stack but also PTP/Ethernet stack. The solution has been verified by security experts of NIST. TICTOC should not declare itself as the owner of PTP security unless the timing community requests it. Management ITU-T Q13/SG15 has decided that management is out of scope of the PTP telecom profile for the time being. Telecom vendors have incorporated the management of packet timing into their network management systems. I don't see that the telecom companies have done a mistake in standards work that needs to be corrected by TICTOC. Surely it is possible to raise the management issue again in Q13 if needed. Conclusion I propose that the possible security & management work carried out in TICTOC would not concern telecom usage of PTP unless IETF and ITU decide together to do otherwise.=20 Best regards, Antti Antti Pietilainen Nokia Siemens Networks Mobile transport research Linnoitustie 6 02600 ESPOO Finland tel. +358-71-8036660 =20 ------------------------------ _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc End of TICTOC Digest, Vol 40, Issue 4 ************************************* From wwwrun@core3.amsl.com Tue Mar 30 14:50:31 2010 Return-Path: X-Original-To: tictoc@ietf.org Delivered-To: tictoc@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 78BA13A6B2E; Tue, 30 Mar 2010 14:50:31 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: andrew.g.malis@verizon.com, matthew.bocci@alcatel-lucent.com, stbryant@cisco.com, yaakov_s@rad.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100330215031.78BA13A6B2E@core3.amsl.com> Date: Tue, 30 Mar 2010 14:50:31 -0700 (PDT) X-Mailman-Approved-At: Tue, 30 Mar 2010 23:12:01 -0700 Cc: tictoc@ietf.org, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, pwe3@ietf.org, yoichi.maeda@ntt-at.co.jp, rdroms.ietf@gmail.com, tsbsg15@itu.int, jean-loup.ferrant@calnexsol.com, paf@cisco.com, hiroshi.ota@itu.int, adrian.farrel@huawei.com Subject: [TICTOC] New Liaison Statement, "LS155 - ESMC frames in Synchronous Ethernet links" X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 21:50:31 -0000 Title: LS155 - ESMC frames in Synchronous Ethernet links Submission Date: 2010-03-30 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=860 Please reply by 2010-05-31 From: Greg Jones(ITU-T SG 15) To: IETF PWE3 and TICTOC(andrew.g.malis@verizon.com,matthew.bocci@alcatel-lucent.com,stbryant@cisco.com,yaakov_s@rad.com) Cc: paf@cisco.com jari.arkko@piuha.net rdroms.ietf@gmail.com adrian.farrel@huawei.com yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com pwe3@ietf.org tictoc@ietf.org Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: jean-loup.ferrant@calnexsol.com Purpose: For action Body: Attachment(s): LS155 - ESMC frames in Synchronous Ethernet links - pdf body (https://datatracker.ietf.org/documents/LIAISON/file973.pdf)