Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Jeffrey Haas <jhaas@pfrc.org> Tue, 18 April 2023 15:57 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16E4C151B06; Tue, 18 Apr 2023 08:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 JWATbQBYoq55; Tue, 18 Apr 2023 08:57:24 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CCBC5C151543; Tue, 18 Apr 2023 08:57:23 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 6B8D21E039; Tue, 18 Apr 2023 11:57:22 -0400 (EDT)
Date: Tue, 18 Apr 2023 11:57:21 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
Cc: Reshad Rahman <reshad@yahoo.com>, The IESG <iesg@ietf.org>, "draft-ietf-bfd-unsolicited@ietf.org" <draft-ietf-bfd-unsolicited@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)
Message-ID: <20230418155721.GA20798@pfrc.org>
References: <167104636614.47387.14544637650303450586@ietfa.amsl.com> <20221215223922.GD23286@pfrc.org> <437097223.585815.1679885856359@mail.yahoo.com> <AM6PR07MB39920946F22521797E66B2B29F9C9@AM6PR07MB3992.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AM6PR07MB39920946F22521797E66B2B29F9C9@AM6PR07MB3992.eurprd07.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/CEq1RJqf_mjdsyV-YvoYAif1wIU>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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, 18 Apr 2023 15:57:25 -0000

Zahed,

Oddly enough, it appears that mail from ietf.org delivered one of the two
copies of mail from you in a corrupted form.  This message replies to the
missing piece of your question:

On Tue, Apr 18, 2023 at 12:44:13PM +0000, Zaheduzzaman Sarker wrote:
> > The environment must be under reasonable operational control to satisfy the
> > scaling of the impacted system.  What words would you prefer to have there
> > instead?  How would those words change if you want to permit this feature to
> > be utilized when the operational environment spans multiple entities, such
> > as at an exchange point (IXP)?
> 
> Calling it something else would not resolve the issue until that “something else” is we defined or described. I have no issue with calling it trustworthy when it is described well to that we can understand it, like you attribute it as – “The environment must be under reasonable operational control to satisfy the scaling of the impacted system”. I suggest we put some descriptive text to explain what is makes the environment trustworthy.

I don't believe that it will be possible to tersely state such a thing,
partially because BFD is simply one element in a deep stack of such
considerations.  As an example, unsecured ARP may be utilized in an IXP
environment.  You can do far more damage by spoofing ARP than you can in
BFD.  Same for discovery components like LLDP.

If you're looking for a particular term of art for such a trustworthy
environment where multiple potentially semi-trustworthy parties are
involved, we'll likely need to have such a thing supplied by current
security practitioners.

>From a general networking standpoint, some properties of such an environment
seem obvious: 
- The network element that can be attacked is expected to be attacked by a
  device one IP hop away. (See GTSM considerations in the draft.)
- Attackers must either be directly connected to the network element or on
  shared media with the network element, thus limiting the set of attackers.
- Layer 2 control mechanisms such as 802.1X may limit the viability of
  attackers to known parties.

In such circumstances, attackers in many circumstances are indistinguisable
from misconfigured or misbehaving parties.  When things go wrong, the IXP
operator will simply chase it down.  It's not like this would be the first
such malfunction.

Active attackers who are breaking into your racks just to mess with you
imply security issues far beyond the scope of this protocol extension.

-- Jeff