Re: [secdir] Secdir last call review of draft-ietf-manet-dlep-pause-extension-05

[Lou Berger <[e-mail]>]

Hi Steve,

Thanks for the comments!

On 3/20/2019 11:21 AM, Stephen Kent via Datatracker wrote:
> 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.

fair point, how about:

OLD:

   An example of when a modem might send
   this data item is when an internal queue length exceeds a particular
   threshold.

NEW:

The motivating use case is for this data item is when a modem's internal 
queue length exceeds a particular threshold.  Other use cases are 
possible, e.g., when there a non queue related congestion points within 
a modem, but such are not explicitly described in this document.


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

Hopefully these have already been corrected, if not I'm sure the editor 
will help us out.


> 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.”

Thanks.

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

I'm not sure thus is quite right, but will revise!

Thanks again!,

Lou

>
>