IDR Working Group W. Hao Z. Li Y. Lucy Internet Draft Huawei Intended status: Standards Track Expires: March 2016 October 6, 2015 BGP Flow-Spec Redirect to Tunnel action draft-hao-idr-flowspec-redirect-tunnel-00.txt Abstract This draft defines a new flow-spec action, redirect-to-Tunnel, and a new sub-TLV for the redirect extended community to provide redirecting a flow to a tunnel. A BGP UPDATE for a flow-spec NLRI can contain the extended community. When activated, the corresponding flow packets will be encapsulated by a tunnel encapsulation protocol and then be forward to the target IP address. The redirected tunnel information and target IP address are encoded in BGP Path Attribute [TUNNELENCAPS] [MPP] that is carried in the BGP flow-spec UPDATE. The draft expends the tunnel encapsulation attribute to apply to flow-spec SAFI, i.e. 133 and 134. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Hao, et,al Expires March 5 [Page 1] Internet-Draft Flow Spec for Redirect-to-Tunnel October 2015 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 2. Redirect to Tunnel Extended Community........................ 3 2.1. Validation Procedures................................... 6 3. Security Considerations...................................... 6 4. IANA Considerations ......................................... 6 4.1. Normative References.................................... 7 4.2. Informative References.................................. 7 5. Acknowledgments ............................................. 7 1. Introduction BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. It leverages the BGP Control Plane to simplify the distribution of ACLs, 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. Every flow-spec route consists of a matching part (encoded in the NLRI field) and an action part(encoded in one or more BGP extended communities). The flow-spec standard [RFC 5575] defines widely-used filter actions such as discard and rate limit; it also defines a redirect-to-VRF action for policy-based forwarding. [Redirect to IP] defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. In some cases like service chaining, traffic steering and etc, the traffic needs to be redirected to tunnel directly. Using the redirect-to-VRF action or redirect-to-IP action for this will be complex and cumbersome. Hao, et,al Expires March 6, 2016 [Page 2] Internet-Draft Flow Spec for Redirect-to-Tunnel October 2015 This draft proposes a new redirect-to-tunnel flow-spec action that provides a straightforward solution for policy-based forwarding. The details of the redirected tunnel information are encoded in already existing defined BGP Path Attributes. 2. Redirect to Tunnel Extended Community To support ''Redirect to Tunnel'', besides the extended communities in below per RFC5575, a new extended community of ''Redirect to Tunnel'' is defined by this draft. This redirect extended community allows the traffic to be redirected to a set of tunnel(s) that are specified by BGP Tunnel Encapsulation Attribute [TUNNELENCAPS] and/or BGP Extended Unicast Tunnel Attribute [MPP]. +--------+--------------------+--------------------------+ | type | extended community | RFC or Draft | +--------+--------------------+--------------------------+ | 0x8006 | traffic-rate | RFC5575 | | 0x8007 | traffic-action | RFC5575 | | 0x8008 | redirect | RFC5575 | | 0x8009 | traffic-marking | RFC5575 | | TBD | redirect to Tunnel | This draft | +--------+--------------------+--------------------------+ The new extended community for ''Redirect to Tunnel'' has a type indicating it is transitive and ''Redirect to Tunnel'' [to be assigned by IANA]. The sub-TLV has following format. 40 41 42 43 44 45 46 47 +---+---+---+---+---+---+---+---+ | reserved | C | +---+---+---+---+---+---+---+---+ In this value field (6 bytes) the least-significant bit is defined as the 'C' (or copy) bit. When the 'C' bit is set the redirection applies to copies of the matching packets and not to the original traffic stream. All bits other than the 'C' bit MUST be set to 0 by the originating BGP speaker and ignored by the receiving BGP speakers. This draft extends BGP Tunnel Encapsulation Attribute to apply to BGP flow-spec SAFI, i.e., SAFI=133,134. When a tunnel is specified by BGP Tunnel Encapsulation Attribute, the tunnel type and encapsulation information such as VXLAN, NVGRE, VXLAN-GPE are encoded in the Tunnel Encapsulation Attribute Sub-TLVs. When Hao, et,al Expires March 6, 2016 [Page 3] Internet-Draft Flow Spec for Redirect-to-Tunnel October 2015 applying it to flow-spec safi, the target IP address, IPv4 or IPv6 MUST be encoded in the Remote Endpiont Sub-TLV with the corresponding AFI. The AS number in the sub-TLV MUST be the number of the AS to which the target IP address in the sub-TLV belongs. If the redirect to tunnel end point is the BGP next hop, the AFI in the sub-TLV should be filled with zero, and the address in the sub-TLV should be omitted, and AS field should be filled with zero. When a tunnel is specified by BGP Extended Unicast Tunnel Attribute [MPP], the tunnel type and encapsulation information such as RSVP-TE, LDP, Segment Routing Path are encoded in BGP Extended Unicast Tunnel Attributes ([MPP]). The flow-spec UPDATE carries the ''Redirect to Tunnel'' extended community MUST have at least one BGP Path Attribute that specifies a set of tunnel(s) that the flow packets can be redirected to. The following of this Section specifies a flow-spec to be redirect to the tunnel that is specified by BGP tunnel encapsulation attribute [TUNNELENCAPS]. A flow-spec to be redirected to a tunnel that is specified by the BGP extended unicast tunnel attribute will be addressed in future version. When a BGP speaker receives a flow-spec route with a 'redirect to Tunnel' extended community and this route represents the one and only best path, it installs a traffic filtering rule that matches the packets described by the NLRI field and redirects them (C=0) or copies them (C=1) towards the target IPv4 or IPv6 address encoded in Remote Endpoint sub-TLV of Tunnel Encapsulation Attribute. The BGP speaker is expected to do a longest-prefix-match lookup of the 'target address' in its forwarding information base (FIB) and forward the tunneled redirected/copied packets based on the resulting route (the 'target route'). If the 'target address' is invalid or unreachable then the extended community SHOULD be ignored. If a BGP speaker receives a flow-spec route with one 'Redirect to Tunnel' extended community and one BGP Tunnel Encapsulation Attribute that represents a set of tunnels to the same target address, and all of them are considered best and usable paths according to the BGP speaker's multipath configuration, the BGP speaker SHOULD load-share the redirected packets across all the tunnels. If the BGP speaker is not capable of redirecting and copying the same packet it SHOULD ignore the extended communities with C=0. If the BGP speaker is not capable of redirecting/copying a packet towards multiple tunnels it SHOULD deterministically select one tunnel to the 'target address' and ignore the others. Hao, et,al Expires March 6, 2016 [Page 4] Internet-Draft Flow Spec for Redirect-to-Tunnel October 2015 If a BGP speaker receives multiple flow-spec routes for the same flow-spec NLRI and all of them are considered best and usable paths according to the BGP speaker's multipath configuration and each one carries one 'Redirect to Tunnel' extended community and one Tunnel Encapsulation Attribute, the BGP speaker SHOULD load-share the tunneled redirected/copied packets across all the tunnels, with the same fallback rules as discussed in the previous paragraph. Note that this situation does not require the BGP speaker to have multiple peers - i.e. Add-Paths could be used for the flow-spec address family. If a BGP speaker receives a flow-spec route with one 'Redirect to Tunnel'' and one or more 'redirect to IP' extended communities; local policy determines which 'redirect' should be used. If a BGP speaker receives a flow-spec route with one 'Redirect to Tunnel'' and one or more 'redirect to VRF' extended communities, and this route represents the one and only best path, the 'Redirect to Tunnel' actions described above should be applied in the context of the 'target VRF' matching the 'redirect to VRF' extended community - i.e. the 'target addresses' should be looked up in the FIB of the 'target VRF'. If there are multiple 'redirect to VRF' extended communities in the route the 'target VRF' SHOULD be the one that matches the 'redirect to VRF' extended community with the highest numerical value. If the BGP speaker is not capable of 'redirect to VRF' followed by 'Redirect to Tunnel' then it SHOULD give preference to performing the 'redirect to VRF' action and doing only longest- prefix-match forwarding in the 'target VRF'. If a BGP speaker receives multiple flow-spec routes for the same flow-spec NLRI and all of them are considered best and usable paths according to the BGP speaker's multipath configuration and they carry a combination of 'Redirect to Tunnel' and 'redirect to VRF' extended communities, the BGP speaker SHOULD apply the 'Redirect to Tunnel' actions in the context of the 'target VRF' as described above. Note that this situation does not require the BGP speaker to have multiple peers - i.e. Add-Paths could be used for the flow-spec address family. The redirected/copied flow packets will be encapsulated first. The outer src address on the encapsulated packets MUST be filled with the IP address of the forwarding router; the outer dst address on the packets MUST be filled with the target IP address. If the flow has multiple tunnels that have the 'target address' as remote tunnel endpoint, the redirected/copied packets MAY be encapsulated according to tunnel type and be load-shared across these tunnels according to the router's ECMP configuration. Hao, et,al Expires March 6, 2016 [Page 5] Internet-Draft Flow Spec for Redirect-to-Tunnel October 2015 If the 'target route' has one or more tunnel next-hops then, in turn, the tunneled redirect/copy packets SHOULD be encapsulated appropriately again. 2.1. Validation Procedures The validation check described in [RFC 5575] and revised in [VALIDATE] SHOULD be applied by default to received flow-spec routes with a 'redirect to tunnel' extended community, as it is to all types of flow-spec routes and the validation check described in [TUNNELENCAPS] SHOULD be applied to the tunnel encapsulation attribute. This means that a flow-spec route with a destination prefix subcomponent SHOULD NOT be accepted from an EBGP peer unless that peer also advertised the best path for the matching unicast route. BGP speakers that support the extended communities defined in this draft MUST also, by default, enforce the following check when receiving a flow-spec route from an EBGP peer: if the received flow- spec route has a 'redirect to tunnel' extended community with a 'target address' X (in the remote endpoint sub-TLV) and the best matching route to X is not a BGP route with origin AS matching the peer AS then the extended community should be discarded and not propagated along with the flow-spec route to other peers. It MUST be possible to disable this additional validation check on a per-EBGP session basis. 3. Security Considerations A system that originates a flow-spec route with a 'redirect to tunnel' extended community can cause many receivers of the flow-spec route to send traffic to a single next-hop, overwhelming that next- hop and resulting in inadvertent or deliberate denial-of-service. This is particularly a concern when the 'redirect to tunnel' extended community is allowed to cross AS boundaries. The validation check described in section 2.1 significantly reduces this risk. 4. IANA Considerations IANA is requested to update the reference for the following assignment in the "BGP Extended Communities Type/sub-Type for 'Redirect to Tunnel' that is specified in this draft. Hao, et,al Expires March 6, 2016 [Page 6] Internet-Draft Flow Spec for Redirect-to-Tunnel October 2015 4.1. Normative References [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4.2. Informative References [1] [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J.Mauch, D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, August 2009. [2] [Redirect to IP] J.Uttaro, etc, " BGP Flow-Spec Redirect to IP Action ", draft-ietf-idr-flowspec-redirect-ip-02, February 2015. [3] [TUNNELENCAPS] E. Rosen, etc, " Using the BGP Tunnel Encapsulation Attribute without the BGP Encapsulation SAFI ", draft-rosen-idr-tunnel-encaps-00, June 2015. [4] [MPP] Z. Li, etc, " BGP Extensions for Service-Oriented MPLS Path Programming (MPP) ", draft-li-idr-mpls-path-programming- 01, March 2015. 5. Acknowledgments The authors wish to acknowledge the important contributions of Shunwan Zhuang, Qiandeng Liang. Hao, et,al Expires March 6, 2016 [Page 7] Internet-Draft Flow Spec for Redirect-to-Tunnel October 2015 Authors' Addresses Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China Email: haoweiguo@huawei.com Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Lucy Yong Huawei Technologies Phone: +1-918-808-1918 Email: lucy.yong@huawei.com Hao, et,al Expires March 6, 2016 [Page 8]