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
- Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-u… Zaheduzzaman Sarker via Datatracker
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Jeffrey Haas
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Reshad Rahman
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Zaheduzzaman Sarker
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Jeffrey Haas
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Zaheduzzaman Sarker
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Jeffrey Haas
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… John Scudder
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Zaheduzzaman Sarker
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Reshad Rahman
- Re: Zaheduzzaman Sarker's Discuss on draft-ietf-b… Reshad Rahman