IDR Working Group G. Van de Velde, Ed. Internet-Draft W. Henderickx Intended status: Standards Track Alcatel-Lucent Expires: July 15, 2016 K. Patel Cisco Systems January 12, 2016 Flowspec Indirection-id Redirect draft-vandevelde-idr-flowspec-path-redirect-01 Abstract Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particular if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new redirect-to-INDIRECTION_ID (32-bit or 128-bit) flow-spec action to provide advanced redirection capabilities. When activated, the flowspec Indirection-id is used to identify the next-hop redirect information within a router locallized Indirection-id table. This allows a flowspec controller to signal redirection towards a next-hop IP address, a shortest path tunnel, a traffic engineered tunnel or a next-next-hop (traffic engineered) tunnel egress interface. 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 [1]. 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/. Van de Velde, et al. Expires July 15, 2016 [Page 1] Internet-Draft Flowspec Indirection-id Redirect January 2016 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 July 15, 2016. Copyright Notice 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. INDIRECTION_ID and INDIRECTION_ID Table . . . . . . . . . . . 3 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4 3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5 4. Redirect to INDIRECTION-ID Communities . . . . . . . . . . . 6 5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 6 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Flow-spec RFC5575 [2] is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. Van de Velde, et al. Expires July 15, 2016 [Page 2] Internet-Draft Flowspec Indirection-id Redirect January 2016 Every flow-spec route is effectively a rule, consisting of a matching part (encoded in the NLRI field) and an action part (encoded in one or more BGP extended community). The flow-spec standard RFC5575 [2] defines widely-used filter actions such as discard and rate limit; it also defines a redirect-to-VRF action for policy-based forwarding. Using the redirect-to-VRF action for redirecting traffic towards an alternate destination is useful for DDoS mitigation but using this technology can be cumbersome when there is need to redirect the traffic onto an engineered traffic path. This draft proposes a new redirect-to-Indirection-id flow-spec action facilitating an anchor point for policy-based forwarding onto an engineered path or into a service plane. The router consuming and utilizing the flowspec rule makes a local mapping between the flowspec signalled redirect Indirection-id and locally available redirection information referenced by the Indirection-id. This locally available redirection information is derived from out-of-band programming or signalling. The redirect-to-Indirection-id is encoded in a newly defined BGP extended Indirection_ID community. The construction of the Indirection-id redirect table and the technology used to create an engineered path are out-of-scope of this document. 2. INDIRECTION_ID and INDIRECTION_ID Table An INDIRECTION_ID is an abstract number (32-bit or 128-bit value) used as identifier for a localised redirection decision. e.g. When a BGP flowspec controller intends to redirect a flow using te redirect- to-INDIRECTION_ID action then it has the ability to redirect the flow to a destination abstracted as the INDIRECTION_ID. The device receiving the BGP flowspec rule will use the INDIRECTION_ID to identify the next-hop and the relevant tunnel encapsulations that need to be pushed by a localised recursive lookup using information located within the INDIRECTION_ID table. The INDIRECTION_ID Table is a router localised table. The table content is constructed out of INDIRECTION_IDs and corresponding redirect information which may be of rescursive or non-recursive nature. When the redirect information is non-recursive, then the represented information MUST be sufficient to identify the local egress interface and the corresponding required encapsulations. However, if the information is recursive, then the represented information MUST be sufficient to identify the local egress interface and corresponding encapsulations using additional recursions. Van de Velde, et al. Expires July 15, 2016 [Page 3] Internet-Draft Flowspec Indirection-id Redirect January 2016 3. Use Case Scenarios This section describes use-case scenarios when deploying redirect-to- INDIRECTION_ID. 3.1. Redirection shortest Path tunnel A first use-case is allowing a BGP Flowspec controller send a single flowspec policy message (redirect-to-INDIRECTION_ID#1) to many BGP flowspec consuming routers. This message is instructing the Flowspec recipient routers to redirect traffic onto a tunnel to a single IP destination address. For this use-case scenario, each flowspec recipient router has a tunnel configured following the shortest path towards a tunnel IP destination address. Each tunnel can have its own unique encapsulation associated. Each tunnel is associated with an INDIRECTION_ID, and for this example it is on all recipient routers INDIRECTION_ID#1. Both manual and orchestrated tunnel provisioning is supported, however for large scale deployment automation is advisable. When using this setup, a BGP flowspec controller can send a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#1. This BGP Flowspec NLRI is received by all recipient routers. Each of the recipient routers performs a locallised recursive lookup for INDIRECTION_ID#1 in the INDIRECTION_ID Table and identifies the corresponding locallised tunnel redirect information. This locallised tunnel information is now used to redirect traffic matching the Flowspec policy towards a tunnel, each potentially using its own unique tunnel encapsulation. 3.2. Redirection to path-engineered tunnels A second use-case is allowing a BGP Flowspec controller send a single flowspec policy message (redirect-to-INDIRECTION_ID#2) to many BGP flowspec consuming routers. This message is instructing the Flowspec recipient routers to redirect traffic onto a path engineered tunnel. For this use-case scenario, each flowspec recipient router has a path engineered tunnel configured. Each tunnel can have its own unique encapsulation and engineerd path associated. Each tunnel is associated with an INDIRECTION_ID, and for this example it is on all recipient routers INDIRECTION_ID#2. Both manual and orchestrated tunnel provisioning is supported, however for large scale deployment automation is advisable. Van de Velde, et al. Expires July 15, 2016 [Page 4] Internet-Draft Flowspec Indirection-id Redirect January 2016 When using this setup, a BGP flowspec controller can send a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2. This BGP Flowspec NLRI is received by all recipient routers. Each of the recipient routers performs a locallised recursive lookup for INDIRECTION_ID#2 in the INDIRECTION_ID Table and identifies the corresponding locallised tunnel redirect information. This locallised tunnel information is now used to redirect traffic matching the Flowspec policy towards a path engineered tunnel. 3.3. Redirection to Next-next-hop tunnels A Third use-case is allowing a BGP Flowspec controller send a single flowspec policy message (redirect-to-INDIRECTION_ID#3) to many BGP flowspec consuming routers. This message is instructing the Flowspec recipient routers to redirect traffic onto a shortest or engineered path to a tunnel end-point and onwards to the next-hop-interface on this end-point. This type of tunnel is used for example for Segment Routing Central Egress Path Engineering [4]. For this use-case scenario, each flowspec recipient router constructs redirect information using two tunnel components. The first component is a shortest or engineered path towards a network egress router. The second component is the interface used on this network egress router to which the redirected traffic needs to be steered upon. The combination of these two components allows steering towards the next-hop of the egress router, allowing for example the Central Egress Path Engineering using BGP Flowspec [4]. The redirection towards a next-next-hop tunnel can be done by using either a single INDIRECTION_ID representing the combined path to the egress router and steering the traffic to the egress interface, or by using individual INDIRECTION_IDs each representing a tunnel component (One INDIRECTION_ID value to identify the path towards the egress router and another INDIRECTION_ID value to identify the egress interface on this egress router towards the next-next-hop). When using individual INDIRECTION_IDs it is required to use INDIRECTION_ID community Tunnel IDs (TID) each identifying a component of the complete redirect path attached to the NLRI. i.e. when using next-next-hop tunnels, a BGP flowspec controller can send a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#3. This BGP Flowspec NLRI is received by all recipient routers. Each of the recipient routers performs a locallised recursive lookup for INDIRECTION_ID#3 in the INDIRECTION_ID Table and identifies the corresponding locallised tunnel redirect information (=path to the egress router and the next-hop egress interface on this router). Traffic matching the flowspec policy is redirected towards the recursively found redirection information. Van de Velde, et al. Expires July 15, 2016 [Page 5] Internet-Draft Flowspec Indirection-id Redirect January 2016 4. Redirect to INDIRECTION-ID Communities This document defines a new BGP extended community. The extended communities have a type indicating they are transitive and IPv4- address-specific or IPv6-address-specific, depending on whether the INDIRECTION_ID is 32-bit or 128-bit. The sub-type value [to be assigned by IANA] indicates that the global administrator and local administrator fields encode a flow-spec 'redirect to INDIRECTION_ID' action. In the new extended community the 4-byte or 16-byte global administrator field encodes the 32-bit or 128-bit INDIRECTION_ID's providing the INDIRECTION_ID to allow a local to the router mapping reference to an engineered Path. The 2-byte local administrator field is formatted as shown in Figure 1. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |TID|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 In the local administrator field 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. The 'TID' field identifies a 2 bit Table-id field. This field is used to provide the router consuming the flowspec rule an indication how and where to use the INDIRECTION_ID when redirecting traffic. All bits other than the 'C' bit in the local administrator field MUST be set to 0 by the originating BGP speaker and ignored by receiving BGP speakers. 5. Redirect using locallized INDIRECTION_ID Router Mapping When a BGP speaker receives a flow-spec route with a 'redirect to INDIRECTION_ID' 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 INDIRECTION_ID local recursed Path. The BGP speaker is expected to do a local INDIRECTION_ID Table lookup to identify the redirection information. Van de Velde, et al. Expires July 15, 2016 [Page 6] Internet-Draft Flowspec Indirection-id Redirect January 2016 The router local INDIRECTION_ID table contains a list of INDIRECTION_ID's each mapped to redirect information. The redirect information can be non-recursive (i.e. there is only one option available in the INDIRECTION_ID Table) or recursive (i.e. L3 VPN, L2 VPN, a pre-programmed routing topology, etc... ). o When the redirect information is non-recursive then the packet is redirected based upon the information found in the Table. o In case of a next-hop tunnel, the traffic matching the flowspec rule is redirected to the next-hop tunnel. This tunnel could be instantiated through various means (i.e. manual configuration, PCEP, RSVP-TE, WAN Controller, Segment Routing, etc...). o In case of redirection to a local next-hop interface, the traffic matching the flowspec rule is redirected to the local next-hop interface. o In case the INDIRECTION_ID Table lookup results in redirect information identifying an additional layer of recursion, then this will trigger the flow to be redirected based upon an additional routing lookup within the realm of the additional layer of recursion. 6. Validation Procedures The validation check described in RFC5575 [2] and revised in [3] SHOULD be applied by default to received flow-spec routes with a 'redirect to INDIRECTION_ID' extended community. 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. It is possible from a semenatics perspective to have multiple redirect actions defined within a single flowspec rule. When a BGP flowspec NLRI has a 'redirect to INDIRECTION_ID' extended community attached resulting in valid redirection then it MUST take priority above all other redirect actions emposed. However, if the 'redirect to INDIRECTION_ID' does not result in a valid redirection, then the flowspec rule must be processed as if the 'redirect to INDIRECTION_ID' community was not attached to the flowspec route and MUST provide an indication within the BGP routing table that the 'redirect to INDIRECTION_ID' resulted in an invalid redirection action. Van de Velde, et al. Expires July 15, 2016 [Page 7] Internet-Draft Flowspec Indirection-id Redirect January 2016 7. Security Considerations A system using 'redirect-to-INDIRECTION_ID' extended community can cause during the redirect mitigation of a DDoS attack result in an overflow of traffic being received by the mitigation infrastructure. 8. Acknowledgements This document received valuable comments and input from IDR working group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert Raszuk, Jeff Haas, Susan Hares and Lucy Yong 9. IANA Considerations This document requests a new sub-type from the "Transitive IPv4- Address-Specific" extended community registry. The sub-type name shall be 'Flow-spec Redirect to 32-bit Path-id'. This document requests a new sub-type from the "Transitive IPv6- Address-Specific" extended community registry. The sub-type name shall be 'Flow-spec Redirect to 128-bit Path-id'. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . 10.2. Informative References [3] Uttaro, J., Filsfils, C., Filsfils, C., Alcaide, J., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", January 2014. [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. Afanasiev, "Segment Routing Centralized Egress Peer Engineering", October 2015. Van de Velde, et al. Expires July 15, 2016 [Page 8] Internet-Draft Flowspec Indirection-id Redirect January 2016 Authors' Addresses Gunter Van de Velde (editor) Alcatel-Lucent Antwerp BE Email: gunter.van_de_velde@alcatel-lucent.com Wim Henderickx Alcatel-Lucent Antwerp BE Email: wim.henderickx@alcatel-lucent.com Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: keyupate@cisco.com Van de Velde, et al. Expires July 15, 2016 [Page 9]