On 15/10/2024 22:11, Jeffrey Haas
wrote:
For me, that's much clearer than the text that appears in the draft, thank you for explaining. Could something like this appear in the spec.?Gorry, On Tue, Oct 15, 2024 at 05:26:04PM +0100, Gorry Fairhurst wrote:I have a few comments, but i am not a routing expert, so I'm maybe misisng context on the intended use, and why this is a good thing to allow.... I did not find a description of why this was needed.Like many IETF specifications, the use cases often get dropped from the work as the document proceeds through its discussion. This "one sided BFD" covers the use case where a device that understands BFD wants to validate bidirectional connectivity to a second device that doesn't understand BFD. Devices supporting traditional RFC 5880 BFD are able to leverage Echo mode where the forwarding path is verified by looping packets through the remote node. This has been deployed for years by multiple vendors. Traditional RFC 5880 requires the BFD asynchronous mode session to be in the Up state prior to using the Echo mode. This draft leverages the existing looping mechanism used by Echo to permit one BFD speaker to use Echo without requiring BFD asynchronous mode to be present on the remote side. To provide protection vs. running BFD Echo mode at speed with a non-consenting remote party, the existing BFD state machine is executed on the BFD speaker while talking to itself. Thus, BFD only moves to sending packets at speed once the looped BFD session has moved to the Up state.
If the above text were there, it would be easier to understandWhereas I understand BFD is a protocol setup between two endpoints, this draft appears to describe a version without the setup, which makes it a UDP-based request/response protocol in itself. That brings questions about how it addresses RFC 8085 (also known as BCP 145), with respect to the UDP Usage? This does not appear to be explained.Hopefully the above comments about leveraging the existing BFD state machine helps.
Can this be misused as a DoS vector?BFD's state machine starts in a sedate mode (1 packet per second is common) until the session moves to Up before it will send packets at speed
GTSM, aka RFC 5082, isn't mentioned or used, but it seems to be relevent? If not, then the mechanism used to protect from forwarding needs more explanation.See the text covering TTL in the draft.
That TTL text was what made me ask.
I still think this might be a use fo GTSM, aka RFC 5082? If so, that's good for me, if you refer to it - if it's not, what is different?
Best wishes, Gorry P.S. I didn't understand this: "Unaffiliated BFD Echo requires the remote device to loop Unaffiliated BFD Echo packets.", so the packet would fail an RPF check to the source - why is this good?Packet looping is the mechanism that has been used by BFD Echo for years. This part is not new. -- Jeff
Thanks, appreciated - trying to carefuly read documents can be
hard across areas, but it's helpful to know what is being done.
Gorry
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
