Re: [Tsv-art] [manet] Tsvart last call review of draft-ietf-manet-dlep-pause-extension-06
Lou Berger <lberger@labn.net> Thu, 11 April 2019 00:22 UTC
Return-Path: <lberger@labn.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334971200A0 for <tsv-art@ietfa.amsl.com>; Wed, 10 Apr 2019 17:22:22 -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 Dgcu_75EfwHT for <tsv-art@ietfa.amsl.com>; Wed, 10 Apr 2019 17:22:20 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 F3323120092 for <tsv-art@ietf.org>; Wed, 10 Apr 2019 17:22:19 -0700 (PDT)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 349A81421B7 for <tsv-art@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 ENPchssqTmds9ENPchZK03; Wed, 10 Apr 2019 18:17:52 -0600
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: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: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/0k5BcSilvIGSTz1XirPDXx_6P3U>
Subject: Re: [Tsv-art] [manet] Tsvart last call review of draft-ietf-manet-dlep-pause-extension-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 00:22:22 -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 >
- [Tsv-art] Tsvart last call review of draft-ietf-m… Bob Briscoe via Datatracker
- Re: [Tsv-art] [manet] Tsvart last call review of … Lou Berger
- Re: [Tsv-art] [manet] Tsvart last call review of … Justin Dean
- Re: [Tsv-art] [manet] Tsvart last call review of … Bob Briscoe