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

[Reshad Rahman <[e-mail]>]

 Thanks John and Zahed. I'm also good with the new text, will include it in the next rev.
    On Tuesday, April 18, 2023, 05:22:29 PM EDT, Zaheduzzaman Sarker <[e-mail]> wrote:  
 
 Thanks for the text suggestion. It is better now. Someone might of course ask what the business relation is, but I think I understand it better in this context.//ZahedFrom: John Scudder <[e-mail]>
Sent: Tuesday, April 18, 2023 6:15 PM
To: Jeffrey Haas <[e-mail]>; Zaheduzzaman Sarker <[e-mail]>
Cc: Reshad Rahman <[e-mail]>; The IESG <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT) Top-posting to avoid the nest of dueling quoting conventions :-( and since there’s only one residual point to settle.

I believe the draft text in question is:

OLD:
   *  Deploy the feature only in certain "trustworthy" environment,
      e.g., at an IXP, or between a provider and its customers.

Based on the conversation so far, let me throw out a suggestion for discussion.

NEW:
   *  Deploy the feature only in an environment that does not 
      offer anonymous participation. Examples include an IXP, 
      where the IXP operator will have a business relationship with 
      all IXP participants, or between a provider and its customers. 

Zahed, would that work for you?

Authors, any problems with that?

Thanks,

—John

> On Apr 18, 2023, at 11:57 AM, Jeffrey Haas <[e-mail]> wrote:
> 
> 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
>