Skip to main content

Telechat Review of draft-ietf-6lo-deadline-time-04
review-ietf-6lo-deadline-time-04-secdir-telechat-kaufman-2019-05-09-00

Request Review of draft-ietf-6lo-deadline-time
Requested revision No specific revision (document currently at 05)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2019-05-14
Requested 2019-04-25
Authors Lijo Thomas , Satish Anamalamudi , S.V.R Anand , Malati Hegde , Charles E. Perkins
I-D last updated 2024-05-28 (Latest revision 2019-07-08)
Completed reviews Iotdir Early review of -02 by Wesley Eddy (diff)
Rtgdir Telechat review of -03 by Dan Frost (diff)
Secdir IETF Last Call review of -03 by Charlie Kaufman (diff)
Genart IETF 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
Request Telechat review on draft-ietf-6lo-deadline-time by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/c5c4LUNYucngnocw-VtuxmvVAI4
Reviewed revision 04 (document currently at 05)
Result Ready
Completed 2019-05-09
review-ietf-6lo-deadline-time-04-secdir-telechat-kaufman-2019-05-09-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 header in the routing header of packets
carried over LLNs (Low Power and Lossy Networks). This new header specifies a
delivery deadline for packets, and the spec describes how a router is supposed
to modify the field when the packet crosses between synchronized time domains.

There really aren't any security implications to a feature like this, though
depending on how routers adjust their scheduling based on the values in this
field, there might be opportunities for network nodes to mount more effective
denial of service attacks or to get themselves better service than they might
be entitled to. Since this document does not specify the scheduling algorithms,
it's probably not appropriate for it to worry about possible weaknesses in
those algorithms.

 --Charlie

Sent from Outlook<http://aka.ms/weboutlook>