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, 04 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 > >> >> >
- [manet] Secdir last call review of draft-ietf-man… Stephen Kent via Datatracker
- Re: [manet] Secdir last call review of draft-ietf… Lou Berger
- Re: [manet] Secdir last call review of draft-ietf… Stephen Kent