Network Working Group Z. Li Internet-Draft Huawei Technologies Intended status: Standards Track L. Ou Expires: January 7, 2016 Y. Luo China Telcom Co., Ltd. S. Zhuang N. Wu Huawei Technologies July 06, 2015 BGP FlowSpec Extensions for Routing Policy Distribution (RPD) draft-li-idr-flowspec-rpd-00 Abstract This document describes a mechanism to use BGP Flowspec address family [RFC5575] as routing-policy distribution protocol. This mechanism is called BGP FlowSpec Extensions for Routing Policy Distribution (BGP FS RPD). Requirements Language 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]. Status of This Memo 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 January 7, 2016. Li, et al. Expires January 7, 2016 [Page 1] Internet-Draft BGP FS RPD July 2015 Copyright Notice Copyright (c) 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Routing Policies . . . . . . . . . . . . . . . . . . . . 3 1.2. BGP FlowSpec . . . . . . . . . . . . . . . . . . . . . . 4 1.3. BGP FlowSpec Extensions for Routing Policy Distribution . 4 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 3.1. FlowSpec Traffic Actions for Routing Policy Distribution 5 3.2. BGP Policy Attribute . . . . . . . . . . . . . . . . . . 6 3.2.1. Match Fields Format . . . . . . . . . . . . . . . . . 6 3.2.2. Action Fields Format . . . . . . . . . . . . . . . . 8 3.3. Capability Negotiation . . . . . . . . . . . . . . . . . 9 4. Applications . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Outbound Traffic Control . . . . . . . . . . . . . . . . 9 4.2. Inbound Traffic Control . . . . . . . . . . . . . . . . . 12 5. Additional Contributors . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction On a traditional IP network, devices calculate their respective paths in a dynamic and distributed manner. The entire network is divided into multiple autonomous systems (ASs), and an Interior Gateway Protocol (IGP) runs on the devices within each AS. The IGP enables devices within an AS to obtain the intra-AS network topology and use the same algorithm to calculate routes. Devices in different ASs use Border Gateway Protocol (BGP) to exchange routes. If a link or device fails, the IP network layer triggers route convergence to Li, et al. Expires January 7, 2016 [Page 2] Internet-Draft BGP FS RPD July 2015 protect data traffic. However, if you want to manually optimize traffic paths on a traditional IP network, you will encounter the following difficulties: Traffic can only be adjusted device by device. All routers that the traffic traverses need to be configured. The configuration workload is heavy. The operation is not only time consuming but also prone to misconfiguration for Service Providers. The routing policies used to control network routes are complex, posing difficulties to subsequent maintenance, high maintenance skills are required. Hence, an automatic mechanism for setting up routing policies is desirable which can simplify the complexity of routing policies configuration. 1.1. Routing Policies Routing policies are used to filter routes and control how routes are received and advertised. If route attributes, such as reachability, are changed, the path along which network traffic passes changes accordingly. When advertising, receiving, and importing routes, the router implements certain policies based on actual networking requirements to filter routes and change the attributes of the routes. Routing policies serve the following purposes: o Control route advertising: Only routes that match the rules specified in a policy are advertised. o Control route receiving: Only the required and valid routes are received. This reduces the size of the routing table and improves network security. o Filter and control imported routes: A routing protocol may import routes discovered by other routing protocols. Only routes that satisfy certain conditions are imported to meet the requirements of the protocol. o Modify attributes of specified routes Attributes of the routes: that are filtered by a routing policy are modified to meet the requirements of the local device. o Configure fast reroute (FRR): If a backup next hop and a backup outbound interface are configured for the routes that match a routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be implemented. Li, et al. Expires January 7, 2016 [Page 3] Internet-Draft BGP FS RPD July 2015 Routing policies are implemented using the following procedures: 1) Define rules: Define features of routes to which routing policies are applied. Users define a set of matching rules based on different attributes of routes, such as the destination address and the address of the router that advertises the routes. 2) Implement the rules: Apply the matching rules to routing policies for advertising, receiving, and importing routes. 1.2. BGP FlowSpec BGP FlowSpec is defined in [RFC 5575]. This RFC describes a new NLRI that allows to convey flow specifications and traffic Action/Rules associated (rate-limiting, redirect, remark ...). BGP Flow specifications are encoded within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. Rules (Actions associated) are encoded in Extended Community attribute. The BGP Flow Specification function allows BGP Flow Specification routes that carry traffic policies to be transmitted to BGP Flow Specification peers to control attack traffic. BGP FlowSpec leverages the BGP Control Plane to simplify the distribution of filter rules, new filter rules can be injected to all BGP peers simultaneously without changing router configuration. The typical application of BGP Flow-spec is to automate the distribution of traffic filter lists to routers for DDOS mitigation. 1.3. BGP FlowSpec Extensions for Routing Policy Distribution BGP FlowSpec address family [RFC5575] is used to install Flow based filters to filter unwanted data traffic. It is based on the forwarding plane, serves forwarding. BGP FlowSpec feature allows you to rapidly deploy and propagate filtering and policing functionality among a large number of BGP peer routers, it can easily and automatically push the filter update to all the BGP peer routers that support BGP FlowSpec address family, it is a powerful tool. Routing Policy is based on the control plane, serves routing protocols and routing tables. Routing Policy is also a powerful tool. Currently, Routing Policy can only be configured device by device. This document describes a mechanism to use BGP Flowspec address family [RFC5575] as routing-policy distribution protocol. This mechanism is called BGP FlowSpec Extensions for Routing Policy Distribution (BGP FS RPD). Li, et al. Expires January 7, 2016 [Page 4] Internet-Draft BGP FS RPD July 2015 BGP FS RPD introduce a new BGP path attribute called BGP Policy Attribute, it defines the matching criteria and actions for routing policies in the BGP Policy Attribute. BGP FS RPD uses the Destination Prefix component in the BGP FS NLRI to define a target prefix. When a device receives a BGP FS RPD route, it will use the target prefix containing in the BGP FS NLRI to choose the matching routes, in most case, a prefix will have one more matching routes. When the matching routes are selected, the routing policies carrying in the BGP FS RPD route wiil be applied to them. 2. Definitions and Acronyms BGP Flow Specification route: BGP Flow Specification routes are defined in RFC 5575. Each BGP Flow Specification route contains BGP Network Layer Reachability Information (NLRI) and Extended Community Attributes, which carry traffic filtering rules and actions to be taken on filtered traffic. BGP Flow Specification peer relationship: A BGP Flow Specification peer relationship is established between the device that generates BGP Flow Specification routes and each network ingress that will transmit the BGP Flow Specification routes. After receiving the BGP Flow Specification routes, the peer delivers preferred BGP Flow Specification routes to the forwarding plane. The routes are then converted into traffic policies that control attack traffic. ACL:Access Control List BGP: Border Gateway Protocol FS: Flow Specification PBR:Policy-Based Routing RPD: Routing Policy Distribution VPN: Virtual Private Network 3. Protocol Extensions 3.1. FlowSpec Traffic Actions for Routing Policy Distribution The traffic-action extended community consists of 6 bytes of which only the 2 least significant bits of the 6th byte (from left to right) are currently defined in [RFC5575]. Terminal Action (bit 47) Li, et al. Expires January 7, 2016 [Page 5] Internet-Draft BGP FS RPD July 2015 and Sample (bit 46) defines in [RFC5575], this document defines Route Policy Distribution Flag(Bit 45). The Flow Specification Traffic Actions for Routing Policy Distribution: 40 41 42 43 44 45 46 47 +---+---+---+---+---+---+---+---+ | reserved | R | S | T | +---+---+---+---+---+---+---+---+ Figure 1: FlowSpec Traffic-action Route Policy Distribution Flag(Bit 45): When this bit is set, the corresponding filtering rules will be used as Route Policy. 3.2. BGP Policy Attribute This document defines and uses a new BGP attribute called the "BGP Policy attribute". This is an optional BGP attribute. The format of this attribute is defined as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Match fields (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Action fields (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: BGP Policy Attribute Match fields: Match Fields define the matching criteria for the BGP Policy Attribute. Action fields: Action fields define the action being applied to the target route. 3.2.1. Match Fields Format Match Fields define the matching criteria for the BGP Policy Attribute. Li, et al. Expires January 7, 2016 [Page 6] Internet-Draft BGP FS RPD July 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Match Type (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Sub-TLVs (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Match Fields Format Match Type: 0: Permit, specifies the permit mode of a match rule. If a route matches the matching criteria of the BGP Policy Attribute, the actions defined by the Action fields of the BGP Policy Attribute are performed. If a route does not match the matching criteria for the BGP Policy Attribute, then nothing needs to do with this route. 1: Deny, specifies the deny mode of a match rule. In the deny mode, If a route does not match the matching criteria of the BGP Policy Attribute, the actions defined by the Action fields of the BGP Policy Attribute are performed. If a route matches the matching criteria of the BGP Policy Attribute, then nothing needs to do with this route. Number of Sub-TLVs: The number of Sub-TLVs contain in Match fields. The contents of Match fields are encoded as Sub-TLVs, where each TLV has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Values (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Sub-TLVs Format Type: The Type field contains a value of 1-65534. The values 0 and 65535 are reserved for future use. Length: The Length field represents the total length of a given TLV's value field in octets. Values: The Value field contains the TLV value. Li, et al. Expires January 7, 2016 [Page 7] Internet-Draft BGP FS RPD July 2015 Supported format of the TLVs can be: Type 1: IPv4 Neighbor Type 2: IPv6 Neighbor Type 3: ASN List ... To be added in later versions. 3.2.2. Action Fields Format Action fields define the action being applied to the targeted route. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action Type (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action Length (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Action Values (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Action Fields Format Action Type: The Action Type field contains a value of 1-65534. The values 0 and 65535 are reserved for future use. Action Length: The Action Length field represents the total length of the Action Values in octets. Action Values: The Action Values field contain parameters of the action. Supported format of the TLVs can be: Type 1: Route-Preference Type 2: Route-Prepend-AS ... To be added in later versions. Li, et al. Expires January 7, 2016 [Page 8] Internet-Draft BGP FS RPD July 2015 3.3. Capability Negotiation It is necessary to negotiate the capability to support BGP FlowSpec Extensions for Route Policy Distribution (RPD). The BGP FS RPD Capability is a new BGP capability [RFC5492]. The Capability Code for this capability is to be specified by the IANA. The Capability Length field of this capability is variable. The Capability Value field consists of one or more of the following tuples: +--------------------------------------------------+ | Address Family Identifier (2 octets) | +--------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +--------------------------------------------------+ | Send/Receive (1 octet) | +--------------------------------------------------+ Figure 6: BGP FS RPD Capability The meaning and use of the fields are as follows: Address Family Identifier (AFI): This field is the same as the one used in [RFC4760]. Subsequent Address Family Identifier (SAFI): This field is the same as the one used in [RFC4760]. Send/Receive: This field indicates whether the sender is (a) willing to receive Route Policies via BGP FLowSpec from its peer (value 1), (b) would like to send Route Policies via BGP FLowSpec to its peer (value 2), or (c) both (value 3) for the . 4. Applications 4.1. Outbound Traffic Control Figure 7 shows the multiple transit providers scenario. For Network 1, it has n entries/exits that respectively connect to transit network N1, N2 and Nn. And between Network 1 and each transit network, there is one or more links. Different link has different cost/price, bandwidth, delay/loss attributes. For this multiple extry/exit scenario, it has the following requirements: o Choose the proper extry/exit based on link price and/or service type; Li, et al. Expires January 7, 2016 [Page 9] Internet-Draft BGP FS RPD July 2015 o Dynamically adjust the extry/exit based on link load and/or link price; /----\ |------------| | N1 |---| | L1 / \----/ | | ---------------- / / | | /// \\\ / / | | / ------ /\ /L3 | | | |IGW1|--+ | / | | | ------------ ------ \|/ | | | |Policy | /\ | | | |Controller| / |\ | | Route-Advertising | ------------ / | \L2 | | <------- | ------/ | \ /----\ | | | Network 1 |IGW2|----+---| N2 |--| ... |------| Prefix1 | ------ L4 | \----/ | | | ----- | | | | |PE1| ... | ... | | | ----- ------ | | | | |IGWn|--+ | | | | ------ \| | | | |\ | | \\\ /// \ | | ---------------- \ /----\ | | | Nn |---| | \----/ |------------| -----> Traffic to Prefix1 PE1 acts as an Ingress Router EBGP peering: L1: IGW1 with N1; L2: IGW1 with N2; L3: IGW2 with N1; L4: IGW2 with N2 Figure 7: Inbound Route Control / Outbound Traffic Control Outbound traffic control adjusts the transmission paths of outbound traffic from the ISP network to ensure that the traffic is evenly shared among links between IGWs and Transit Providers networks and the bandwidth usage of each link is below the specified threshold. In outbound traffic control scenario, if the bandwidth usage of a link exceeds the specified threshold, the Policy Controller automatically identifies which traffic needs to be scheduled and the Policy Controller automatically calculates traffic control paths based on network topology and traffic information. For example: Li, et al. Expires January 7, 2016 [Page 10] Internet-Draft BGP FS RPD July 2015 To ensure even traffic sharing, the outbound traffic destined for Prefix1 needs to be scheduled to link IGW2 -> N1 for transmission. The Policy Controller sends a BGP FS RPD route to IGW2, the route carries: 1) Prefix1 in the Destination Prefix component of the BGP FS NLRI; 2) Flow Specification Traffic Action Extended Community with the Route Policy Distribution Flag(Bit 45) set. When this bit is set, the corresponding filtering rules will be used as Routing Policies. 3) BGP Policy Attribute: o Match Type: 1, Permit o IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer N1 o Action Type: Route-Preference IGW2 processes the received BGP FS RPD route as follows: 1) IGW2 gets the target prefix Prefix1 from the Destination Prefix component in the BGP FS NLRI of the BGP FS RPD route; 2) IGW2 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW2 knows that the corresponding filtering rules will be used as Routing Policies. 3) IGW2 uses the target prefix Prefix1 to choose the matching routes, in this case, the prefix Prefix1 has two more routes: Prefix Next-Hop Local BGP Speaker Remote BGP Peer Prefix1 N1 IGW2 N1 Prefix1 N2 IGW2 N2 ... 4) IGW2 gets the matching criteria from the BGP Policy Attribute: Local BGP Speaker IGW2, Remote BGP Peer N1; 5) IGW2 gets the action from the BGP Policy Attribute: Route- Preference; So IGW2 chooses the BGP route received from N1 (rather than N2) as the best route and the outbound traffic destined for Prefix1 can be scheduled to link IGW2 -> N1 for transmission. Li, et al. Expires January 7, 2016 [Page 11] Internet-Draft BGP FS RPD July 2015 4.2. Inbound Traffic Control Inbound traffic control adjusts the transmission paths of traffic bound for the IP core network to ensure that the traffic is evenly shared among links between Transit Networks and IGWs and the bandwidth usage of each link is below the specified threshold. /----\ |------------| | N1 |---| | L1 / \----/ | | ---------------- / / | | /// \\\ / / | | / ------ /\ /L3 | | | |IGW1|--+ | / | | | ------------ ------ \|/ | | | |Policy | /\ | | | |Controller| / |\ | | Traffic to Prefix2 | ------------ / | \L2 | | <------- | ------/ | \ /----\ | | | Network 1 |IGW2|----+---| N2 |--| ... |------| Client | ----- ------ L4 | \----/ | | | |PE1| | | | | ----- ... | ... | | | Prefix2 ------ | | | | |IGWn|--+ | | | | ------ \| | | | |\ | | \\\ /// \ | | ---------------- \ /----\ | | | Nn |---| | \----/ |------------| -----> Route-Advertising Figure 8: Outbound Route Control / Inbound Traffic Control For example: To ensure even traffic sharing, the traffic destined for Prefix2 needs to be scheduled to link N1 -> IGW2 for transmission. The Policy Controller constructs a BGP FS RPD route and pushes it to all the IGW routers, the route carries: 1) Prefix2 in the Destination Prefix component of the BGP FS NLRI; 2) Flow Specification Traffic Action Extended Community with the Route Policy Distribution Flag(Bit 45) set. When this bit is set, the corresponding filtering rules will be used as Routing Policies. Li, et al. Expires January 7, 2016 [Page 12] Internet-Draft BGP FS RPD July 2015 3) BGP Policy Attribute: o Match Type: 2, Deny o IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer N1 o Action Type: Route-Prepend-AS o Action Value: Prepend-AS times is 5 IGW1 processes the received BGP FS RPD route as follows: 1) IGW1 gets the target prefix Prefix2 from the Destination Prefix component in the BGP FS NLRI of the BGP FS RPD route; 2) IGW1 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW1 knows that the corresponding filtering rules will be used as Routing Policies. 3) IGW1 uses the target prefix Prefix2 to choose the matching routes, in this case, IGW1 will choose the current best route of Prefix2; 4) IGW1 gets the matching criteria from the BGP Policy Attribute: Local BGP Speaker IGW2, Remote BGP Peer N1; 5) IGW1 gets the action from the BGP Policy Attribute: Route-Prepend- AS, 5 times; IGW1 checks the matching criteria and finds that it doesn't hits the matching criteria: Local BGP Speaker IGW2, Remote BGP Peer N1, at the same time the Match Type is "Deny" mode, so IGW1 sends the best route of Prefix2 to N1 with performing the Action instructions from the BGP FS RPD route: Prepend Local AS 5 times. IGW2 processes the received BGP FS RPD route as follows: 1) IGW2 gets the target prefix Prefix2 from the Destination Prefix component in the BGP FS NLRI of the BGP FS RPD route; 2) IGW2 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW2 knows that the corresponding filtering rules will be used as Routing Policies. 3) IGW2 uses the target prefix Prefix2 to choose the matching routes, in this case, IGW2 will choose the current best route of Prefix2; Li, et al. Expires January 7, 2016 [Page 13] Internet-Draft BGP FS RPD July 2015 4) IGW2 gets the matching criteria from the BGP Policy Attribute: Local BGP Speaker IGW2, Remote BGP Peer N1; 5) IGW2 gets the action from the BGP Policy Attribute: Route-Prepend- AS, 5 times; IGW2 checks the matching criteria and finds that it hits the matching criteria: Local BGP Speaker IGW2, Remote BGP Peer N1, but the Match Type is "Deny" mode, so IGW2 sends the best route of Prefix2 to N1, without performing the Action instructions from the BGP FS RPD route. In like manner, the other IGWs will perform the same Action instructions as IGW1. Afterwards, client will choose the route to Prefix2 that it passes IGW2 and N1. So the traffic destined for Prefix2 has been be scheduled to link N1 -> IGW2 for transmission. 5. Additional Contributors Peng Zhou Huawei Email: Jewpon.zhou@huawei.com 6. IANA Considerations TBD. 7. Security Considerations TBD. 8. Acknowledgements The authors would like to thank xxx for their contributions to this work. 9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. Li, et al. Expires January 7, 2016 [Page 14] Internet-Draft BGP FS RPD July 2015 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009. [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, August 2009. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Liang Ou China Telcom Co., Ltd. 109 West Zhongshan Ave,Tianhe District Guangzhou 510630 China Email: oul@gsta.com Yujia Luo China Telcom Co., Ltd. 109 West Zhongshan Ave,Tianhe District Guangzhou 510630 China Email: luoyuj@gsta.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Li, et al. Expires January 7, 2016 [Page 15] Internet-Draft BGP FS RPD July 2015 Nan Wu Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: eric.wu@huawei.com Li, et al. Expires January 7, 2016 [Page 16]