IDR Working Group W. Hao Z. Li L. Yong Internet Draft Huawei Intended status: Standards Track Expires: September 2016 March 18, 2016 BGP Flow-Spec Redirect to Tunnel Action draft-hao-idr-flowspec-redirect-tunnel-01.txt Abstract This draft defines a new flow-spec action, Redirect-to-Tunnel, and a new sub-TLV for Redirect-to-Tunnel extended community. A BGP UPDATE for a flow-spec NLRI can contain the extended community. When activated, the corresponding flow packets will be encapsulated and carried via a tunnel. The redirect tunnel information is encoded in BGP Path Attribute or extended community [TUNNELENCAPS][MPP] that is carried in the BGP flow-spec UPDATE. The draft expends the tunnel encapsulation attribute [TUNNELENCAPS] 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 September 18, 2016 [Page 1] Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016 Copyright (c) 2016 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 3. Usage Rules for Redirect-to-Tunnel Action......................6 3.1. Matching Filters for Redirect Tunnel Action...............6 3.2. Other Actions Considerations..............................6 3.3. Validation Procedures.....................................6 4. Security Considerations........................................7 5. IANA Considerations............................................7 5.1. Normative References......................................7 5.2. Informative References....................................8 6. Acknowledgments................................................8 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 Hao, et al Expires September 18, 2016 [Page 2] Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016 service chaining, traffic steering and etc, the traffic needs to be redirected to a tunnel directly. Redirect-to-VRF action or redirect- to-IP action can't service this purpose. . This draft proposes a new redirect-to-tunnel flow-spec action that provides a straightforward policy-based forwarding. The details of the redirect tunnel information are encoded in BGP Path Attributes or extended communities. 2. Redirect-to-Tunnel Extended Community To support Redirect-to-Tunnel action, besides the extended communities in below per RFC5575, a Redirect-to-Tunnel extended community is defined by this draft. This extended community conveys redirecting tunnel action; the tunnel information is specified in 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 Redirect-to-Tunnel extended community 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. Hao, et al Expires September 18, 2016 [Page 3] Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016 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 [TUNNELENCAPs], the tunnel type and encapsulation information such as VXLAN, NVGRE, VXLAN-GPE are encoded in the Tunnel Encapsulation Attribute Sub-TLVs. When 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 such as RSVP-TE, LDP, Segment Routing Path and encapsulation information are encoded in BGP Extended Unicast Tunnel Attributes (See section 5.1 of [MPP]). Note that BGP Extended Unicast Tunnel Attribute is used in Centralized Controller Environment [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. When a BGP speaker receives a flow-spec route with a Redirect-to- Tunnel extended community and BGP tunnel encapsulation attribute [TUNNELENCSPS], if this route represents the one and only best path, it installs a traffic filtering rule that matches the packets described by the NLRI field; the packets matching the rules will be redirected (C=0) or copied (C=1) via the IP tunnel with remote endpoint address encoded in Remote Endpoint sub-TLV of Tunnel Encapsulation Attribute. If the 'target address' is invalid or unreachable then the extended community and the tunnel attribute SHOULD be ignored. When a BGP speaker receives a flow-spec route with a Redirect-to- Tunnel extended community and extended unicast tunnel attribute, it installs traffic filtering rules that matches the packets described by the NLRI field and the tunnel info. If BGP speaker can't resolve the tunnel locally according to the unicast tunnel attribute, then the extended community and the tunnel attribute 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 Hao, et al Expires September 18, 2016 [Page 4] Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016 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 community 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. 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 'redirect to VRF' extended community, 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 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 September 18, 2016 [Page 5] Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016 If the 'target route' has one or more tunnel next-hops then, in turn, the tunneled redirect/copy packets SHOULD be encapsulated appropriately again. 3. Usage Rules for Redirect-to-Tunnel Action 3.1. Matching Filters for Redirect Tunnel Action Redirect-to-Tunnel action can apply to different types of flow spec rules described in the NLRI field. Here are the types of flow spec rules that can have the Redirect-to-Tunnel action. Applicability for Other types of flow spec rules are for further study. o IPv4 or IPv6 o L3VPN o L2VPN o NVO3 3.2. Other Actions Considerations Flow spec rules in a NLRI can associate with one or more actions that are specified in extended communities, which means that flow spec packets will subject to a sequence of actions.[COMBO] specified default ordering precedence of actions. However some actions do not make a sense to be used with Redirect-to-Tunnel action, i.e. they have to be used in mutually exclusive. In general Redirect-to-Tunnel action can work with traffic rate in Bite, traffic rate in packet, traffic action, redirect to VRF, interface set, time actions. The use cases for Redirect-to-Tunnel action to work with other actions are for further study. Note that: the two actions that can be used with Redirect-to-Tunnel action may be in mutually exclusive usage. Memo: need a standard way to document these rules for a flow spec action. 3.3. 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 Hao, et al Expires September 18, 2016 [Page 6] Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016 [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 community 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. 4. 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. 5. 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. 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TUNNELENCAPS] E. Rosen, et al, "Using the BGP Tunnel Encapsulation Attribute without the BGP Encapsulation SAFI", draft-rosen-idr- tunnel-encaps-00, June 2015. [MPP] Z. Li, et al, "BGP Extensions for Service-Oriented MPLS Path Programming (MPP) ", draft-li-idr-mpls-path-programming-01, March 2015. Hao, et al Expires September 18, 2016 [Page 7] Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016 [COMBO] S. Hares, ''An Information Model for Basic Network Policy and Filter Rules'', draft-hares-ide-flowspec-combo-01, March 2016. 5.2. Informative References [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J.Mauch, D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, August 2009. [Redirect to IP] J.Uttaro, et al, "BGP Flow-Spec Redirect to IP Action ", draft-ietf-idr-flowspec-redirect-ip-02, February 2015. 6. Acknowledgments The authors wish to acknowledge the important contributions of Shunwan Zhuang, Qiandeng Liang. Hao, et al Expires September 18, 2016 [Page 8] Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016 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 September 18, 2016 [Page 9]