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

Lou Berger <lberger@labn.net> Fri, 08 March 2019 03:00 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 AC85A13126D for <manet@ietfa.amsl.com>; Thu, 7 Mar 2019 19:00:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.399
X-Spam-Level: **
X-Spam-Status: No, score=2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 H8F0aHbvP2Wq for <manet@ietfa.amsl.com>; Thu, 7 Mar 2019 19:00:14 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (outbound-ss-348.hostmonster.com [74.220.202.212]) (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 A64DA13126B for <manet@ietf.org>; Thu, 7 Mar 2019 19:00:14 -0800 (PST)
Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 4FE791E06C9 for <manet@ietf.org>; Thu, 7 Mar 2019 20:00:13 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 25k5hBzSRXFO525k5htjxt; Thu, 07 Mar 2019 20:00:13 -0700
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:References:Cc:To:From: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=tCkkU53IHhFVdYtIIFT1iBHqNv/16Y69AVI1nCFB14U=; b=dKYzSfe5GIRvnGsTA3uyJGB+AL BvVY/gJ0j/EyDmWvtAbg+j5eAGEYuCK8/gDIQHgz0hkWxSMOmRnpN73I/A93PNTEUJtBqPbb6qlks zkfXxgYe0vGYxcEayfzo+ts0e;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:53126 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 1h25k4-0023md-PS; Thu, 07 Mar 2019 20:00:12 -0700
From: Lou Berger <lberger@labn.net>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: MANET IETF <manet@ietf.org>
References: <mailman.572.1552013148.6143.manet@ietf.org> <7b9f9fe8-1ea3-b907-6654-6a049e701d19@labn.net>
Message-ID: <af06dc2a-6142-2852-0117-709bd8f0485a@labn.net>
Date: Thu, 7 Mar 2019 22:00:11 -0500
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: <7b9f9fe8-1ea3-b907-6654-6a049e701d19@labn.net>
Content-Type: text/plain; charset=windows-1252; 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: 1h25k4-0023md-PS
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]:53126
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/jjr7I5UxpP-AgxezLydWqioettk>
Subject: Re: [manet] Fwd: Re: 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: Fri, 08 Mar 2019 03:00:18 -0000

here's the commit with the new registry (see formatted link below for 
txt version)

https://github.com/louberger/dlep-extensions/commit/365a4c23ea1e62629b8129c90cb7d1c05f098214

On 3/7/2019 9:48 PM, Lou Berger wrote:
> apparently I made someone mad ;-)  See below for original message
>
>
>
> -------- Forwarded Message --------
> Subject: 	Re: [manet] AD Review of draft-ietf-manet-dlep-pause-extension-04
> Date: 	Thu, 07 Mar 2019 18:45:48 -0800
> From: 	manet-owner@ietf.org
> To: 	lberger@labn.net
>
>
>
> Message rejected by filter rule match
>
>
>
>
> -------- Forwarded Message --------
> Subject:     Re: [manet] AD Review of
> draft-ietf-manet-dlep-pause-extension-04
> Date:     Thu, 7 Mar 2019 21:45:37 -0500
> From:     Lou Berger <lberger@labn.net>
> To:     Alvaro Retana <aretana.ietf@gmail.com>om>,
> draft-ietf-manet-dlep-pause-extension@ietf.org
> <draft-ietf-manet-dlep-pause-extension@ietf.org>
> CC:     manet@ietf.org <manet@ietf.org>rg>, Rick Taylor
> <rick@tropicalstormsoftware.com>om>, Mobile Ad-hoc Networks Working Group
> <manet-chairs@ietf.org>
>
>
>
> Hi Alvaro/Rick,
>
>        Same apologies as the last message, see below.
>
> Also changes described in this message are posted at:
>
> https://github.com/louberger/dlep-extensions/commit/ab094b42b9d41f394ad002cef6058090ccdd9ce8
>
>
> and a formatted version at:
>
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/louberger/dlep-extensions/master/pause/draft-ietf-manet-dlep-pause-extension.xml
>
>
> On 2/12/2019 4:12 PM, Alvaro Retana wrote:
>   > Ping!
>   >
>   > Where are we with this document?  I haven’t seen related discussion to
>   > Rick’s point either.
>   >
>   > Alvaro.
>   >
>   > On November 17, 2018 at 5:13:26 AM, Rick Taylor (
>   > rick@tropicalstormsoftware.com) 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
>   > removed.
>   >
> The  Queue Parameters Data Item needs a list of objects semantic --
> having a consistent way of doing this facilitates reusable code.  I
> don't see any downside of the current definition.
>
>
>   >
>   > However, given the DiffServ Aware/CW drafts have almost caught up
> with the
>   > Pause extension, do the authors/WG want to rethink their intention?
>
> I think the current approach of having a DI-specific sub-DI format that
> happens to be common works just fine.  It's also cleaner that having a
> single sub-DI registry and track which sub-DIs are valid for which DIs.
>
> David has even shown that this works fine in code:
>
> https://github.com/mit-ll/LL-DLEP/commit/283b2f7618aeee1fcec606fdc7b4f659f300caaf
>
> so unless there's a strong reason to go back on the conclusions we came
> up with (in the WG) before, I don't think we should revisit the current
> sub-DI approach documented in the different drafts.
>
>   >
>   >
>   > 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?
>
> I believe we went back and forth on this as a WG (although I'll have to
> dig to find the discussion)  and agreed to not do this. At one time we
> discussed having a common sub-DI tyoe vale space for all DIs, I believe
> we agreed on having a common TLV format that is unique to each DI that
> wants to use a sub-DI.  This translates to DI unique sub-DI type
> namespace and allowing for future DIs to choose if they use the common
> sub-DI format or some other sub-di format.
>
>
>   >
>   >
>   >
>   > (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.
>   >
> done.
>
>
>   >
>   >
>   >
>   > ....
>   >
>   > 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?
>
> I think this is implementation specific, e.g., if more than one FC
> mechanisms is implemented the vendor may choose which is preferred.
>
>
>   >
>   >
>   >
>   >
>   > ....
>   >
>   > 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.]
> sure.
>   >
>   >
>   > [major] Please define a registry for the Sub Data Item Types to be used
>   > with the Queue Parameters Data Item.
>   >
> okay.
>
>
>   >
>   > 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.
>   >
> sure. Dropped Copying [RFC8175]
>   >
>   > 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
>   >
> Thanks!
>   >
>   > [minor] Pause and Restart reserve the Queue Index of 255 to indicate "all
>   > traffic", but that value is not reserved here.  Should it?
>   >
> I think this is covered by Num Queues = 1 and thereby no Queue Parameter
> Sub Data Item carried in the DI.
>
>   >
>   > ...
>   > 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.
> s/should equal/MUST
>   >
>   >
>   > ...
>   > 2863.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.
>   >
> okay s/MAY/MUST * 2
>   >
>   > ...
>   > 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.
>
> This is how DLEP handles errors in general.  I'm not sure that else
> should be done. Do you have an suggested alternative?
>
>
>   >
>   >
>   > ...
>   > 3473.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.
>   >
> same response: s/MAY/MUST * 2
>   > 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...
>   >
>   >
> I think leaving as is is more "liberal in what you accept"
>
>
>   > ...
>   > 3844. 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.
>   >
> A rogue modem can just drop all the traffic too, is this really
> substantive new vulnerability -  but sure, I can add a sentence.
>   > 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.
>   >
>   >
> Added
>
>
> <t>
>      Note that this extension does allow a compromised or impersonating
>      modem to suppress transmission by the router, but this is not a
>      substantively different threat by such a compromised modem simply
>      dropping all traffic destined to, or sent by a router. <xref
>      target="RFC8175"/> defines the use of TLS to protect against the
>      impersonating attacker.
> </t>
>
>   > ...
>   > 466Appendix A.  Acknowledgments
>   >
>   > 468  The sub data item format was inspired by Rick Taylor's "Data Item
>   > 469  Containers".
>   >
>   > [nit] Is this a draft?  Reference?
>
> I think just an idea/ discussion.
>
> Thanks again for the comments -- once we resolve these I'll push a new
> version.  (I'll also push one before the monday cutoff no matter what.)
>
> Lou
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>