| Internet Engineering Task Force | N. Akiya |
| Internet-Draft | C. Pignataro |
| Updates: 5880 (if approved) | D. Ward |
| Intended status: Standards Track | Cisco Systems |
| Expires: December 14, 2014 | M. Bhatia |
| Alcatel-Lucent | |
| P. K. Santosh | |
| Juniper Networks | |
| June 12, 2014 |
Seamless Bidirectional Forwarding Detection (S-BFD)
draft-ietf-bfd-seamless-base-00
This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
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 http://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 December 14, 2014.
Copyright (c) 2014 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 (http://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.
Bidirectional Forwarding Detection (BFD), [RFC5880] and related documents, has efficiently generalized the failure detection mechanism for multiple protocols and applications. There are some improvements which can be made to better fit existing technologies. There is a possibility of evolving BFD to better fit new technologies. This document focuses on several aspects of BFD in order to further improve efficiency, to expand failure detection coverage and to allow BFD usage for wider scenarios. This document extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-case]. Because defined mechanism eliminates much of negotiation aspects of the BFD protocol, "Seamless BFD" (S-BFD) has been chosen as the name for this mechanism.
Each protocol instance (e.g. OSPF/IS-IS) allocates one or more BFD discriminators on its network node, ensuring that BFD discriminators allocated are unique within the network domain. Allocated BFD discriminators may be advertised by the protocol. Required result is that a protocol possess the knowledge of mapping between network targets to BFD discriminators. Each network nodes will also create a BFD session instance that listens for incoming BFD control packets with "your discriminator" having protocol allocated values. The listener BFD session instance, upon receiving a BFD control packet targeted to one of local S-BFD discriminator values, will transmit a response BFD control packet back to the sender.
Once above setup is complete, any network node, understanding the mapping between network targets to BFD discriminators, can quickly perform reachability check to these network targets by simply sending BFD control packets with known BFD discriminator value as "your discriminator".
For example:
<------- IS-IS Network ------->
+---------+
| |
A---------B---------C---------D
^ ^
| |
SystemID SystemID
xxx yyy
BFD Discrim BFD Discrim
123 456
Figure 1: S-BFD for IS-IS Network
Note that a protocol may create an explicit mapping between a protocol ID (e.g. System-ID, Router-ID) to a BFD discriminator. A protocol may also create an explicit mapping between a network target (e.g. IP address) to a BFD discriminator. A protocol may even function with implicit mapping between a network target (e.g. IPv4 address) to a BFD discriminator, i.e. IPv4 address is used as BFD discriminator value. Decisions and rules on how protocols allocate and distribute BFD discriminators are outside the scope of this document.
The reader is expected to be familiar with the BFD, IP, MPLS and SR terminology and protocol constructs. This section describes several new terminology introduced by Seamless BFD.
This document defines a generic mechanism where network nodes can send BFD control packets to specific network targets to perform various tasks. One task is to perform a reachability check (i.e requesting immediate response back). Details of this task is further defined in sections to follow. Further tasks (i.e. using BFD control packet to request specific services from specific network nodes) may be defined. Therefore, this document defines a code point for BFD Target Identifier. Each locally allocated S-BFD discriminator MUST be associated to BFD Target Identifier type, to allow demultiplexing to a specific task or service.
BFD Target Identifier types:
Value BFD Target Identifier Type
------ --------------------------
0 Reserved
1 Network Target Discriminator
Note that IP based BFD from [RFC5885] is supported by this specification, but non-IP based BFD is outside the scope of this document.
Further identifier types are to be defined as needed basis.
S-BFD functions on a well-known UDP port: TBD1.
Protocols (i.e. client of S-BFD) may request an arbitrary BFD discriminator value, or protocols may request a specific BFD discriminator value. Therefore, it is RECOMMENDED for implementations to create a separate discriminator pool for S-BFD sessions to minimize the collision between existing BFD sessions and S-BFD sessions. In such case, incoming BFD control packets MUST be demultiplexed first with UDP port to identify the discriminator table to look up the session. Regardless of the approach, collision can happen with following scenarios. Section 7) to generate a response back, due to "your discriminator" matching. This is clearly not desirable. If only IP based S-BFD is concerned, then it is possible for S-BFD reflector session to require demultiplexing of incoming S-BFD control packet with combination of destination IP address and "your discriminator". Then S-BFD discriminator only has to be unique within a local node. However, S-BFD is a generic mechanism defined to run on wide range of environments: IP, MPLS, Segment Routing ([I-D.previdi-filsfils-isis-segment-routing]), etc. For other transports like MPLS, because of the need to use non-routable IP destination address, it is not possible for S-BFD reflector session to demultiplex using IP destination address. With PHP, there may not be any incoming label stack to aid in demultiplexing either. Thus, S-BFD imposes a requirement that S-BFD discriminators MUST be network wide unique.
One important characteristics of S-BFD discriminator is that it MUST be network wide unique. If multiple network nodes allocated same S-BFD discriminator value, then S-BFD control packets falsely terminating on a wrong network node can result in reflector BFD session (described in
Each network node MUST create one or more reflector BFD sessions. This reflector BFD session is a session which transmits BFD control packets in response to received valid locally destined BFD control packets. Specifically, this reflector BFD session is to have following characteristics:
One reflector BFD session MAY be responsible for handling received BFD control packets targeted to all local BFD target identifiers, or few reflector BFD sessions MAY each be responsible for subset of local BFD target identifiers. This policy is a local matter, and is outside the scope of this document.
Note that incoming BFD control packets destined to BFD target identifier types may be IPv4, IPv6 or MPLS based. For those BFD target identifier types, implementations MAY either allow the same reflector BFD session to handle all incoming BFD control packets in address family agnostic fashion, or setup multiple reflector BFD sessions to handle incoming BFD control packets with different address families. This policy is again a local matter, and is outside the scope of this document.
S-BFD introduces some new state variables, and modifies the usage of existing ones.
A new state variable is added to the base specification in support of S-BFD.
This variable MUST be initialized to the appropriate type when the session is created, according to the rules in section TBD.
Some state variables defined in section 6.8.1 of the BFD base specification need to be initialized or manipulated differently depending on the session type.
Any network node can attempt to perform a full reachability validation to any BFD target identifier on other network nodes, as long as destination BFD target identifier is provisioned to use this mechanism. BFD control packets transmitted by the initiator is to have "your discriminator" corresponding to destination BFD target identifier.
A node that initiates a BFD control packet MAY create an active BFD session to periodically send BFD control packets to a target, or a BFD control packet MAY be crafted and sent out on "as needed basis" (ex: BFD ping) without any session presence. In both cases, a BFD instance MUST have a unique "my discriminator" value assigned. If a node is to create multiple BFD instances to the same BFD target identifier, then each instance MUST have separate "my discriminator" values assigned. A BFD instance MUST NOT use a discriminator corresponding to one of local BFD target identifiers as "my discriminator". This is to prevent incoming response BFD control packets ("pong" packets) having "your discriminator" as a discriminator corresponding to the local BFD target identifier.
Below ASCII art describes high level concept of full reachability validations using this mechanism. R2 reserves value XX as BFD discriminator for its BFD target identifier. ASCII art shows that R1 and R4 performing full reachability validation to XX on R2.
-- md=50/yd=XX (BFD ping) -->
<-- md=XX/yd=50 (BFD pong) --
[*]
R1 ---------------------- R2 ----------- R3 ----------- R4
| ^
| |
| + - md=60/yd=XX (BFD ping) --
+ - - -md=XX/yd=60 (BFD pong) -->
[*] Reflector BFD session on R2.
Figure 2: S-BFD path monitoring
If BFD control packet is to be sent via IP path, then:
If BFD control packet response is determined to explicitly be label switched, then:
The following diagram provides an overview of the initiator state machine. The notation on each arc represents the state of the remote system (as received in the State field in the BFD Control packet) or indicates the expiration of the Detection Timer.
+--+
ADMIN DOWN, | |
TIMER | V
+------+ UP +------+
| |-------------------->| |----+
| DOWN | | UP | | UP
| |<--------------------| |<---+
+------+ ADMIN DOWN, +------+
TIMER
Figure 3: S-BFD Initiator FSM
A network node which receives BFD control packets transmitted by an initiator is referred as responder. Responder, upon reception of BFD control packets, is to perform necessary relevant validations described in [RFC5880]/[RFC5881]/[RFC5883]/[RFC5884]/[RFC5885].
When responder receives a BFD control packet, if "your discriminator" value is not one of local entries in the BFD target identifier table, then this packet MUST NOT be considered for this mechanism. If "your discriminator" value is one of local entries in the BFD target identifier table, then the packet is determined to be handled by a reflector BFD session responsible for specified BFD targeted identifier. If the packet was determined to be processed further for this mechanism, then chosen reflector BFD session is to transmit a response BFD control packet using procedures described in Section 9.2.2, unless prohibited by local administrative or local policy reasons.
BFD target identifier type MUST be used to determine further information on how to reach back to the initiator.
In addition, destination IP address of received BFD control packet MUST be examined to determine how to construct response BFD control packet to send back to the initiator.
If destination IP address of received BFD control packet is not 127/8 for IPv4 or 0:0:0:0:0:FFFF:7F00/104 for IPv6, then:
Response BFD control packet SHOULD be IP routed back, but MAY explicitly be label switched.
If BFD control packet response is determined to be IP routed, then:
If BFD control packet response is determined to explicitly be label switched, then:
Regardless of the response type, BFD control packet being sent by the responder MUST perform following procedures:
Further details of BFD control packets sent by initiator (ex: active BFD session):
Further details of BFD control packets sent by responder (reflector BFD session):
Diagnostic value in both directions MAY be set to a certain value, to attempt to communicate further information to both ends. However, details of such are outside the scope of this specification.
The Poll sequence MUST operate in accordance with [RFC5880].
Control plane independent (C) bit for BFD instances speaking to a reflector BFD session MUST work according to [RFC5880]. Reflector BFD session also MUST work according to [RFC5880]. Specifically, if reflector BFD session implementation does not share fate with control plane, then response BFD control packets transmitted MUST have control plane independent (C) bit set. If reflector BFD session implementation shares fate with control plane, then response BFD control packets transmitted MUST NOT have control plane independent (C) bit set.
Same mechanism as described in "Full Reachability Validations" section will be applied with exception of following differences on initiator.
This mechanism brings forth one noticeable difference in terms of scaling aspect: number of BFD sessions. This specification eliminates the need for egress nodes to have fully active BFD sessions when only one side desires to perform reachability validations. With introduction of reflector BFD concept, egress no longer is required to create any active BFD session per path/LSP basis. Due to this, total number of BFD sessions in a network is reduced.
If traditional BFD technology was used on a network comprised of N nodes, and each node monitored M unidirectional paths/LSPs, then total number of BFD sessions in such network will be:
(((N - 1) x M) x 2)
Assuming that each network node creates one reflector BFD session to handle all local BFD target identifiers, then total number of BFD sessions in same scenario will be:
(((N - 1) x M) + N)
This mechanism has no issues being deployed with traditional BFDs ([RFC5881]/[RFC5883]/[RFC5884]/[RFC5885]) because BFD discriminators which allow this mechanism to function are explicitly reserved and separate UDP port values are used with S-BFD.
BFD echo is outside the scope of this document.
Same security considerations as [RFC5880], [RFC5881], [RFC5883], [RFC5884] and [RFC5885] apply to this document.
Additionally, implementing the following measures will strengthen security aspects of the mechanism described by this document.
Using the above method,
BFD Target Identifier types:
Value BFD Target Identifier Type
------ --------------------------
0 Reserved
1 Network Target Discriminator
Authors would like to thank Jeffrey Haas for performing thorough reviews and providing number of suggestions. Authors would like to thank Girija Raghavendra Rao, Marc Binderberger, Les Ginsberg, Srihari Raghavan, Vanitha Neelamegam and Vengada Prasad Govindan from Cisco Systems for providing valuable comments.
Tarek Saad
Cisco Systems
Email: tsaad@cisco.com
Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com
Nagendra Kumar
Cisco Systems
Email: naikumar@cisco.com
Mallik Mudigonda
Cisco Systems
Email: mmudigon@cisco.com
Sam Aldrin
Huawei Technologies
Email: aldrin.ietf@gmail.com
| [I-D.ietf-bfd-seamless-use-case] | Aldrin, S., Bhatia, M., Mirsky, G., Kumar, N. and S. Matsushima, "Seamless Bidirectional Forwarding Detection (BFD) Use Case", Internet-Draft draft-ietf-bfd-seamless-use-case-00, June 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5880] | Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. |
| [RFC5881] | Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. |
| [RFC5883] | Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. |
| [RFC5884] | Aggarwal, R., Kompella, K., Nadeau, T. and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. |
| [I-D.ietf-bfd-generic-crypto-auth] | Bhatia, M., Manral, V., Zhang, D. and M. Jethanandani, "BFD Generic Cryptographic Authentication", Internet-Draft draft-ietf-bfd-generic-crypto-auth-06, April 2014. |
| [I-D.previdi-filsfils-isis-segment-routing] | Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W. and J. Tantsura, "Segment Routing with IS-IS Routing Protocol", Internet-Draft draft-previdi-filsfils-isis-segment-routing-02, March 2013. |
| [RFC2827] | Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. |
| [RFC5885] | Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. |
Consider a scenario where we have two nodes and both are S-BFD capable.
Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2)
|
|
Man in the Middle (MiM)
Assume node A reserved a discriminator 0x01010101 for target identifier 1.1.1.1 and has a reflector session in listening mode. Similarly node B reserved a discriminator 0x02020202 for its target identifier 2.2.2.2 and also has a reflector session in listening mode.
Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc = 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this packet reaches Node B, the reflector session on Node B will swap the discriminators and IP addresses of the received packet and reflect it back, since YourDisc of the received packet matched with reserved discriminator of Node B. The reflected packet that reached Node A will have MyDdisc=0x02020202 and YourDisc=0x01010101. Since YourDisc of the received packet matched the reserved discriminator of Node A, Node A will swap the discriminators and reflects the packet back to Node B. Since reflectors MUST set the TTL of the reflected packets to 255, the above scenario will result in an infinite loop with just one malicious packet injected from MiM.
FYI: Packet fields do not carry any direction information, i.e., if this is Ping packet or reply packet.
Solutions
The current proposals to avoid the loop problem are: