Updated text is in rev-14.
Regards,Reshad.
- URL:
https://www.ietf.org/archive/id/draft-ietf-bfd-unsolicited-14.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited
Diff: Diff: draft-ietf-bfd-unsolicited-13.txt -
draft-ietf-bfd-unsolicited-14.txt
On Tuesday, April 18, 2023, 10:04:21 PM EDT, Reshad Rahman
<[email protected]> wrote:
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
<[email protected]> 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 <[email protected]>
Sent: Tuesday, April 18, 2023 6:15 PM
To: Jeffrey Haas <[email protected]>; Zaheduzzaman Sarker
<[email protected]>
Cc: Reshad Rahman <[email protected]>; The IESG <[email protected]>;
[email protected] <[email protected]>;
[email protected] <[email protected]>; [email protected] <[email protected]>
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 <[email protected]> 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
>
