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 | |
| Draft last updated | 2019-05-09 | |
| 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-04-secdir-telechat-kaufman-2019-05-09
|
|
| 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>