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

[Reshad Rahman <[e-mail]>]

 Lars, thank you for the review.
We have uploaded -13.
Please see inline.

    On Thursday, December 15, 2022, 05:18:56 PM EST, Jeffrey Haas <[e-mail]> wrote:  
 
 Lars,

[Speaking in role as chair/shepherd and not author.]

On Mon, Dec 12, 2022 at 06:27:25AM -0800, Lars Eggert via Datatracker wrote:
> ## Discuss
> 
> ### Section 7.1, paragraph 3
> ```
>      The same security considerations and protection measures as those
>      described in [RFC5880] and [RFC5881] apply to this document.  In
>      addition, with "unsolicited BFD" there is potential risk for
>      excessive resource usage by BFD from "unexpected" remote systems.  To
>      mitigate such risks, the following measures are mandatory:
> 
>      *  Limit the feature to specific interfaces, and to single-hop BFD
>        with "TTL=255" [RFC5082].
>      *  Apply "policy" to allow BFD packets only from certain subnets or
>        hosts.
>      *  Deploy the feature only in certain "trustworthy" environment,
>        e.g., at an IXP, or between a provider and its customers.
>      *  Use BFD authentication, see [RFC5880].  In some environments, e.g.
>        when using an IXP, BFD authentication can not be used because of
>        the lack of coordination into the operation of the two endpoints
>        of the BFD session.  In other environments, e.g. when BFD is used
>        to track the next hop of static routes, it is possible to use BFD
>        authentication: this comes with the extra cost of configuring
>        matching key-chains at the two endpoints.  If BFD authentication
>        is used, the Meticulous Keyed SHA1 mechanism SHOULD be used.
> ```
> BFD can be configured to send large volumes of traffic, and it sends
> it without congestion control. When a past IESG approved BFD for
> standardization in that form, it was exactly because both endpoints
> needed to be configured, which significantly reduces the
> possibility/impact of unilateral misconfiguration. I don't believe
> the suggestions above provide nearly the same level of protection.
> Also, if (all of?) these are mandatory, that needs to be made very
> clear, i.e., using RFC2119 terms here and elsewhere in the document
> (where it currently says these mechanisms are recommended...)

Strictly from an English standpoint, I'm unclear what the appropriate
response is to your request above.  The "mandatory" word leading the bullet
points certainly could be treated as each of those points as having a
leading "MUST" there.  Or alternatively, the word mandatory itself could be
replaced with MUST.  

Would you be satisfied by replacing the sentence prior to the bullet points
with:

"To mitigate such risks, implementations of unsolicited BFD MUST:"

?<RR> The suggested change above has been made in -13 (might actually have been in -12).
Wrt "large volumes of traffic", was Jeff's response below satisfactory, or is there still a concern?
Regards,Reshad.

With regard to the concerns about "large volumes of traffic":
- Those mandatory items restrict possible unsolicted sessions to a directly
  connected interface, on subnets that are part of an ACL, and ideally with
  BFD authentication mechanisms.
- BFD doesn't go into its fast mode until the BFD state machinery goes into
  the Up state. Thus, the passive side will not send traffic at speed until
  all of the requirements above are satisfied AND the state machine permits
  the session to advance to Up.
- An active implementation that doesn't respect the state machinery isn't
  compliant.  Arguably, it's simply a DoS attacker that just happens to be
  using BFD ports as its target.

-- Jeff