Comments on draft-ietf-bfd-unaffiliated-echo-01

[Jeffrey Haas <[e-mail]>]

[Speaking as an individual contributor]

Authors,

Attached, please find an rfcdiff containing some suggested edits to your
draft.  The intent is to try to add clarity to the document.  If you would
find it helpful, I can also forward a patch vs. the published -01 xml.

---

Additionally, there are several points of discussion for you and perhaps the
Working Group about this proposal:

The changes recommended in section 2 are clear, but difficult to see what
content each change brings.  IETF has a mixed culture about how to implement
such changes in a document.  This draft does so by copy, paste, and change.
If we can collectively find a better way to highlight the differences
without being so wordy, that would be good.

Alternatively, I know some people will be thrilled with the format you have
chosen.  :-)

---

In section 3, the proposal effectively says that the BFD speaker is
originating BFD Control packets in the Echo Packet mode.  Since RFC 5880/5881
keeps the details about how Echo packets are made out of scope, but does
provide some guidance for security, this is acceptable.

I would suggest highlighting that the validation procedures of RFC 5880 are
used.  The intent appears to be "re-use existing BFD Control procedure as
much as possible", which means re-use of code.  Good!  However, this leads
to some interesting issues.

One example is that since a BFD speaker is "hearing itself" rather than
having the remote device actually speaking BFD, some things are wrong.  As
an example, the Discriminator procedures in the BFD Async mode can't apply.
The remote won't pick its own and swap it!  I'd thus recommend some text
about this.

RFC 5880, section 5, has the following to say about authentication:
:   Some form of authentication SHOULD be included, since Echo packets
:   may be spoofed.

Some procedural text related to authentication and the contents of the
packets is needed.

The desired min TX and required min RX intervals should be populated with
something, even if it's 1 second.  And perhaps some advice that we're
ignoring the values in these fields.

---

Your last set of changes in section 2 attempts to adjust the text covering
sending Echo packets.  When the implementation transitions to sending them
at the desired echo speed is a little ambiguous since the role of Control
packets is on the Echo port and in Echo packets.

One possible solution is that the Echo rate is not used until the BFD state
machine moves to the Up stage as per normal RFC 5880 procedures.  However,
that involves running the state machine from its usual slow rate of 1 second
until we transition to Up, and reverting to the slow rate when it goes to
Down/AdminDown.

This text will be tricky to do since we're blending the Control mode in the
Echo packets.

A strong goal of this is what happens when the remote is not echoing packets
back to us properly.  We do not want the BFD echo sender to transition
directly to a denial-of-service condition, especially since the TTL is set
to 255.  The usual slow rate until Up at least mitigates the sender's role
in this problem.

Note that the TTL receive check on the receiver will be at least 254 due to
the loop.  This reduces the effectiveness of GTSM, and potentially is an
issue for the loop procedure.

---

Does this mechanism ever go AdminDown?  What does it do, if so?

---

Suggestion: Move the following text in some form to the top of section 3:

:   After receiving the BFD Echo packets sent from device A, the one-hop-
:   away BFD peer device B immediately loops them back by normal IP
:   forwarding, this allows device A to rapidly detect a connectivity
:   loss to device B.

Being able to do this is a requirement for the feature, and the easy one to
articulate.  It provides the motivations for the rest of the section.

---

Security Considerations:

The URPF comments in the security considerations is really intended to say
"you can't do urpf for this feature".  It might be easy to just say that
more directly.

The requirement for this feature is that the receiver is willing to loop UDP
packets on port 3785.  In the simplest possible implementation, this can
become an open reflector attack and is probably one of the larger security
considerations our Transport and Security Area Directors and their
Directorates will flag.

There are two mitigations that can help with this, although it's an open
question whether the host stacks supplying the loop beheaviors can support
them:
- A packet SHOULD NOT be looped unless it has a TTL of 255.
- A packet being looped MUST NOT reset the TTL to 255, and SHOULD use a TTL
  of 254.  The motivation for this is firstly to respect GTSM procedures on
  reception and prevent remote attackers from exploiting the loop.  This
  should be able to be implemented using a firewall at the very least.
  Secondly, retransmiting with a fresh TTL of 255 can potentially cause a
  set of looping devices to infinitely loop traffic.  A TTL of 254 is the
  largest TTL that can prevent such infinite loops.  A lower TTL widens the
  window for targeting attack traffic to the BFD speaker originating the
  Echo traffic.

---

Comment to note for later purposes: the BFD state variables for the yang
module will need to be defined for these changes.  Oddly, we never got
around to doing a central IANA registry for such things.

-- Jeff