[RTG-DIR]Re: Rtgdir last call review of draft-ietf-bfd-unaffiliated-echo-11
Jeffrey Haas <jhaas@pfrc.org> Thu, 10 October 2024 23:54 UTC
Return-Path: <jhaas@pfrc.org>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E32C14F736; Thu, 10 Oct 2024 16:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRSx-BysPWUh; Thu, 10 Oct 2024 16:54:41 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 59DB5C14F714; Thu, 10 Oct 2024 16:54:41 -0700 (PDT)
Received: from smtpclient.apple (172-125-100-52.lightspeed.livnmi.sbcglobal.net [172.125.100.52]) by slice.pfrc.org (Postfix) with ESMTPSA id CBEAD1E039; Thu, 10 Oct 2024 19:54:40 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DF0A058E-ED39-4F09-BC50-AC0AFEFF8EBB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <20240927164429291JKZGq70YWoHfOOnwXeN4E@zte.com.cn>
Date: Thu, 10 Oct 2024 19:54:40 -0400
Message-Id: <9B34C344-4078-4619-9A76-49FC42504719@pfrc.org>
References: <172736023728.255075.16590213579223517326@dt-datatracker-6c75f7dfff-hrjh6> <20240927164429291JKZGq70YWoHfOOnwXeN4E@zte.com.cn>
To: adrian@olddog.co.uk, Xiao Min <xiao.min2@zte.com.cn>
X-Mailer: Apple Mail (2.3696.120.41.1.8)
Message-ID-Hash: PUJYGKHTE6G5HTE4GHASUKWGZKCOMMFS
X-Message-ID-Hash: PUJYGKHTE6G5HTE4GHASUKWGZKCOMMFS
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: rtg-dir@ietf.org, draft-ietf-bfd-unaffiliated-echo.all@ietf.org, last-call@ietf.org, BFD WG <rtg-bfd@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [RTG-DIR]Re: Rtgdir last call review of draft-ietf-bfd-unaffiliated-echo-11
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ps0rDnv6bcySqYdX6eKA7HXkDsM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>
> On Sep 27, 2024, at 4:44 AM, xiao.min2@zte.com.cn wrote: > > Section 4, question... > > Could an attacker interpose themselves between the two nodes and perform > loopback? Loopback is an easy function with no requirement to generate > any additional security, so it is easier than impersonating a full BFD > implementation. > [XM]>>> In theory it would happen, however in the real deployment I doubt it would happen. Currently we have two specific use cases of the Unaffiliated BFD Echo, one is between RG and IP Edge (as described in Section 6.2.2 of BBF TR-146), another one is between DC Gateway and VM of Server (as described in draft-wang-bfd-one-arm-use-case). For the two use cases it seems difficult for an attacker to interpose itself between the two nodes. > > As a potentially closing note, unaffiliated BFD PDUs require GTSM procedures validating the TTL. In order for such an attacker to interpose themselves in such a fashion, it would have to be an attacker that appears one IP hop away, typically an on-link attacker. In such a case, the attack is the expected destination being taken down but the BFD session being kept up. Unaffiliated BFD can't detect such imposters. BFD using one of the stronger authentications such as SHA-1 will have better resiliency against talking to such imposters. In scenarios where this is a concern, unaffiliated BFD should not be used. Even when stronger BFD authentication is in use, it shouldn't be used as a mechanism to try to provide application level authentication of the endpoints. -- Jeff
- [RTG-DIR]Rtgdir last call review of draft-ietf-bf… Adrian Farrel via Datatracker
- [RTG-DIR]Re: Rtgdir last call review of draft-iet… Eric Vyncke (evyncke)
- [RTG-DIR]Re: Rtgdir last call review of draft-iet… xiao.min2
- [RTG-DIR]Re: Rtgdir last call review of draft-iet… Jeffrey Haas