Skip to main content

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 revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-04-03
Requested 2019-03-14
Authors Bow-Nan Cheng , David Wiggins , Lou Berger
I-D 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 R. Worley (diff)
Tsvart Last Call review of -06 by Bob Briscoe (diff)
Assignment Reviewer Stephen Kent
State Completed
Request Last Call review on draft-ietf-manet-dlep-pause-extension by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 08)
Result Has nits
Completed 2019-03-20
review-ietf-manet-dlep-pause-extension-05-secdir-lc-kent-2019-03-20-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 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,  …”