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

[Charlie Perkins <[e-mail]>]

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.