Subject: Secdir last call review of draft-ietf-manet-dlep-pause-extension-05

From: Stephen Kent via Datatracker <[email-masked]>
Date: Wed, 20 Mar 2019 08:21:05 -0700

Reviewer: Stephen Kent
Review result: Has Nits

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,  …”