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

Lou Berger <lberger@labn.net> Fri, 08 March 2019 02:48 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 E025D13125B for <manet@ietfa.amsl.com>; Thu, 7 Mar 2019 18:48:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, 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 0Mppr2OMN-c5 for <manet@ietfa.amsl.com>; Thu, 7 Mar 2019 18:48:44 -0800 (PST)
Received: from outbound-ss-879.bluehost.com (outbound-ss-879.bluehost.com [69.89.30.202]) (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 00032131106 for <manet@ietf.org>; Thu, 7 Mar 2019 18:48:43 -0800 (PST)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id BE4051E07FE for <manet@ietf.org>; Thu, 7 Mar 2019 19:48:43 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 25YxhziwsD8Rp25YxhMW60; Thu, 07 Mar 2019 19:48:43 -0700
X-Authority-Reason: nr=8
X-Authority-Analysis: $(_cmae_reason
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:From:Cc:To:References: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=ZzaH93VPJA3CMpc5rFcQx1D9ITVsX4camwp+Rn5TiPw=; b=XxDmblNj2r8qIJlBOnmlR59lmW LanR+jxIjT3RHe3r6LueTvRdlytc3takhTkU029O8JKf0YNmGjRmJOwzLDXeQz1/yLTIazV4KlKbw 4JYovB05Q5qKRu/V7SLj7vtfd;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:52038 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 1h25Yx-0020aW-5M; Thu, 07 Mar 2019 19:48:43 -0700
References: <mailman.572.1552013148.6143.manet@ietf.org>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: MANET IETF <manet@ietf.org>, Rick Taylor <rick@tropicalstormsoftware.com>
From: Lou Berger <lberger@labn.net>
X-Forwarded-Message-Id: <mailman.572.1552013148.6143.manet@ietf.org>
Message-ID: <7b9f9fe8-1ea3-b907-6654-6a049e701d19@labn.net>
Date: Thu, 7 Mar 2019 21:48:41 -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: <mailman.572.1552013148.6143.manet@ietf.org>
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: 1h25Yx-0020aW-5M
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]:52038
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/wDB9ArBbErMqGby79mjknIywz4s>
Subject: [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 02:48:46 -0000

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