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

"Carles Gomez Montenegro" <> Fri, 05 April 2019 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49138120453; Fri, 5 Apr 2019 07:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qukQ0gRfPLIl; Fri, 5 Apr 2019 07:39:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 551ED12044F; Fri, 5 Apr 2019 07:39:16 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x35EdATh040340; Fri, 5 Apr 2019 16:39:10 +0200
Received: from ( []) by (Postfix) with ESMTP id D3E401D53C1; Fri, 5 Apr 2019 16:39:09 +0200 (CEST)
Received: from by with HTTP; Fri, 5 Apr 2019 16:39:10 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <>
Date: Fri, 05 Apr 2019 16:39:10 +0200
From: Carles Gomez Montenegro <>
To: Charlie Kaufman <>
Cc: "" <>, "" <>, Charlie Perkins <>
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 ( []); Fri, 05 Apr 2019 16:39:11 +0200 (CEST)
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-6lo-deadline-time-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

Do you think -04 satisfies your previous concerns?


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.