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

Stephen Kent <stkent@verizon.net> Thu, 04 April 2019 22:28 UTC

Return-Path: <stkent@verizon.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 B06C5120048 for <manet@ietfa.amsl.com>; Thu, 4 Apr 2019 15:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.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 TmUwRWqPgQnQ for <manet@ietfa.amsl.com>; Thu, 4 Apr 2019 15:28:32 -0700 (PDT)
Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8152F120179 for <manet@ietf.org>; Thu, 4 Apr 2019 15:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1554416910; bh=TmRiOX1o/uQV709xKtrGLJC88mrYETublN77xx0V6i4=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=dz/Jd+cioMuQYiPWPok3yJcuMNNK3N8nGHApROxeIP7WPSj2wPz7SbUjVLjT4KY+o7U4s93127+v9dkwAVbrrouW5HG7zN7KsC9tZNfE2OBk99XVMLckDT/ZHGbkMF306ElHQxBZQKYLHGFAvdy79PQUEJT9KdNALviRo45yNmS6bSqq3lK5OkpS6dk54v4WKbAAtSwMUwEBXpFh1ehA6ujxtxkLlwV5Fc+kCQklNCkLa8Diu+mj5BG70ObiFI3ysIdNC+/infqg+7rlFNH2EYXDTJh8GuAl2zPTDCcm/m6upU0VaIHOu9z0W+CcmcCXNZ9fJQL2HnIHYHaOn4/6bA==
X-YMail-OSG: MBxwPmcVM1nQRhYlomroMvXNOd53BfmCv7B7FmqdDili0BzKN8.fKTI1lWqJBSQ _AmYGrd2p.izlcrzonNjziVCZi0Dqz.0yNJMh6ET55cd5iEfAy3SobvxnISbWzoBGoPkWfPU3zh_ 5wl09sfkKoxWA10rR6IvGxKrmQV0juc2Xa..Jq8OwdXs3Ik.KMHB_cbO8rK6uY7Oz.2cvWBsWQMc snJPLfl1YUiD007naU.NLreizu5dOt9XnQwFj4kKLKdHN1PemZZGBkdn8jH2SIDgi_np3hO4jl2F s7SRD.u1kd7hAorxhgQ0zfsoNKCLnrOwL_DYACcM_9IkbfV3TkyVrzj2XffP7HEc0vFgrXrERrP4 y9WH9puXJon5p7RG2kwxcqZDd685.mEiYDTZwDSFWm8N3q_au7SHsz3BOn.EXLaPqlFfA8Zojuce cIqSV5hAiED6h6Xm1RKcA.kzeydPIl2B36xo6IipHaosPRp9nGx06C4bOoz6WljIc9ZjtbJSccLU 9O_FOOlYFjNtWTVrGN0Kl9gjG.185.U4aR9WzeIlFHT0GSqPfot5yrQr9HokUUblxvCjR6jYH96h XgMu7qlwoVk8ZxMWF6Wrj9_TvVuBzoO2UdbbmXSD8qn5.NzoB8ML.vp7rbTVQlbB1NCswKlHWOBP XkiPctnFPoPqO9EJsXjeyUr79D610DVOPTkRRjdC0UN3yQ16v1jQenTD4Y3DuWesWTDiCOUkaabW Xn9hQc5hZHzGNZ9D1CCaLOAM_pQFQ9ATVicjOvCm0NSLL11tfb4cc2In6pfYuevwSBFmiekHk6UB FsCo5djXVDcVijMt_GnwC1N_zFyxyi_q.vncgVUJNCiJTwkj1Qp69ny2pifmS2IdPUpBuzB3u0_h I70XAkLtDlRcK8BzzvbvQbRzsMQIvES3cMjoKiXQjaHFnfOefbs01QWjEDVt1aaLENCtQpspvHF1 MwLJnSbKjSkL.TZ_0GPwrL_v1pxoPE6ZDFC4uvR5Qq0WuLJ_LbqAJHGCwkikYPFe0pf4oleUB7tS mrjxAKJrltip6H9as57Erj1lGVvwPvzF11muPGDuovxX_Ywbf8GVh.8AFa.u8tHTQEJ6zO_tLP7z Src1P8wuA9gGfzY5CMl_u
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Apr 2019 22:28:30 +0000
Received: from 192.40.225.130 (EHLO Steves-MacBook-Pro.local) ([192.40.225.130]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ef3da3371e5c72119df3c3879322e470; Thu, 04 Apr 2019 22:28:29 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: Lou Berger <lberger@labn.net>, 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> <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net>
Message-ID: <b3290d58-f2ac-0efc-3f4b-17dc5cc87d4b@verizon.net>
Date: Thu, 4 Apr 2019 15:28:12 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/8F6Sd_3nT-2ALcM0CpsWfelKkr4>
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: Thu, 04 Apr 2019 22:28:35 -0000

Lou,

Thanks for the quick reply. Your proposed edits look fine.

Steve


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