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

Charlie Perkins <> Sun, 10 February 2019 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AA69128CF2; Sun, 10 Feb 2019 11:23:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key); domainkeys=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NK3tYqQLvX5Q; Sun, 10 Feb 2019 11:23:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B96FC126C15; Sun, 10 Feb 2019 11:23:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dk12062016; t=1549826619; bh=ZcTQZjeFQ6q3ALM+X7rOt72ZvJPz8rhLPCd0 zGRso8o=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=Z17BviYMvVWL7nv8yzemkSU8+TvAo5MC8 ZhEfLtwfTqa2qqxx7QohtC1w8xYOOvHI9JabOydfX/zg6BX1R4OcVuAZsL5pDgcPCr1 RzK5vFo7wIx0kqOBbGq0VAF9/vze5GP2b7ZX6AAd4lvvT2Y/heRdkvOXhlis1z5Pi+U NNzOEVbRik1btPL0ftKcim22S2oFjmFetd58RcCcXRo7JPciiUDeqPnkeGWWgok9nMd XXznalrgEzOoawU78fxoAgTswR1WjQd6skypF/axsawdFUwYu8uE1AieNPKMLlSKjim 7L2iPzFQQpK8vR+il3yFjP+dtSRURgEEvK/tF8n9Q==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016;; b=Z4UBkE4qqz/3tgyDLv1VzCakv+iuGwblLcsEwjMyjlmU01Gg8slp/FrartCWE6BxG/EQdG/CR9vvJjcrCGEu7kohkqQbgDhycbSs87S5757HNLuBmiSmn7Bm2beFKRw28oYHZlr4PrfTRU1+4lyWZ6jXxG1eDY+zy1j5HKRawMFt/raShxvz5P0ZrJUAM9vEXQcSnc5D7luMIN+yqgMHsmLaFtzPrD+nZrxrQkYDauGegzhvaQyG5m53B4CK1EKSNYf75cTVIFNplwboweaAfCe7CDl/KZQUTqQCrN5vcGJw0w8czFkjRzAkxPjfFctakFC8qP8lufagvft9ufchkw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <>) id 1gsuhV-00046Q-66; Sun, 10 Feb 2019 14:23:37 -0500
To: Charlie Kaufman <>, "" <>, "" <>, "" <>
References: <>
From: Charlie Perkins <>
Message-ID: <>
Date: Sun, 10 Feb 2019 11:23:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------1B31471C5593DF9BA0EA6D53"
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c953b9a430e6c29e61fa5f08993193ad228350badd9bab72f9c350badd9bab72f9c
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: Sun, 10 Feb 2019 19:23:42 -0000

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!

Charlie P.