Last Call Review of draft-ietf-6lo-deadline-time-03

Request Review of draft-ietf-6lo-deadline-time
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-12-24
Requested 2018-12-10
Authors Lijo Thomas, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins
Draft last updated 2018-12-27
Completed reviews Iotdir Early review of -02 by Wesley Eddy (diff)
Rtgdir Telechat review of -03 by Dan Frost (diff)
Secdir Last Call review of -03 by Charlie Kaufman (diff)
Genart Last Call review of -03 by Dale Worley (diff)
Genart Telechat review of -04 by Dale Worley (diff)
Secdir Telechat review of -04 by Charlie Kaufman (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-6lo-deadline-time-03-secdir-lc-kaufman-2018-12-27
Reviewed rev. 03 (document currently at 05)
Review result Has Issues
Review completed: 2018-12-27


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document specifies a new optional extension in 6LoRHE headers to be used to do fine grained time tracking of packets traversing a network. It supports two functions: tracking the timing of transiting packets for the purpose of performance analysis and diagnostics, and delivery deadline enforcement where the source instructs the network to drop a packet if it cannot be delivered within a specified time bound. This avoids network congestion by quickly discarding packets that are going to be useless by the time they are delivered.

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

The issues raised below may be covered in companion documents, but they are what occurred to me while reviewing this one.

Security issues:

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.

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.

Non-security issues:

The length of the time fields is specified in the OTL and DTL headers to have a length of between 1 and 8 octets. I could not tell from the spec whether it was intended that the sender was supposed to pick a size big enough to represent the entire time field or whether it was OK to pick a smaller size and place the low order bits of the time in the field. Placing the low order bits there would normally work, though it makes size comparisons more complex (particularly in cases where there are just barely enough bits to avoid wrapping before the packet expires).

I was initially confused by the presence of two fields OT and DT when one should be sufficient to enforce packet expiration. Reading between the lines of the spec, 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.

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