Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unaffiliated-echo-12: (with DISCUSS and COMMENT)

[Jeffrey Haas <[e-mail]>]

Zahed,


> On Oct 17, 2024, at 8:52 AM, Zaheduzzaman Sarker via Datatracker <[e-mail]> wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks for working on this specificaition. This is an interesting protocol to
> enable system to loopback packets to itself.
> 
> [...]

> I am holding a discuss on the relaxation of congestion control statements in
> the operational considerations. I think it is very important that we explain
> the reason better on why we are relaxing that requirement on BFD session ( but
> not session) in this specification.
> 
> [...]

>  and this specification says
> 
>      All Operational Considerations from [RFC5880] apply, except that the
>     Unaffiliated BFD Echo can only be used across one hop, which result in
>     unnecessity of a congestion control mechanism.
> 
>   It seems like this specification is relaxing the congestion control
>  requirements without really explaining why it is an exception from what is a
>  SHOULD in RFC 5880, even for single hop. Note that RFC 8085 cprovides
>  congestion control guidelines for protocol that uses UDP. I understand that
>  there is a periodicity and configured value to send the BFD Echo packets,
>  still that does not automatically result in unnecessity of a congestion
>  control requirement for UDP traffic, especially when RFC 5880 also says the
>  congestion is not only a traffic phenomenon. I was expecting more explanation
>  of this exception ( this was also brought up by the TSVART review ) and
>  potential operation impacts as RFC 5880 also indicates the effects can be
>  catastrophic.

This sentence, which is admittedly a bit vague, seems only to be causing confusion and grief.  Would dropping it make these concerns go away?

Note, keeping or dropping it doesn't really change anything.  Two things are going on here:

1. Since this mechanism leverages existing BFD machinery, particularly periodic pacing of traffic based on configuration, there's no real "congestion control" present. That's true even in the base BFD protocol.  If the session is unable to sustain the paced traffic, the session drops because some combination of link or protocol resources is unable to sustain it.  In such cases, "works as designed".

2. The Echo mechanism in the base BFD protocol gave zero guarantees about any sort of congestion control to start with.  All behavior was locally chosen.  But similar to 1, above, since the point is to determine if the link is up and providing bidirectional connectivity, doing Bad Things to it doesn't make sense.

In particular, this document's recommendations to leverage the existing BFD machinery toward Echo makes for a better behaved system rather than the less specified "do as you like" in RFC 5880.

Thus, the sentence adds no deep clarity, nor its absence removes any real considerations.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I have further comments below as I believe when addressed that will improve the
> specification description -
> 
> # Section 1 : I don't quite get this statement
> 
>    This document updates [RFC5880] by defining a new method of BFD Echo-Only
>    without requiring an implementation to support the full BFD protocol.

The intent here is to cover the one-sidedness of the mechanism.  Did you have any suggested text changes to clarify that?

> 
>  Does this mean any IP packet forwarder can be Device B in figure 1?

Any forwarder.

> or the
>  device B actually needs to implement RFC5880 partially.

Device B only loops packets.  It may be completely ignorant of the BFD protocol, and that is the purpose of this mechanism.

> In the description of
>  Figure 1 , it says Device B does not support BFD. So to me, Device B can be
>  anything that understands IP forwarding, is it?
> 
> # Section 5 : it is not clear to me if Device B (loop-back device) in figure 1
> does not support BFD then how it can provide the authentication as per RFC
> 8550. I think we should say that for authentication the loop-back device needs
> to support RFC 5880.

Device B only provides loopback support.  All authentication is isolated to device A which implements this mechanism.

Reviewing section 5, the intent here is to cover attacks where the active attacker spoofs traffic targeting Device A by sending them through the loopback Device B.  Authentication prevents Device A from being susceptible to that attack.

What text would you prefer to see instead?

-- jeff


> 
>