[Last-Call] Re: Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

[Jeffrey Haas <jhaas@xxxxxxxx>]

Adrian,

For clarity, do you mean "receiver" in the sense of the originator of the packet that has received the reflected packet or the device doing the reflection?

If you mean the originator of the packet, the current text is:

All Unaffiliated BFD Echo packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255, and received with a TTL or Hop Limit value of 254, otherwise the received packets MUST be dropped.

Does this not address the comment?

A previously raised point is GTSM has in RFC 5082 appendix A a matching use case.

If you mean the reflecting party, it's ignorant of everything going on.  It's just doing IP forwarding.  In that context the behavior you're requesting is IP firewalling and would be out of scope for BFD echo as it's been deployed for years and implemented in multiple chipsets.

-- Jeff

On Oct 17, 2024, at 3:33 PM, Adrian Farrel <adrian@xxxxxxxxxxxx> wrote:

Jeff,

 

I think this is “almost there.”

Just need to say how the receiver of a reflected message ensures that the packet is a single hop packet.

That probably comes down to…

TTL MUST be greater than or equal to n (254?). All other packets MUST be discarded, but MAY be logged applying a rate limit to not overload the logging system.

 

Cheers,

Adrian

 

From: Jeffrey Haas <jhaas@xxxxxxxx> 
Sent: 17 October 2024 20:18
To: Greg Mirsky <gregimirsky@xxxxxxxxx>
Cc: Brian Trammell (IETF) <ietf@xxxxxxxxxxx>; Erik Auerswald <auerswal@xxxxxxxxxxxxxxxxx>; tsv-art@xxxxxxxx; draft-ietf-bfd-unaffiliated-echo.all@xxxxxxxx; last-call@xxxxxxxx; rtg-bfd@xxxxxxxx
Subject: [Last-Call] Re: Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

 

Greg,

 

Would you be satisfied to update the text to say this applies to RFC 5881 IPv4/IPv6 single-hop use cases and that all others are out of scope?

 

-- Jeff

 

On Oct 17, 2024, at 1:26 PM, Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:

 

Hi Jeff,
it appears that you and other proponents of this draft concentrate on the
single-hop BFD (RFC 5881) case. But single-hop BFD is also used in
BFD-over-foo, e.g., RFC 5884, RFC 8971, RFC 9521, draft-ietf-bess-evpn-bfd.
All these specifications all state that
  Support for echo BFD is outside the scope of this document.
According to draft-ietf-bfd-unaffiliated-echo, U-BFD is applicable in, for
example, VXLAN, what would happen to the looped packet? I seems like it
will be routed through the underlay network. AFAICS, that is not part of
BFD Echo function per RFC 5880.

Regards,
Greg

On Wed, Oct 16, 2024 at 9:28 AM Jeffrey Haas <jhaas@xxxxxxxx> wrote:

Brian,


On Oct 16, 2024, at 1:31 AM, Brian Trammell (IETF) <ietf@xxxxxxxxxxx>
wrote:

hi Erik,

Thanks for the clarifications. Xiao, please take this reply as a reply to
your own request for an amendment to this review; tl;dr the recommendations
to the authors, WG, and IESG change in their details but my headline
opinion (“Not Ready”) stands until the document is revised.


FWIW, I agree with Xiao that Erik's analysis is well considered.  He saved
me from writing a large amount of similar tax, and did so with less
frustrated sarcasm.


My most serious concerns here are summed up in Greg’s last message (though
I’m not as versed in the details of interactions with SR): in its
well-behaved, deployed-as-intended state this seems fine, it’s my lack of
understanding around the safeguards against (1) a malicious actor who has
access to a u-bfd endpoint or (2) the impact of implementation faults
breaking the sandbox assumptions around the protocol. Now, it may be that
these safeguards do indeed exist in some other document I didn’t read.


Please note that I consider Greg's references to be a "red herring", and
an unnecessary distraction.  The issues with SRv6 are security issues with
SRv6 and not specifically BFD related.

BFD Echo is a feature that has been shipping for years.  Echo relies on
three things:
1. A BFD implementation sends echo packets to a designated port addressing
those packets to itself.
2. The adjacent system loops those packets back.  The sender, talking to
itself, leverages the contents of the packet to determine that it is indeed
talking to itself and uses that information to decide that bi-directional
connectivity thus exists.

Point 3, which I suspect is part of Greg's contention, is that such Echo
reply functionality is enabled as part of BFD negotiation.  BFD's primary
role is permitting rate negotiation for the feature.  (See RFC 5880,
section 6.8.9)

That point is not necessarily true.

Routers will happily provide the loop behavior as part of IP forwarding.

Endpoints that are not routers that are asked to implement this mechanism
need to implement IP forwarding, even if in a limited context.



The minimum effort fix here is probably an expanded security
considerations section explaining how u-bfd doesn’t escape to the Internet.


Unfamiliarity with BFD is likely what makes this comment seem reasonable.
it's not.

From the draft:

"Similar to what's specified in [RFC5880
<https://www.rfc-editor.org/info/rfc5880>], the Unaffiliated BFD Echo
session begins with the periodic, slow transmission of Unaffiliated BFD
Echo packets. The slow transmission rate SHOULD be no less than one second
per packet, until the session is Up. After the session is Up, the
provisioned transmission interval is used."

If it's the case that a U-BFD session is provisioned to test a system that
isn't a willing participant, these things follow from underlying procedures:
- If the system doesn't loop the U-BFD packets, the BFD session never goes
to Up and thus the packet rate is 1/second.  This is less aggressive in
many respects that someone leaving ping running because the target IP stack
doesn't need to process this in user-land.
- If the system does loop the U-BFD packets and it is more than one IP hop
away, the TTL check will cause the U-BFD packets to be dropped and the
session will never go Up.  See prior comment for impact.

Is there something outside of these considerations that are intended to
cover "escape to the Internet" because that phrase doesn't actually make
much sense.

Other comments follow:


On 15 Oct 2024, at 22:43, Erik Auerswald <auerswal@xxxxxxxxxxxxxxxxx>
wrote:

Okay, then I am confused by the name of the protocol (“[…] Echo”), as well
as figure 1, which clearly shows device B sending packets back to device A.
I’m not sure I understand the distinction between “looping” a packet and
“creating a response packet” unless said looping functionality is at layer
1, but I see no reference here to optical or electromagnetic delay lines,
so I assume that is not the case.


You may wish to review the Echo procedures from RFC 5880 since the
terminology originates there.

In this case, it is loopback where a sender "talks to itself" by sending a
packet to an adjacent node with its own address as the destination.  IP
forwarding on that system sends the traffic back to itself. No packet
reception by the remote system beyond that required for forwarding is
required.

Unaffiliated BFD Echo is based on the fact that BFD Echo packets are not
handeled on any device except the device creating them.


I’m also having a lot of trouble reconciling Figure 1 with this, and with
Jeff’s statement “[t]he actual idea of a remote system is farcical for this
mode[…, in] U-bfd the system is only talking to itself.” Either the packets
stay on the device (and there are strong protocol-level guarantees that
would isolate the protocol from the Internet in cases of implementation
fault or unintentional misconfiguration, and the document needs to detail
what those are), or the session runs between two devices (in which case the
concerns about isolation need to be addressed explicitly).


How would you suggest graphically depicting "Device A" sending a PDU with
a destination of Device A to Device B and Device B, using standard IP
forwarding, sending the PDU back to Device A?  A UML sequence diagram?
Pseudocode?

Perhaps the term "loopback" is confusing some people because they think
they're talking to 127.0.0.1?


This uses the idea from RFC 5082, "The Generalized TTL Security Mechanism
(GTSM)", adapted to work over a single hop instead of no hop.


There is no citation to 5082 in this document. Please consider adding one
to help readers understand that that’s the intent here.


The citation would, at best, be to the non-normative appendix A.  Is that
satisfactory?

Yes, but it would ensure that non-compromised intermediate devides would
not forward the packet


Forward what packet?
If it's a configured U-BFD session from a conformant implementation, it'd
be the system addressing PDUs to itself.


, therefore reducing the risk of misuse via reflection. This concept seems
to lean very heavily on the assumption that these packets will never leave
the u-bfd sandbox (in the sense of “restricted environment”), otherwise I
would expect that using TTL as an escape safety feature would take priority
over using it as an internal detection feature.


Your scenario is not clear.  Are you arguing "don't use GTSM"?

Consider articulating a full scenario rather than some abstract "escapes"

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx