Re: [manet] Tsvart last call review of draft-ietf-manet-dlep-pause-extension-06

Lou Berger <lberger@labn.net> Thu, 11 April 2019 00:42 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 D2BFD1205CF for <manet@ietfa.amsl.com>; Wed, 10 Apr 2019 17:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.554
X-Spam-Level:
X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, 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 fL_r5Da-omnT for <manet@ietfa.amsl.com>; Wed, 10 Apr 2019 17:42:29 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 7A1BD12046D for <manet@ietf.org>; Wed, 10 Apr 2019 17:42:27 -0700 (PDT)
Received: from CMGW (unknown [10.9.0.13]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 36D08176677 for <manet@ietf.org>; Wed, 10 Apr 2019 18:17:52 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id ENPchQIEteyBxENPchtE3W; Wed, 10 Apr 2019 18:17:52 -0600
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:From:References:Cc:To: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=6NAgBI4jHBO4TZQBzZIKq0sca4kh+gurfclgVzgsZV0=; b=jMIyYy30pHwaQIakDtnZMhiwry XGpbTotC42hYS5z9eb9Y8owvCBNYuNvZtzi5ot4GhgETaPb/d5pjXt7zAFkyhVIE4BIAUKtRHeeUZ NimycUYcSVjGMZXOJEyeEVfj7;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:48280 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 1hENPb-000OzO-QC; Wed, 10 Apr 2019 18:17:51 -0600
To: Bob Briscoe <ietf@bobbriscoe.net>, tsv-art@ietf.org
Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org
References: <155442219204.31004.18308454286183143947@ietfa.amsl.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <f5d1e0d8-0683-2c86-e9c3-2a20a72e42ae@labn.net>
Date: Wed, 10 Apr 2019 20:17:51 -0400
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: <155442219204.31004.18308454286183143947@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; 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: 1hENPb-000OzO-QC
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]:48280
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/-r-PBmoFqsaYc1GvCieekzqcGe0>
Subject: Re: [manet] Tsvart last call review of draft-ietf-manet-dlep-pause-extension-06
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, 11 Apr 2019 00:42:37 -0000

Bob,

Thanks for the comments - see below for responses.

On 4/4/2019 7:56 PM, Bob Briscoe via Datatracker wrote:
> Reviewer: Bob Briscoe
> Review result: On the Right Track
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>
> ==1. Introduction==
>
> It would be useful to describe the use-case where the modem does not implement
> active queue management but the router does, so the modem can use flow control
> to push the queue back into the router, where it can be more intelligently
> controlled.

I guess I'll have to talk to the Shepherd on this one to see how much 
he/the WG would want to add on this at this point.  Perhaps giving a 
reference to the earlier PPPOE (rfc5578) would suffice, what do you think?

>
> ===Scope within Intro===
> Please extend the single sentence about scope (end of 2nd para of Intro) to
> explain that pause control only applies to data in the router to modem
> direction.
>
> Please also mention that the scope of pause-based flow control is limited to
> one hop and to a point-to-point link between router and modem, not multipoint.
> The modem does not track the source of the data in its queue, so it cannot
> focus pause messages onto particular sending stations on a multipoint link, or
> onto particular ingress ports of the router.

Done.

>
> Why is the scope limited to DLEP radio links? I would have thought this
> protocol is generally useful between a and modem and router.

Because this is a DLEP extension.  Other mechanisms exist for other 
technologies, e.g., RFC5578 or Ethernet PAUSE/PFC.


> ==3. Extension Data Items==
>
> Pls define the direction of the messages:
> s/The xxx Data Item is used by a modem to.../
>   /A modem sends the xxx Data Item to its peer router to.../
okay (paraphrase a bit)
>
> ===Unsafe design?===
> Is it not good practice to make the data plane robust to unexpected control
> plane failures (e.g. key expiry, incorrect or mis-timed change of address,
> etc.) and vice versa? So, would it not be more robust for the router to
> time-out a pause if no restart appears? Also, if the last message received
> before shutting down or suspending was a pause, should the router restart or
> resume in the paused state? What if the router enters a power-saving state
> after it is paused and misses a restart message?

I generally agree that a control plane fault should not result in a data 
plane loss -- in some environments, I'd say this is a must.  This said, 
your comment goes to a design principle in DLEP RFC8175 where control 
plane error result in session resets and data plane impacts.  I think 
changing this basic behavior of DLEP is beyond the scope of this 
extension.  I think a general modification of base DLEP to support such 
would be a fine idea.

>
> ==Queue size in bytes for informational purposes?==
> Why? This strikes me as like one of those Government forms you have to fill in
> with an ill-formed question that is mandatory to answer, even though sometimes
> there is no answer, and you cannot proceed until you've answered, even though
> the answer is not needed anyway. For instance, if there is a shared physical
> buffer, a size cannot be straightforwardly given for each logical buffer. So,
> if buffer size info is not used by the protocol, do not include it in the
> protocol.
It is largely for reporting to a user/operator for "informational 
purposes".  If an implementation chooses, it can put in zero or 
infinity.  In most cases I understand this will be a straightforward 
value that can be reported to the router and its operators.
> On the other hand, how is the threshold at which the modem sends a pause
> configured. Is that out of scope? If so, where is it specified? Wherever this
> is specified, it should be possible to specify the threshold in time units
> (queue delay at the current service rate of the queue), not just in bytes. This
> is important for queues in a hierarchy where the service rate varies, e.g.
> dependent on traffic in another queue with priority over it. Or simply where
> the modem can operate at different rates.

I think a service rate / queue delay property would be very interesting 
- but this didn't come up in the WG, so I don't think it is appropriate 
to add it here.  There is also nothing preventing such information being 
added in a future extension.


>
> ==3.3 Restart==
>
>    "A router which receives the Restart Data Item SHOULD resume
>     transmission of the identified traffic to the modem."
>
> Why only SHOULD? Under what conditions would it not?

if it has no data to send. I don't object changing this to a MUST if you 
think important.

> ==4. Security Considerations==
>
>    "The extension does not inherently
>     introduce any additional vulnerabilities above those documented in
>     [RFC8175]."
>
> Er, no... What about the ability for an off-path attacker to stop the router
> sending data!?

the same attacker can subvert the dlep session an cause a session reset 
and take down all traffic.  So how is this case different?

> The last part about TLS needs to be worded differently. Because of the above
> additional vulnerability, the router MUST verify that all 3 types of message
> are authenticated by the modem. This requires client authentication mode of
> TLS, which is not mentioned in RFC8175, so it needs to be mentioned here.  Or
> is the TLS session set up by the router (so the modem is the authenticated
> server)? Also this raises the question of key management, if every modem has to
> be authenticated by its router.
>
>     "but this is not a
>     substantively different attack by such a compromised modem simply
>     dropping all traffic destined to, or sent by a router."
>
> Er, no... The modem does not need to be compromised for a 3rd party to send
> spoof messages purporting to be from the modem.

Fair point - how about:


   Note that this extension does allow a compromised or impersonating
   modem to suppress transmission by the router.  Similar attacks are
   generally possible base DLEP, for example an impersonating modem may
   cause a session reset or a compromised modem simply can
   drop all traffic destined to, or sent by a router.  <xref
   target="RFC8175"/> defines the use of TLS to protect against the
   impersonating attacker.


>
> ==Nits==
>
> 1. Intro
> "DLEP peers are comprised of a modem and a router" is incorrect English for
> what you mean (it means that each peer consists of a modem and a router).
> Better to do away with this sentence completely, and alter to the previous
> sentence to "It provides the exchange of link related control information
> between a modem and its DLEP peer router."

sure.


> 3.1
> s/with Queue Index/
>   /with a Queue Index/

okay

> Scale:
> s/An 4-bit/
>   /A 4-bit/
okay
> In general, I think the term "queue size" is wrongly being used where "buffer
> size" should be used (the queue size is the varying size of the queue within
> the buffer at any one time).
>
> Also, pls consistently use the term 'paused' not 'suppressed', which has the
> potentially ambiguous meaning of 'discarded'.

will clarify the intent.


> Delete gratuitous 'is':
>    "The motivating use case [is] for this
>     data item is when a modem's internal queue length exceeds a
>     particular threshold."
yes,
>
> CURRENT:
>    "e.g., when there
>     a non queue related congestion points within a modem, but such are
>     not explicitly described in this document."
> SUGGESTED:
>    "e.g., when there
>     are non queue related congestion points within a modem. Such use-cases are
>     not explicitly described in this document."
>
>
Done!

Thank you for the comments.

Lou

PS the working document has been updated, if interested see 
https://github.com/louberger/dlep-extensions/tree/master/pause

> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>