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

["Carles Gomez Montenegro" <[e-mail]>]

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.
>
>