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

Mon, 05 Apr 2021 14:40:53 -0700 

[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
Title: Diff: draft-ietf-bfd-unaffiliated-echo-01.txt - draft-ietf-bfd-unaffiliated-echo-jhaas.txt
 draft-ietf-bfd-unaffiliated-echo-01.txt   draft-ietf-bfd-unaffiliated-echo-jhaas.txt 
BFD Working Group W. Cheng BFD Working Group W. Cheng
Internet-Draft R. Wang Internet-Draft R. Wang
Updates: 5880 (if approved) China Mobile Updates: 5880 (if approved) China Mobile
Intended status: Standards Track X. Min Intended status: Standards Track X. Min
Expires: May 6, 2021 ZTE Corp. Expires: October 7, 2021 ZTE Corp.
R. Rahman R. Rahman
Cisco Systems Cisco Systems
R. Boddireddy R. Boddireddy
Juniper Networks Juniper Networks
November 2, 2020 April 5, 2021
Unaffiliated BFD Echo Function Unaffiliated BFD Echo Function
draft-ietf-bfd-unaffiliated-echo-01 draft-ietf-bfd-unaffiliated-echo-01
Abstract Abstract
Bidirectional Forwarding Detection (BFD) is a fault detection Bidirectional Forwarding Detection (BFD) is a fault detection
protocol that can quickly determine a communication failure between protocol that can quickly determine a communication failure between
two forwarding engines. This document proposes a use of the BFD Echo two forwarding engines. This document proposes a use of the BFD Echo
function where the local system supports BFD but the neighboring function where the local system supports BFD but the neighboring
system does not support BFD. system does not support BFD.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021. This Internet-Draft will expire on October 7, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Updates to RFC 5880 . . . . . . . . . . . . . . . . . . . . . 3 2. Updates to RFC 5880 . . . . . . . . . . . . . . . . . . . . . 3
3. Unaffiliated BFD Echo Procedures . . . . . . . . . . . . . . 6 3. Unaffiliated BFD Echo Procedures . . . . . . . . . . . . . . 6
4. Unaffilicated BFD Echo Applicability . . . . . . . . . . . . 7 4. Unaffilicated BFD Echo Applicability . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
To minimize the impact of device/link faults on services and improve To minimize the impact of device/link faults on services and improve
network availability, a network device must be able to quickly detect network availability, a network device must be able to quickly detect
faults in communication with adjacent devices. Measures can then be faults in communication with adjacent devices. Measures can then be
taken to promptly rectify the faults to ensure service continuity. taken to promptly rectify the faults to ensure service continuity.
BFD [RFC5880] is a low-overhead, short-duration method to detect BFD [RFC5880] is a low-overhead, short-duration method to detect
faults on the communication path between adjacent forwarding engines. faults on the communication path between adjacent forwarding engines.
The faults can be on interface, data link, and even forwarding The faults can be on interfaces, data link(s), and even the
engine. It is a single, unified mechanism to monitor any media and forwarding engines. It is a single, unified mechanism to monitor any
protocol layers in real time. media and protocol layers in real time.
BFD defines Asynchronous mode to satisfy various deployment BFD defines an Asynchronous mode to satisfy various deployment
scenarios, and also supports Echo function to reduce the device scenarios. It also supports an Echo function to reduce the device
requirement for BFD. When the Echo function is activated, the local requirement for BFD. When the Echo function is activated, the local
system sends BFD Echo packets and the remote system loops back the system sends BFD Echo packets and the remote system loops back the
received Echo packets through the forwarding path. If several received Echo packets through the forwarding path. If several
consecutive BFD Echo packets are not received by the local system, consecutive BFD Echo packets are not received by the local system,
then the BFD session is declared to be Down. then the BFD session is declared to be Down.
When using BFD Echo function, there are two typical scenarios as When using BFD Echo function, there are two typical scenarios as
below: below:
o Full BFD protocol capability with affiliated Echo function: this o Full BFD protocol capability with affiliated Echo function: This
scenario requires both the local device and the neighboring device scenario requires both the local device and the neighboring device
to support full BFD protocol. to support the full BFD protocol.
o Only BFD Echo function without full BFD protocol capability: o BFD Echo-Only function without full BFD protocol capability: This
this scenario requires only the local device to support sending scenario requires only the local device to support sending and
and demultiplexing BFD Control packets. demultiplexing BFD Control packets.
The two typical scenarios are both reasonable and useful, and the The latter scenario is referred to as Unaffiliated BFD Echo function
latter is referred to as Unaffiliated BFD Echo function in this in this document.
document.
Section 6.2.2 of [BBF-TR-146] describes one use case of the Section 6.2.2 of [BBF-TR-146] describes one use case of the
Unaffiliated BFD Echo function, and at least one more use case is Unaffiliated BFD Echo function, and at least one more use case is
known in the field BFD deployment. known is known to be deployed.
This document describes the use of the Unaffiliated BFD Echo function This document describes the use of the Unaffiliated BFD Echo function
over IPv4 and IPv6 for single IP hop. over IPv4 and IPv6 for single IP hop.
2. Updates to RFC 5880 2. Updates to RFC 5880
The Unaffiliated BFD Echo function described in this document reuses The Unaffiliated BFD Echo function described in this document reuses
the BFD Echo function as described in [RFC5880] and [RFC5881], but the BFD Echo function as described in [RFC5880] and [RFC5881], but
does not require BFD asynchronous mode. When using the Unaffiliated does not require BFD Asynchronous mode. When using the Unaffiliated
BFD Echo function, only the local system has the BFD protocol BFD Echo function, only the local system has the BFD protocol
enabled, the remote system just loops back the received BFD Echo enabled; the remote system just loops back the received BFD Echo
packets as regular data packets. packets as regular data packets.
With that said, this document updates [RFC5880] with respect to its This document updates [RFC5880] with respect to its descriptions on
descriptions on the BFD Echo function as follows. the BFD Echo function as follows.
o [RFC5880] states in the 4th paragraph of Section 3.2: o [RFC5880] states in the 4th paragraph of Section 3.2:
An adjunct to both modes is the Echo function. When the Echo An adjunct to both modes is the Echo function. When the Echo
function is active, a stream of BFD Echo packets is transmitted in function is active, a stream of BFD Echo packets is transmitted in
such a way as to have the other system loop them back through its such a way as to have the other system loop them back through its
forwarding path. If a number of packets of the echoed data stream forwarding path. If a number of packets of the echoed data stream
are not received, the session is declared to be down. The Echo are not received, the session is declared to be down. The Echo
function may be used with either Asynchronous or Demand mode. function may be used with either Asynchronous or Demand mode.
Since the Echo function is handling the task of detection, the Since the Echo function is handling the task of detection, the
skipping to change at page 7, line 34 skipping to change at page 7, line 30
+--------+ +---------+ +--------+ +---------+
| A |---------------------------------| B | | A |---------------------------------| B |
| |Inf 1 Inf 1| | | |Inf 1 Inf 1| |
+--------+10.1.1.1/24 10.1.1.2/24+---------+ +--------+10.1.1.1/24 10.1.1.2/24+---------+
BFD is supported. BFD is not supported. BFD is supported. BFD is not supported.
Figure 1: Unaffiliated BFD Echo deployment scenario Figure 1: Unaffiliated BFD Echo deployment scenario
4. Unaffilicated BFD Echo Applicability 4. Unaffilicated BFD Echo Applicability
With the more and more application of BFD detection, there are some Some devices that would benefit from the use of BFD may be unable to
scenarios the BFD Echo function is deployed. And due to the support the full BFD protocol. Examples of such devices include
different capabilities of the devices deploying BFD Echo function, servers running virtual machines, or Internet of Things (IoT)
it's required to apply Unaffiliated BFD Echo to the devices that devices. The Unaffiliated BFD Echo function can be used when two
couldn't afford the overhead of the full BFD protocol capability, devices are connected and only one of them supports the BFD protocol,
such as the servers running virtual machines or some Internet of and the other is capable of looping BFD Echo packets.
Things (IoT) devices. Unaffiliated BFD Echo can be used when two
devices are connected and only one of them supports BFD protocol
capability.
Unaffiliated BFD Echo function is reasonable and useful. Firstly,
Unaffiliated BFD Echo can use BFD protocol capability at the local
BFD-supported device, while using IP forwarding capability at the
peer BFD-unsupported device, so Unaffiliated BFD Echo can support
fast detecting and manage BFD sessions very effectively. Secondly,
it is scalable when using Unaffiliated BFD Echo to adapt to different
capabilities of devices.
5. Security Considerations 5. Security Considerations
All Security Considerations from [RFC5880] and [RFC5881] apply.
Unicast Reverse Path Forwarding (uRPF), as specified in [RFC3704] and Unicast Reverse Path Forwarding (uRPF), as specified in [RFC3704] and
[RFC8704], is a security feature that prevents the IP address [RFC8704], is a security feature that prevents the IP address
spoofing attacks which is commonly used in DoS, DDoS. uRPF has two spoofing attacks which is commonly used in DoS, DDoS. uRPF has two
modes called strict mode and loose mode. uRPF strict mode means that modes called strict mode and loose mode. uRPF strict mode means that
the router will perform checks for all incoming packets on a certain the router will perform checks for all incoming packets on a certain
interface: whether the router has a matching entry for the source IP interface: whether the router has a matching entry for the source IP
in the routing table and whether the router uses the same interface in the routing table and whether the router uses the same interface
to reach this source IP as where the router received this packet on. to reach this source IP as where the router received this packet on.
Note that the use of BFD Echo function would prevent the use of uRPF Note that the use of BFD Echo function would prevent the use of uRPF
in strict mode. in strict mode.
6. IANA Considerations 6. IANA Considerations
This document has no IANA action requested. This document has no IANA action requested.
7. Acknowledgements 7. Acknowledgements
The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky
skipping to change at page 9, line 6 skipping to change at page 8, line 41
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI
DOI 10.17487/RFC5881, June 2010, 10.17487/RFC5881, June 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5881>. editor.org/info/rfc5881>.
9.2. Informative References 9.2. Informative References
[BBF-TR-146] [BBF-TR-146]
Broadband Forum, "BBF Technical Report - Subscriber Broadband Forum, "BBF Technical Report - Subscriber
Sessions Issue 1", 2013, <https://www.broadband- Sessions Issue 1", 2013, <https://www.broadband-
forum.org/technical/download/TR-146.pdf>. forum.org/technical/download/TR-146.pdf>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
 End of changes. 22 change blocks. 
46 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

Reply via email to