Re: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04
Rick Taylor <rick@tropicalstormsoftware.com> Sat, 17 November 2018 10:13 UTC
Return-Path: <rick@tropicalstormsoftware.com>
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 53C8F130DC9; Sat, 17 Nov 2018 02:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.1
X-Spam-Level: ***
X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 3-ujp7Wj7wvi; Sat, 17 Nov 2018 02:13:29 -0800 (PST)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A1D12008A; Sat, 17 Nov 2018 02:13:27 -0800 (PST)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0415.000; Sat, 17 Nov 2018 10:13:18 +0000
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-manet-dlep-pause-extension@ietf.org" <draft-ietf-manet-dlep-pause-extension@ietf.org>
CC: "manet@ietf.org" <manet@ietf.org>, Mobile Ad-hoc Networks Working Group <manet-chairs@ietf.org>
Thread-Topic: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04
Thread-Index: AQHUffe41avxCSxrIUqMn7Pbf9b0AqVTvosg
Date: Sat, 17 Nov 2018 10:13:18 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801E5557AFA@tss-server1.home.tropicalstormsoftware.com>
References: <CAMMESszBwRNbn2_gu6of-fKCToyHKafpnXUqPekOKqKnEz1Jbw@mail.gmail.com>
In-Reply-To: <CAMMESszBwRNbn2_gu6of-fKCToyHKafpnXUqPekOKqKnEz1Jbw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.5]
Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801E5557AFAtssserver1hom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/NW0btUs5uC58J0V4lg8y8CUY_Is>
Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04
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: Sat, 17 Nov 2018 10:13:32 -0000
(Sorry for the top post… damn outlook) Hi Authors, If I remember correctly – and there has been a bit of delay with this draft, with the CCAMP/not-CCAMP move – the intention of the authors was to make the pause extension simple and self-contained, avoiding getting caught up in the DiffServ Aware/Credit Window/Sub-TLV draft reference reorganization that has happened. If this is still the intention, then I agree with Alvaro that trying to define generic Sub-TLVs in this document is unnecessary, and should be removed. However, given the DiffServ Aware/CW drafts have almost caught up with the Pause extension, do the authors/WG want to rethink their intention? Cheers, Rick From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Alvaro Retana Sent: 16 November 2018 22:00 To: draft-ietf-manet-dlep-pause-extension@ietf.org Cc: manet@ietf.org; Mobile Ad-hoc Networks Working Group Subject: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04 Dear authors: I just finished reviewing this document. I have several comments (see below) and a couple of significant issues, which I'm mentioning in the next 2 bullets. I will wait for these to be addressed before starting the IETF LC. (1) This is a comment for the WG (not just the authors): This is the first draft that specifies a Sub Data Item. Given that rfc8175 says that the Value in a Data Item "contains data specific to a particular Data Item", I don't think it is necessary to define a generic DLEP Sub Data Item.. However, not all future extensions may follow the same model. Is there a need/interest in normatively specifying the characteristics of a Sub Data Item? (2) Security Considerations: The extension in itself doesn't change the security characteristics of DLEP, I agree with that. However, I think that the functionality does -- please see specific comments below. Thanks! Alvaro. [Line numbers from idnits.] ... 70 1. Introduction .... 78 The base DLEP specification does not include any data plane flow 79 control capability. Various flow control methods are possible, e.g., 80 see [I-D.ietf-manet-credit-window]. The extension defined in this ... [minor] A reference to something other than I-D.ietf-manet-credit-window (expired, etc.) may be more appropriate. ... 103 2. Extension Usage and Identification 105 The use of the Control Plane Based Pause Extension SHOULD be 106 configurable. To indicate that the Control Plane Based Pause 107 Extension is to be used, an implementation MUST include the Control 108 Plane Based Pause Extension Type Value in the Extensions Supported 109 Data Item. The Extensions Supported Data Item is sent and processed 110 according to [RFC8175]. [minor] "The use of the Control Plane Based Pause Extension SHOULD be configurable." Is there a default recommended configuration? ... 201 3.1.1. Queue Parameter Sub Data Item ... 234 Sub Data Item Type: 236 A 16-bit unsigned integer that indicates the type and 237 corresponding format of the Sub Data Item's Value field. Sub Data 238 Item Types are scoped within the Data Item in which they are 239 carried, i.e., the Sub Data Item Type field MUST be used together 240 with the Data Item Type to identify the format of the Sub Data 241 Item. This field MUST be set to one (1) for the Queue Parameter 242 Sub Data Item. [minor] "...the Sub Data Item Type field MUST be used together with the Data Item Type to identify the format of the Sub Data Item." It sounds as if this text wants to specify the behavior for *any* Sub Data Item Type. Please reword to be specific in to this document. [Also, see my note at the top.] [major] Please define a registry for the Sub Data Item Types to be used with the Queue Parameters Data Item. 244 Length: Variable 246 Copying [RFC8175], Length is the number of octets in the sub data 247 item, excluding the Type and Length fields. [minor] Copying? As far as I can tell, rfc8175 doesn't define any sub data items. 249 Queue Index: 251 An 8-bit field indicating the queue index of the queue parameter 252 represented in the sub data item. Only the first instance a a 253 particular Queue Index value is meaningful. Subsequent sub data 254 items containing the same Queue Index values, if present, MAY be 255 logged via a management interface and MUST otherwise be ignored. [nit] s/a a/of a [minor] Pause and Restart reserve the Queue Index of 255 to indicate "all traffic", but that value is not reserved here. Should it? ... 269 DS Field Qn: 271 The data item contains a sequence of 8 bit DS Fields. The 272 position in the sequence identifies the associated queue index. 273 The number of DS Fields present should equal the sum of all Num 274 DSCPs field values. [major] "should equal", or "MUST equal"? If the number of DS Fields doesn't add up, should the sub data item be considered invalid? I assume that would invalidate the whole data item. ... 286 3.2. Pause ... 293 A modem may indicate that traffic is to be suppressed on a device 294 wide or destination specific basis. An example of when a modem might 295 use device wide indications is when output queues are shared across 296 all destinations, and destination specific might be used when per 297 destination queuing is used. To indicate that suppression applies to 298 all destinations, a modem MAY send the Pause Data Item in a Session 299 Update Message. To indicate that suppression applies to a particular 300 destination a modem MAY send the Pause Data Item in a Destination 301 Update Message. [major] I think that the two MAYs above are out of place. I understand that sending the Pause Data Item in the corresponding Update Message is optional, but the sentences say that "To indicate that suppression applies...", which means that if the Pause Data Item is not sent, then there is no indication...so sending it is not optional. ... 312 A router which receives the Pause Data Item MUST cease sending the 313 identified traffic to the modem. This may of course translate into 314 the router's queues exceeding their own thresholds. If a received 315 Pause Data Item contains a Queue Index value other than 0, 255, or a 316 queue index established by a Session Initialization or Session Update 317 Message, the router MUST terminate the session with a Status Data 318 Item indicating Invalid Data. [major] Terminating the session seems drastic to me given that the wrong index relates to a single destination and the action has an impact over all. ... 347 3.3. Restart ... 354 The sending of this data item parallels the Pause Data Item, see the 355 previous section, and follows the same rules. This includes that to 356 indicate that transmission can resume to all destinations, a modem 357 MAY send the Restart Data Item in a Session Update Message. It also 358 includes that to indicate that transmission can resume to a 359 particular destination a modem MAY send the Pause Restart Item in a 360 Destination Update Message. Finally, the same rules apply to queue 361 indexes. [major] Same comment as above about the MAYs. 363 A router which receives the Restart Data Item SHOULD resume 364 transmission of the identified traffic to the modem. [minor] Should the Restart always follow a Pause? I think that is the intent. The question is whether it MUST happen that way? As is, the text leaves the possibility open for a modem to send a Restart without having sent a Pause. I think that is ok, just checking... ... 384 4. Security Considerations 386 The extension introduces a new mechanism for flow control between a 387 router and modem using the DLEP protocol. The extension does not 388 inherently introduce any additional threats above those documented in 389 [RFC8175]. The approach taken to Security in that document applies 390 equally when running the extension defined in this document. [major] The extension gives the modem the ability to stop the traffic sent by a router.. A rogue or compromised modem could stop traffic sent by the attached router. Protecting the modem is out of scope, but I think the threat should at least be pointed out. rfc8175 already mentions the risk that "an attacker might pretend to be a DLEP participant...by injection of DLEP Messages once a session has been established", which is related to this case. However, I think that the point still needs to be called out specifically because of the new functionality introduced. ... 466 Appendix A. Acknowledgments 468 The sub data item format was inspired by Rick Taylor's "Data Item 469 Containers". [nit] Is this a draft? Reference?
- [manet] AD Review of draft-ietf-manet-dlep-pause-… Alvaro Retana
- Re: [manet] AD Review of draft-ietf-manet-dlep-pa… Rick Taylor
- Re: [manet] AD Review of draft-ietf-manet-dlep-pa… Alvaro Retana
- [manet] Fwd: Re: AD Review of draft-ietf-manet-dl… Lou Berger
- Re: [manet] Fwd: Re: AD Review of draft-ietf-mane… Lou Berger
- Re: [manet] AD Review of draft-ietf-manet-dlep-pa… Alvaro Retana
- Re: [manet] AD Review of draft-ietf-manet-dlep-pa… Lou Berger