Re: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04

Alvaro Retana <> Tue, 12 February 2019 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1E3212DF71; Tue, 12 Feb 2019 13:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.262
X-Spam-Level: ***
X-Spam-Status: No, score=3.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BQv8Me6d2eqF; Tue, 12 Feb 2019 13:12:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14FD1128B36; Tue, 12 Feb 2019 13:12:54 -0800 (PST)
Received: by with SMTP id 32so175348ota.12; Tue, 12 Feb 2019 13:12:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/FMAhz42wx/l+XiBg7ltEEyknSw/WSyJewbwnmBnJSI=; b=ouH8Sq+GeGi1RzTOmqAArzM4XyR3AMw6DonSS4d+oePM+UvOVZ08QUd56qqfSVtOSH 8mNCwdGp+xRHwEBK3z1T6wcl2IpanXdghP0qoWRWdxhwUcvQ7TMGmslA9Bxg/ZyqYGk2 /HA9vfwW1pvnkEJiJMrwaYbTgV9DsD3Y+yWYHRMqHJ+EKhntN+lMRrnVe3KkuXMLbD7q yxSKXguDOPeoI5mTi5+XQOhs7foCKukC2zp29wUQz39FbGRppiBz01/e9BM/aGgs+AlX XMhLrNk1YcGYYwf66CK5EuXV17v2tTVBZvUD0NmOyRspWeIcedZgJdjk62Sjl2rapFr6 MYAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/FMAhz42wx/l+XiBg7ltEEyknSw/WSyJewbwnmBnJSI=; b=Z8pnNda3wSGpDqxRJgc/QUCw5FRIItHUl9Si3fRP2/S7FmfvIEDvRrq3AeA7CP5yW0 hE++WDwk0XoVxpD5mJjqEk9NSo/NeTRvyINLyj+iPZsDd+1nznn9CtXsKl6ODfJBNLpf JKtE47xIIQwhWfFsMfuLbXH8Cvqi8OddEidWFJyCspHayFg6HW+b8zmdJU0fGbGEJKeX zqwL34wSBaDvn6UtMxxBT5+qMvW/Trxgi1tbSTnhcYb8PdyMGpZTQkovFQJJwesVKQPe ttn01w4sxdZRcAUTH9XS+S6wbefkgfFPHoT49Cu7zu/F5+4dGZbGehwLT1RLcxmtmP9b vgzQ==
X-Gm-Message-State: AHQUAuaJr2MnTnbzdAOYh+Yq+MEKex/XCKXtUX21K/a8aMkE9QYaZTIr dyutmLX+AMJjDm969f8PLHhViNddl1vEojZe4ujIhw==
X-Google-Smtp-Source: AHgI3IaGJTmzVyCyR4VYMKBfxr5xIxO6K/PYY3kSXzuc+1YpSivhf+Y8X/y+YFhTxU0Eur60gZE9IyvGf2KnTCkFUy0=
X-Received: by 2002:a9d:282:: with SMTP id 2mr5772541otl.287.1550005973011; Tue, 12 Feb 2019 13:12:53 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 12 Feb 2019 13:12:52 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Tue, 12 Feb 2019 13:12:52 -0800
Message-ID: <>
To: "" <>
Cc: "" <>, Rick Taylor <>, Mobile Ad-hoc Networks Working Group <>
Content-Type: multipart/alternative; boundary="0000000000006bd2c80581b8e3a7"
Archived-At: <>
Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Feb 2019 21:13:00 -0000


Where are we with this document?  I haven’t seen related discussion to
Rick’s point either.


On November 17, 2018 at 5:13:26 AM, Rick Taylor ( wrote:

(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

However, given the DiffServ Aware/CW drafts have almost caught up with the
Pause extension, do the authors/WG want to rethink their intention?



*From:* manet [] *On Behalf Of *Alvaro Retana
*Sent:* 16 November 2018 22:00
*Cc:*; 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

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



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

80         see [I-D.ietf-manet-credit-window].  The extension defined in


[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

108       Plane Based Pause Extension Type Value in the Extensions Supported

109       Data Item.  The Extensions Supported Data Item is sent and

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

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

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

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

247          item, excluding the Type and Length fields.

[minor] Copying?  As far as I can tell, rfc8175 doesn't define any sub data

249       Queue Index:

251          An 8-bit field indicating the queue index of the queue

252          represented in the sub data item.  Only the first instance a a

253          particular Queue Index value is meaningful.  Subsequent sub

254          items containing the same Queue Index values, if present, MAY

255          logged via a management interface and MUST otherwise be

[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

295       use device wide indications is when output queues are shared

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

299       Update Message.  To indicate that suppression applies to a

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

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

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

355       previous section, and follows the same rules.  This includes that

356       indicate that transmission can resume to all destinations, a modem

357       MAY send the Restart Data Item in a Session Update Message.  It

358       includes that to indicate that transmission can resume to a

359       particular destination a modem MAY send the Pause Restart Item in

360       Destination Update Message.  Finally, the same rules apply to

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

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

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