| BFD Working Group | G. Mirsky |
| Internet-Draft | X. Min |
| Intended status: Standards Track | ZTE Corp. |
| Expires: January 3, 2020 | July 2, 2019 |
Extended Bidirectional Forwarding Detection
draft-mirmin-bfd-extended-01
This document describes a mechanism to extend the capabilities of Bidirectional Forwarding Detection (BFD). These extensions enable BFD to measure performance metrics like packet loss and packet delay. Also, a method to perform lightweight on-demand authentication is defined in this specification.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[RFC5880] provided the base specification of Bidirectional Detection (BFD) as the light-weight mechanism to monitor a path continuity between two systems and detect a failure in the data-plane. Since its introduction, BFD has been broadly deployed. There were several attempts to introduce new capabilities in the protocol, some more successful than others. One of the significant obstacles to extending BFD capabilities may be seen in the compact format of the BFD control message. This document introduces an Extended BFD control message and describes the use of the new format for new BFD capabilities.
BFD: Bidirectional Forwarding Detection
G-ACh Generic Associated Channel
HMAC Hashed Message Authentication Code
MTU Maximum Transmission Unit
PMTUD Path MTU Discovery
p2p: Point-to-Point
TLV Type, Length, Value
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| BFD Control Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Guard Word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended BFD Control Message Format
If an Extended BFD control message is encapsulated in IP/UDP, the value of the Total Length in the IP header includes the length of the Extended BFD control message while the value of the Length field of the BFD control message equals the value as defined in [RFC5880]. If an Extended BFD control message is to be used over Generic Associated Channel (G-ACh), e.g., [RFC6428] new code point for G-ACh may be allocated.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: General Type-Length-Value Encoding
Figure 2 displays the generic TLV format.
TLVs may be included within other TLVs, in which case the former TLVs are referred to as sub-TLVs. Sub-TLVs have independent types.
A BFD system also referred to as a node in this document, that supports Extended BFD first MUST discover whether other nodes in the given BFD session support the Extended BFD. The node MUST send Extended BFD control message initiating the Poll Sequence as defined in [RFC5880]. If the remote system fails to respond with the Extended BFD control message and the Final flag set, then the initiator node MUST conclude that the BFD peer does not support the use of the Extended BFD control messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L | D |M| Authentication ... | Reserved ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Capability TLV Format
The first Extended BFD control message initiating the Poll Sequence SHOULD include the Capability TLV that lists capabilities that may be used at some time during the lifetime of the BFD session. The format of the Capability TLV and the capabilities that use the Extended BFD control message are presented in Figure 3.
The remote BFD node that supports this specification MUST respond to the Capability TLV with the Extended BFD control message that includes the Capability TLV listing capabilities the responder supports. The responder MUST set the Final flag in the Extended BFD control message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Padding | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Padding ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Padding TLV Format
Padding TLV MAY be used to generate Extended BFD control packets of the desired length.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Diagnostic | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Diagnostic TLV Format
Diagnostic TLV MAY be used to characterize the result of the last requested operation.
Loss measurement, delay measurement, and loss/delay measurement messages can be used in the Extended BFD control message to support one-way and round-trip measurements. All the messages are encapsulated as TLVs with Type values allocated by IANA, Section 4.
The sender MAY use the Performance Metric TLV (presented in Figure 6) to measure performance metrics and obtain the measurement report from the receiver.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Performance Metric | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Measurement Message, |
~ Delay Measurement Mesage, or ~
| Combined Loss/Delay Measurement Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Performance Metric TLV Format
To perform one-way loss and/or delay measurement, the BFD node MAY periodically transmit the Extended BFD message with one of the TLVs listed above in Asynchronous mode. To perform synthetic loss measurement, the sender MUST monotonically increment the counter of transmitted test packets. Also, direct-mode loss measurement, as described in [RFC6374], is supported. Procedures to negotiate and manipulate transmission intervals defined in Sections 6.8.2 and 6.8.3 in [RFC5880] SHOULD be used to control the performance impact of using the Extended BFD for performance measurement in the particular BFD session.
To measure the round-trip loss and/or delay metrics the BFD node transmits the Extended BFD control message with the Performance Metric TLV with the Poll flag set. Before the transmission of the Extended BFD control message with the Performance Metric TLV, the receiver MUST clear the Poll flag and set the Final flag.
Using BFD without any security measures, for example, by exchanging BFD control packets without authentication, increases the risk of an attack, especially over multiple nodes. Thus, using BFD without security measures may cause false positive as well as false negative defect detection situations. In the former, an attacker may spoof BFD control packets pretending to be a remote peer and can thus view the BFD session operation even though the real path had failed. In the latter, the attacker may spoof altered BFD control message indicating that the BFD session is un-operational even though the path and the remote BFD peer operate normally.
BFD technology[RFC5880] includes optional authentication protection of BFD control packets to minimize the chances of attacks in a networking system. However, at least some of the supported authentication protocols do not provide sufficient protection in modern networks. Also, current BFD technology requires authentication of each and every BFD control packet. Such an authentication requirement can put a computational burden on networking devices, especially in the Asynchronous mode, at least because authenticating each BFD control packet can require substantial computing resources to support packet exchange at high rates.
This specification defines a lightweight on-demand mode of authentication for a BFD session. The lightweight authentication is an optional mode that can be used when the BFD Authentication [RFC5880] is not in use (bfd.AuthType is zero). The mechanism includes negotiation (Section 3.5.1) and on-demand authentication (Section 3.5.2) phases. During the former, BFD peers advertise supported authentication capabilities and independently select the commonly supported mode of the authentication. In the authentication phase, each BFD system transmits, at certain events and periodically, authenticated BFD control packets in Poll Sequence.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len | AuthL | Authentication Mode ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Lightweight Authentication Capability Field Format
Figure 7 displays the format of the Authentication field that is part of the Capability Encoding:
A BFD system uses Capability TLV, defined in Section 3.1, to discover the commonly supported mode of the Lightweight Authentication. The system sets the values in the Authentication field according to properly reflect its authentication capabilities. The BFD system transmits the Extended BFD control packet with Capability TLV as the first in a Poll Sequence. The remote BFD system that supports this specification receives the Extended BFD control packet with the advertised Lightweight Authentication modes and stores information locally. The system responds with the advertisement of its Lightweight Authentication capabilities in the Extended BFD control packet with the Final flag set. Each BFD system uses local and received information about Lightweight Authentication capabilities to deduce the commonly supported modes and selects from that set the one that uses the strongest authentication with the longest signature. If the common set is empty, i.e., none of supported by one BFD system authentication method is supported by another, an implementation MUST reflect this in its operational state and SHOULD notify an operator.
After BFD peers select an authentication mode for using in Lightweight Authentication each BFD system MUST use it to authenticate each Extended BFD control packet transmitted as part of a Poll Sequence using Lightweight Authentication TLV presented in Figure 8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Lightweight Authentication| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HMAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Lightweight Authentication TLV Format
Section 3.2) MAY be used to align the length of the Extended BFD control packet, excluding the Lightweight Authentication TLV, at multiple of 16 boundary.
The Lightweight Authentication TLV MUST be the last TLV in an Extended BFD control packet. Padding TLV (
The BFD system that receives the Extended BFD control packet with the Lightweight Authentication TLV MUST first validate the .authentication by calculating the hash over the Extended BFD control packet. If the validation succeeds, the receiver MUST transmit the Extended BFD control packet with the Final flag set and the value of the Return code field in Diagnostic TLV set to None value (Table 5). If the validation of the lightweight authentication fails, then the BFD system MUST transmit the Extended BFD control packet with the Final flag set and the value of the Return Code field of the Diagnostic TLV set to Lightweight Authentication failed value (Table 5). The BFD system MUST have a control policy that defines actions when the system receives the Lightweight Authentication failed return code.
IANA is requested to create the Extended BFD Message Types registry. All code points in the range 1 through 32759 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 32760 through 65279 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 1:
| Value | Description | Reference |
|---|---|---|
| 0 | Reserved | This document |
| 1- 32767 | Mandatory TLV, unassigned | IETF Review |
| 32768 - 65279 | Optional TLV, unassigned | First Come First Served |
| 65280 - 65519 | Experimental | This document |
| 65520 - 65534 | Private Use | This document |
| 65535 | Reserved | This document |
This document defines the following new values in Extended BFD Type registry:
| Value | Description | Reference |
|---|---|---|
| TBA1 | Padding | This document |
| TBA2 | Capability | This document |
| TBA3 | Loss Measurement | This document |
| TBA4 | Delay Measurement | This document |
| TBA5 | Combined Loss/Delay Measurement | This document |
| TBA6 | Diagnostic | This document |
| TBA8 | Lightweight Authentication | This document |
IANA is requested to create a Lightweight Authentication Modes registry. All code points in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126].
This document defines the following new values in the Lightweight Authentication Modes registry:
| Bit Position | Value | Description | Reference |
|---|---|---|---|
| 0 | 0x1 | Keyed SHA-1 | This document |
| 1 | 0x2 | Meticulous Keyed SHA-1 | This document |
| 2 | 0x4 | SHA-256 | This document |
IANA is requested to create the Extended BFD Return Codes registry. All code points in the range 1 through 250 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 4:
| Value | Description | Reference |
|---|---|---|
| 0 | Reserved | This document |
| 1- 250 | Unassigned | IETF Review |
| 251-253 | Experimental | This document |
| 254 | Private Use | This document |
| 255 | Reserved | This document |
This document defines the following new values in Extended BFD Return Codes registry:
| Value | Description | Reference |
|---|---|---|
| 0 | None | This document |
| 1 | One or more TLVs was not understood | This document |
| 2 | Lightweight Authentication failed | This document |
This document does not introduce new security aspects but inherits all security considerations from [RFC5880], [RFC6428], and [RFC6374].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5880] | Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010. |
| [RFC6374] | Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011. |
| [RFC6428] | Allan, D., Swallow, G. and J. Drake, "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011. |
| [RFC8126] | Cotton, M., Leiba, B. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
TBD