Benjamin Kaduk's No Objection on draft-ietf-bfd-multipoint-active-tail-09: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Mon, 02 July 2018 20:34 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: rtg-bfd@ietf.org
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 441821312CA; Mon, 2 Jul 2018 13:34:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bfd-multipoint-active-tail@ietf.org, Reshad Rahman <rrahman@cisco.com>, bfd-chairs@ietf.org, rrahman@cisco.com, rtg-bfd@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-bfd-multipoint-active-tail-09: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153056369226.16131.1820577378221314886.idtracker@ietfa.amsl.com>
Date: Mon, 02 Jul 2018 13:34:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Y57st_AlLL4-gYsfwGzlzqBjUiU>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.26
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jul 2018 20:35:01 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-bfd-multipoint-active-tail-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the clear explanations throughout; they made this document pretty easy to read. When the head sends both a multipoint poll and a unicast poll, does the MultipointClient session have a way to tell whether a received reply is replying to the multipoint message or the unicast one? For variables that "MUST be initialized based on configuration", do we need to provide a default value? Section 4 A head may wish to be alerted to the tails' connectivity (or lack thereof), there are a number of options. This is a comma splice and should be reworded. Section 5.1 [...] This mode emulates the behavior described in [I-D.ietf-bfd-multipoint]. In this mode for bfd.SessionType is MultipointTail, variable bfd.SilentTail (see Section 6.3.1) MUST be set to 1. nit: I think the "for" is spurious (and could maybe even be replaced by a comma)? The existing comma could be replaced by a semicolon or "and" to avoid a comma splice. Section 5.2 o if bfd.SessionType is MultipointTail, variable bfd.SilentTail (see Section 6.3.1) MUST be set to 0; nit: "the variable" Section 6.3.1 Few state variables are added in support of Multipoint BFD active tail. nit: "A few" bfd.UnicastRcvd Set to 1 if a tail receives a unicast BFD Control packet from the head. This variable MUST be set to zero if the session transitions from Up state to some other state. Is there ambiguity about "the session" being MultipointHead/MultipointTail vs. MultipointClient/MultipointTail (i.e., multipoint or unicast)? Section 6.4 If the head wishes to request a notification from the tails when they lose connectivity, it sets bfd.ReportTailDown to 1 in either the MultipointHead session (if such notification is desired from all tails) or in the MultipointClient session (if notification is desired from a particular tail). Note that the setting of this variable in a MultipointClient session for a particular tail overrides the setting in the MultipointHead session. It seems like this property (MultipointClient overrides MultipointHead) is fairly general and would apply to other variables as well. Should it be stated in a more general location? Section 6.7 When the tails send BFD Control packets to the head from the MultipointTail session, the contents of Your Discr (the discriminator received from the head) will not be sufficient for the head to demultiplex the packet, since the same value will be received from all tails on the multicast tree. In this case, the head MUST demultiplex packets based on the source address and the value of Your Discr, which together uniquely identify the tail and the multipoint path. I just want to double-check my understanding: is My Discr used at all for BFD Control messages from the tail to the head? Section 6.8 The value of Required Min Rx Interval received by a tail in a unicast BFD Control packet, if any, always takes precedence over the value received in Multipoint BFD Control packets. Do we need to scope this down to the "associated" sessions? (If so, probably someone should review the whole draft with an eye for it, as I have not done so.) Section 6.9, 6.10 In "If the head wishes to [...] session MAY send [...]", the 2119 MAY does not seem especially appropriate? Section 6.13.1 [...] In addition to that, if tail tracking is desired by the head, below procedure MUST be applied. nit: "the following procedure" Section 6.13.2 Do we need to say if this "addition" happens at the beginning or end of the bfd-multipoint procedure, or is it supposed to replace part of it, or what? Section 6.13.3 If bfd.SessionType value is MultipointTail and periodic the transmission of BFD Control packets is just starting (due to Demand mode not being active on the remote system), the first packet to be transmitted MUST be delayed by a random amount of time between zero and (0.9 * bfd.RemoteMinRxInterval). Should "periodic the" be "the periodic"? Also, this seems like a situation where cryptographic randomness is not required; it may be appropriate to note this. [...] A system MAY limit the rate at which such packets are transmitted. If rate limiting is in effect, the advertised value of Desired Min TX Interval MUST be greater than or equal to the interval between transmitted packets imposed by the rate limiting function. How does this MUST get enforced? Is it a matter of a software implementation refusing to allow local configuration to effect such behavior, or is it a global property of the system (e.g., that would require the administrator to enforce the MUST)? Contents of transmitted packet MUST be as explained in section 5.13.3 of [I-D.ietf-bfd-multipoint]. nit: There's a singular/plural mismatch here between "Contents" (plural) and "transmitted packet" (singular). Section 9 "infinite" is, well, infinite. Implementations that create MultipointClient sessions on demand need to have more reasonable expectations on prevention (the listed points do a better job than this text would indicate). As the rtgdir early review, the risk of spoofed packets causing tail-->MultpointClient traffic (including creation of MultipointClient sessions based on the received traffic) should probably be called out more directly. It seems like an attacker that can insert spoofed multipoint traffic would be able to effect some level of traffic amplification over time, though the jitter makes it harder to create large spikes. (Even on-path attacks are still worth documenting, IMO.) I see there was some conversation about the other security related points raised by that review, but on a quick read it seemed like maybe there was still some room to add more text to the security considerations.
- Benjamin Kaduk's No Objection on draft-ietf-bfd-m… Benjamin Kaduk
- Re: Benjamin Kaduk's No Objection on draft-ietf-b… Greg Mirsky
- Re: Benjamin Kaduk's No Objection on draft-ietf-b… Benjamin Kaduk