Eric Rescorla's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)
Eric Rescorla <ekr@rtfm.com> Tue, 03 July 2018 23:58 UTC
Return-Path: <ekr@rtfm.com>
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 21561130E6F; Tue, 3 Jul 2018 16:58:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: Reshad Rahman <rrahman@cisco.com>, draft-ietf-bfd-multipoint@ietf.org, rtg-bfd@ietf.org, rrahman@cisco.com, bfd-chairs@ietf.org
Subject: Eric Rescorla's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153066232212.5066.7110869726323868091.idtracker@ietfa.amsl.com>
Date: Tue, 03 Jul 2018 16:58:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/p02xnyPzyNnRz-BNN69wuw7CfWg>
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: Tue, 03 Jul 2018 23:58:43 -0000
Eric Rescorla has entered the following ballot position for draft-ietf-bfd-multipoint-18: 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3589 It's not entirely clear to me what the relationship is between this document and RFC5880. Can you clarify? How does this handle duplicate/reordered packets? If I am reading RFC 5880 correctly, you only get that if you have authentication? COMMENTS S 1. > > As multipoint transmissions are inherently unidirectional, this > mechanism purports only to verify this unidirectional connectivity. > Although this seems in conflict with the "Bidirectional" in BFD, the > protocol is capable of supporting this use case. Use of BFD in > Demand mode enables a tail monitor availability of a multipoint path enables a tail monitor -> allows a tail to monitor? If not, I am confused S 5.13.1. > If the Detect Mult field is zero, the packet MUST be discarded. > > If the My Discriminator field is zero, the packet MUST be > discarded. > > Demultiplex the packet to a session according to Section 5.13.2 This is a bit confusing because it applies to the section here and not in 5880. S 5.13.2. > PointToPoint MAY be created, or the packet MAY be discarded. > This choice MAY be controlled by a local policy and is > outside the scope of this specification. > > If the State field is Init and bfd.SessionType is not > PointToPoint, the packet MUST be discarded. Is this material just duplicative of 5880? S 6. > from the viewpoint of any other tail. For this reason, using shared > keys to authenticate BFD Control packets in multipoint scenarios is a > significant security exposure unless all tails can be trusted not to > spoof the head. Otherwise, asymmetric message authentication would > be needed, e.g., protocols that use Timed Efficient Stream Loss- > Tolerant Authentication (TESLA) as described in [RFC4082]. As Ben's review implies, digital signatures would be an appropriate thing to use here.
- Re: Eric Rescorla's No Objection on draft-ietf-bf… Eric Rescorla
- Eric Rescorla's No Objection on draft-ietf-bfd-mu… Eric Rescorla
- Re: Eric Rescorla's No Objection on draft-ietf-bf… Greg Mirsky