Skip to main content

Last Call Review of draft-ietf-6lo-deadline-time-03
review-ietf-6lo-deadline-time-03-secdir-lc-kaufman-2018-12-27-00

Request Review of draft-ietf-6lo-deadline-time
Requested revision 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 E. 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 R. Worley (diff)
Genart Telechat review of -04 by Dale R. 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 revision 03 (document currently at 05)
Result Has Issues
Completed 2018-12-27
review-ietf-6lo-deadline-time-03-secdir-lc-kaufman-2018-12-27-00
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.