Extended Bidirectional Forwarding DetectionZTE Corp.gregimirsky@gmail.comZTE Corp.xiao.min2@zte.com.cn
Routing
BFD Working GroupInternet-DraftBFDExtension
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.
has 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.
The Extended BFD protocol may be seen as
the Operations, Administration, and Maintenance (OAM)
protocol that provides both Fault Management (FM)
Performance Monitoring (PM) OAM functions. In some networks,
for example in a Deterministic Networking (DetNet) domain
, it is easier to ensure that a
test packet of a single OAM protocol is fate-sharing with data packets
rather than map several FM amd PM OAM protocols to that DetNet data flow.
BFD: Bidirectional Forwarding DetectionG-ACh Generic Associated ChannelHMAC Hashed Message Authentication CodeMTU Maximum Transmission UnitPMTUD Path MTU DiscoveryPMTUM Path MTU Monitoringp2p: Point-to-PointTLV Type, Length, ValueOAM Operations, Administration, and MaintenanceFM Fault ManagementPM Performance MonitoringDetNet Deterministic Networking
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
when, and only when, they appear in all capitals, as shown here.
where fields are defined as the following:
BFD control message as defined .Guard word - four octets long field to identify the role of the BFD system - sender or responder.TLVs - variable-length field that contains commands and/or data encoded as type-length-value (TLV).
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 . If an Extended BFD control message is
to be used over Generic Associated Channel (G-ACh), e.g.,
new code point for G-ACh may be allocated.
displays the generic TLV format.
where fields are defined as the following:
Type - two octets long field that defines the encoding of the Value fieldLength - two octets long field equals length on the Value field in octets.Value - depends on the Type.
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 .
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.
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 .
where fields are defined as the following:
Type - TBA1 allocated by IANA in Length - two octets long field equals length on the Capability field in octets.
The value of the Length field MUST be a multiple of 4.
Loss - two bits size field. The least significant of two bits is set if the node is
capable of measuring packet loss using periodically transmitted Extended BFD
control message. The most significant of two bits is set if the node is capable
of measuring packet loss using the Poll Sequence with Extended BFD control message.
Delay - two bits size field. The least significant of two bits is set if the node is
capable of measuring packet delay using periodically transmitted Extended BFD
control message. The most significant of two bits is set if the node is capable
of measuring packet delay using the Poll Sequence with Extended BFD control message.
MTU - two bits size field. Set if the node is capable of using the Extended BFD control message in Path MTU Discovery (PMTUD).
or PMTU Monitoring (PMTUM). The least significant of two bits is set if the node is
capable of PMTUD/PMTUM using periodically transmitted Extended BFD
control message. The most significant of two bits is set if the node is capable
of PMTUD/PMTUM using the Poll Sequence with Extended BFD control message.
(Lightweight) Authentication - variable-length field. The Authentication field is used by a BFD system to advertise its
lightweight authentication capabilities.
The format and the use of the Authentication field are defined in .Reserved - MUST be zeroed on transmission and ignored on receipt. The Reserved field is zero-padded to align
the length of the Capability TLV to a 4-octet boundary.
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.
Padding TLV MAY be used to generate Extended BFD control packets of the desired length.
where fields are defined as the following:
Type - TBA1 allocated by IANA in Length - two octets long field equals length on the Padding field in octets.Padding - variable-length field. MUST be zeroed on transmit and ignored on receipt.
Padding TLV MAY be used to generate Extended BFD Control packets of different lengths. That capability
is necessary to perform PMTUD, PMTUM, and measure synthetic packet loss and/or packet delay. When Padding TLV is
used in combination with one of performance measurement messages
carried in Performance Metric TLVs as defined in ,
Padding TLV MUST follow the Performance Metric TLV.
Padding TLV MAY be used in PMTUM as part of periodically sent Extended BFD Control messages.
In this case, the number of consecuitive messages that include Padding TLV MUST be not lesser than
Detect Multiplier to ensure that the remote BFD peer will detect loss of messages with the Padding TLV.
Also, Padding TLV MAY be present in an Extended BFD Control message with the Poll flag set. If the remote
BFD peer that supports this specification receives an Extended BFD Control message with Padding TLV,
it MUST include the Padding TLV with the Padding field of the same length as in the received packet and
set the Final flag.
Diagnostic TLV MAY be used to characterize the result of the last requested operation.
where fields are defined as the following:
Type - TBA6 allocated by IANA in .Length - MUST be set to four.Return Code - eight bits-long field. The responding BFD system can set it to one of the
values defined in .Reserved - 24 bits-long field. MUST be zeroed on transmit and ignored on receipt.
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, .
The sender MAY use the Performance Metric TLV (presented in )
to measure performance metrics and obtain the measurement report from the receiver.
where fields are defined as the following:
Type - TBA3 through TBA5 allocated by IANA in as follows:
TBA3 - Loss Measurement Type;TBA4 - Delay Measurement Type;TBA5 - Combined Loss/Delay Measurement TypeLength - two octets long field equals length on the Metric sub-TLVs field in octets.
The value of the Length field MUST be a multiple of 4.Value - various performance metrics measured either directly or
using synthetic methods accordingly using the messages defined in
Sections 3.1 through 3.3 .
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. When using Performance Metric TLV for synthetic measurement
an Extended BFD Control message MAY also include Padding TLV. In that case, the Padding TLV MUST immediately follow
Performance Metric TLV. Also, direct-mode loss measurement, as described in , is supported.
Procedures to negotiate and manipulate transmission intervals defined in
Sections 6.8.2 and 6.8.3 in 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 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 is not in use (bfd.AuthType is zero).
The mechanism includes negotiation () and
on-demand authentication () 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.
displays the format of the Authentication field
that is part of the Capability Encoding:
where fields are defined as the following:
Len (Length) - four-bits long field. The value of the Length field is equal to the
length of the Authentication field, including the Length, in octets.
AuthL (Authentication Length) - four bits size field. The value
of the field is, in four octets long words, the longest
authentication signature the BFD system is capable
of supporting for any of the methods advertised in the AuthMode field.
Authentication Mode - variable-length field. It is a bit-coded field that a BFD system uses
to list modes of lightweight authentication it supports.
A BFD system uses Capability TLV, defined in , 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 .
where fields are defined as the following:
Type - TBA8 allocated by IANA in Length - two octets long field equals length on the HMAC
(Hashed Message Authentication Code) field in octets.
The value of the Length field MUST be a multiple of 4.
HMAC - the hash value calculated on the entire preceding Extended BFD control packet data.
The Lightweight Authentication TLV MUST be
the last TLV in an Extended BFD control packet.
Padding TLV () MAY be used
to align the length of the Extended BFD control packet,
excluding the Lightweight Authentication TLV, at multiple of 16 boundary.
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 ().
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 ().
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 .
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 .
Remaining code points are allocated according to :
ValueDescriptionReference0ReservedThis document1- 32767Mandatory TLV, unassignedIETF Review32768 - 65279Optional TLV, unassignedFirst Come First Served65280 - 65519ExperimentalThis document65520 - 65534Private UseThis document65535ReservedThis document This document defines the following new values in Extended BFD Type registry:ValueDescriptionReferenceTBA1PaddingThis documentTBA2CapabilityThis documentTBA3Loss MeasurementThis documentTBA4Delay MeasurementThis documentTBA5Combined Loss/Delay MeasurementThis documentTBA6DiagnosticThis documentTBA8Lightweight AuthenticationThis 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 .
This document defines the following new values in the Lightweight Authentication Modes registry:Bit PositionValueDescriptionReference00x1Keyed SHA-1This document10x2Meticulous Keyed SHA-1This document20x4SHA-256This 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 .
Remaining code points are allocated according to :
ValueDescriptionReference0ReservedThis document1- 250UnassignedIETF Review251-253ExperimentalThis document254Private UseThis document255ReservedThis documentThis document defines the following new values in Extended BFD Return Codes registry:ValueDescriptionReference0NoneThis document1One or more TLVs was not understoodThis document2Lightweight Authentication failedThis document
This document does not introduce new security aspects but inherits all security considerations
from , ,
and .
TBD