Re: [secdir] Secdir review of draft-ietf-6lo-deadline-time-03

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Fri, 05 April 2019 14:39 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49138120453; Fri, 5 Apr 2019 07:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qukQ0gRfPLIl; Fri, 5 Apr 2019 07:39:16 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551ED12044F; Fri, 5 Apr 2019 07:39:16 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x35EdATh040340; Fri, 5 Apr 2019 16:39:10 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D3E401D53C1; Fri, 5 Apr 2019 16:39:09 +0200 (CEST)
Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Fri, 5 Apr 2019 16:39:10 +0200
Message-ID: <cc43146aea0ac0a0a09b66bb10dc3a4b.squirrel@webmail.entel.upc.edu>
In-Reply-To: <96b8684a-1319-7f89-8e1e-28e8bc154e55@earthlink.net>
References: <DM6PR04MB5099527AC26CD484D373FA09DFBB0@DM6PR04MB5099.namprd04.prod.outlook.com> <96b8684a-1319-7f89-8e1e-28e8bc154e55@earthlink.net>
Date: Fri, 5 Apr 2019 16:39:10 +0200
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: "Charlie Kaufman" <charliekaufman@outlook.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-6lo-deadline-time.all@ietf.org" <draft-ietf-6lo-deadline-time.all@ietf.org>, "Charlie Perkins" <charles.perkins@earthlink.net>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.2 at dash
X-Virus-Status: Clean
X-Greylist: Delayed for 00:04:02 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 05 Apr 2019 16:39:11 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/aNb_QMKxUmV4FUCzsT3_n0TF9qc>
Subject: Re: [secdir] Secdir review of draft-ietf-6lo-deadline-time-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2019 14:39:18 -0000

Dear Charlie Kaufman,

Thanks for reviewing draft-ietf-6lo-deadline-time-03.

Authors of draft-ietf-6lo-deadline-time recently produced revision -04 of
the draft, based on a number of comments received, including yours:
https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

Do you think -04 satisfies your previous concerns?

Thanks,

Shwetha and Carles (6lo co-chairs)




> Hello Charlie K.,
>
>
> Thanks for your review and comments.  I have made some follow-up
> interspersed with your comments below.
>
>
> On 12/23/2018 8:08 PM, Charlie Kaufman wrote:
>>
>> ...
>>
>> One of the challenges facing this design is maintaining tight clock
>> synchronization between packet forwarding devices. The design assumes
>> that sets of such devices are held in tight synchronization through
>> unspecified mechanisms. These groupings are called "time zones". It
>> also calls for the origination time and delivery deadline fields be
>> updated when a packet transitions between "time zones" (which assumes
>> that packet forwarding devices on separating two time zones be aware
>> of the time difference between them so that it can update those fields).
>>
>
> I think the intention was to obey transitions between time zones as we
> usually think of them (Pacific, Central European, etc.). The border
> routers could be expected to have the timezone information configured.
>
>
>>
>>
>> Section 6 specifies that when one of these packets is encapsulated and
>> sent through an IPv6 in IPv6 tunnel, and tunnel exit the time fields
>> must be copied from the outer header to the inner header before the
>> packet is forwarded on. This would be true of any form of
>> encapsulation, in particular including IPsec tunnelling.
>>
>
> Would it be O.K. if we simply deleted "IPv6-in-IPv6" from that sentence?
>
>
>>
>> Many time synchronization protocols - particularly those that target
>> subsecond synchronization - assume they are running on a secure
>> network (or that attackers would not be motivated to mess up time
>> synchronization). If the time synchronization between the packet
>> forwarding devices were to be broken such that there was substantial
>> drift between the devices, that could be used as a denial of service
>> attack if that could be used to cause most or all data packets to be
>> discarded as expired.
>>
>
> I think that a lot of things go wrong if the synchronization between the
> networks is broken.  As mentioned in the document
> draft-ietf-ntp-packet-timestamps, we need to consider whether or not to
> include a new subsection about "Synchronization Aspects".
>
>
>>
>>
>> ... I eventually concluded that only the DT field was intended to be
>> used for this purpose and the OT field was intended to be used to
>> track delivery performance and is not used in the calculation of
>> packet lifetime. Assuming I have that right, it would be good if it
>> were more explicit in the document.
>>
>
> Thanks for this feedback; we will find a way to make the distinction
> more explicit.
>
>
>>
>> The bit bummer in me was offended by the fact that the TU and EXP
>> fields had two different ways of representing 1 second time
>> granularity (TU=00/EXP=110 and TU=01/EXP=000). Given that time
>> granularity greater than 10 seconds is never likely to be needed, the
>> need for the TU=01 code point is questionable, but at the least
>> perhaps the spec should say which is the preferred encoding.
>>
>
> We are going to rework the time representation to be in accordance with
> the abovementioned document draft-ietf-ntp-packet-timestamps.  I think
> this will resolve the concern you have raised.
>
>
>
>> I also could not tell whether the encoding was expected to be constant
>> within a Time Zone (in which case the fields would not be necessary in
>> every packet) or whether packet relay nodes were expected to
>> canonicalize the time representation whenever it parses a packet. But
>> this is only a matter of taste.
>>
>
> I have always thought that the encoding would be constant from end to
> end.  We should have also made that explicit.  Do you think there is a
> good reason to allow the encoding to be chosen on a hop-by-hop basis?
>
>
> Thanks again!
>
>
> Regards,
> Charlie P.
>
>