Last Call Review of draft-ietf-manet-dlep-pause-extension-05
review-ietf-manet-dlep-pause-extension-05-secdir-lc-kent-2019-03-20-00

Request Review of draft-ietf-manet-dlep-pause-extension
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-04-03
Requested 2019-03-14
Draft last updated 2019-03-20
Completed reviews Rtgdir Last Call review of -05 by Andy Smith (diff)
Secdir Last Call review of -05 by Stephen Kent (diff)
Genart Last Call review of -05 by Dale Worley (diff)
Tsvart Last Call review of -06 by Bob Briscoe (diff)
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-manet-dlep-pause-extension-05-secdir-lc-kent-2019-03-20
Reviewed rev. 05 (document currently at 08)
Review result Has Nits
Review completed: 2019-03-20

Review
review-ietf-manet-dlep-pause-extension-05-secdir-lc-kent-2019-03-20

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 with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Review Summary: Ready with nits

This brief document defines and extension to DLEP That enables a modem to use DLEP to pause and resume inbound traffic from a specific peer. DLEP (RFC 8175) cites GTSM as a security mechanism, which is rather weak, but it says that implementations SHOULD use TLS (1.2), which is fine. 

The text states that “An example of when a modem might send this data item is when an internal queue length exceeds a particular threshold.” However, all of details of this data item seem to focus exclusively on queues. Thus it seems likely that this is not just an example, but, rather, the primary motivation for introducing the pause extension. A slight rewording of the text here seems appropriate, or the authors could describe other (not-queue-based) examples.

The Security Considerations section of 8175 addresses a reasonable range of concerns. Thus it is appropriate that this document’s Security Considerations section is very brief, as it cites the corresponding section in 8175. I suggest a couple of minor change to the wording here:

“The extension does not inherently introduce any additional threats …
->
“The extension does not inherently introduce any additional vulnerabilities …”

“ …  but this is not a substantively different threat by …”
->
“ …  but this is not a substantively different attack by …”


There are numerous examples of awkward/poor phrasing throughout the document, which I hope the RFC Editor will correct, e.g., 

Abstract:
	“…to the DLEP protocol …” -> “… to DLEP …”

page 7:

“A modem can indicate that traffic is to be suppressed on a device    wide or destination specific basis.”

“A modem can indicate that traffic is to be suppressed on a device-   wide or destination-specific basis.”

“This includes that to indicate that transmission can resume to all destinations  …”

“Thus, to indicate that transmission can resume to all destinations,  …”