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

Lou Berger <lberger@labn.net> Wed, 03 April 2019 22:07 UTC

Return-Path: <lberger@labn.net>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D3C120161 for <manet@ietfa.amsl.com>; Wed, 3 Apr 2019 15:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyx0Pv2yp3kO for <manet@ietfa.amsl.com>; Wed, 3 Apr 2019 15:07:01 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08261120168 for <manet@ietf.org>; Wed, 3 Apr 2019 15:07:00 -0700 (PDT)
Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 26383175B27 for <manet@ietf.org>; Wed, 3 Apr 2019 16:06:59 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id Bo26hASgJXFO5Bo26hovtG; Wed, 03 Apr 2019 16:06:59 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=EVFLSlff3169fHxVIx7BmZdbAN+X+HYRKuKOIht76G0=; b=w4hXRXVkZeAnSc7HaPU8kFhPcM TY5NDh+EUzt2RqHnMG9zEWByk/Hee7zoc9IjIKat8hdy2b2p2a2N5q2xFgz2S6txEFAZv1n50MJul GFV+Kk9rMGqx25U6sknVoP2Qp;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:47382 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1hBo26-000ow6-On; Wed, 03 Apr 2019 16:06:58 -0600
To: Stephen Kent <kent@alum.mit.edu>, secdir@ietf.org
Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org
References: <155309526492.14741.18141095676597911076@ietfa.amsl.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net>
Date: Wed, 3 Apr 2019 18:06:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <155309526492.14741.18141095676597911076@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1hBo26-000ow6-On
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:47382
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/nh2MMEjpyS5VuKttjLZf-PXNkYs>
Subject: Re: [manet] Secdir last call review of draft-ietf-manet-dlep-pause-extension-05
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 22:07:03 -0000

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

>
>