IDR Working Group G. Van de Velde Internet-Draft W. Henderickx Intended status: Standards Track Alcatel-Lucent Expires: March 17, 2016 K. Patel Cisco Systems September 14, 2015 Flowspec Path-id Redirect draft-vandevelde-idr-flowspec-path-redirect-00 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. This document defines a new redirect-to-Path-id (32-bit or 128-bit) flow-spec action to provide advanced redirection capabilities. When activated, the flowspec signalled Path-id is used to identify the next-hop redirect information within a localized to the router Path- id redirect table. The Path-id redirect table is a table providing a list of Path-id's and router local redirect information. This allows a Flowspec signalled redirect towards a next-hop IP address, next-hop local interface or next-hop (traffic engineered) tunnel 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 March 17, 2016 [Page 1] Internet-Draft Flowspec Path-id Redirect September 2015 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 March 17, 2016. 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 2. Redirect to Path-id Communities . . . . . . . . . . . . . . . 3 3. Redirect using localized Path-id Router Mapping . . . . . . . 4 4. Validation Procedures . . . . . . . . . . . . . . . . . . . . 4 5. Localized Path-id Table . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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. 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 Van de Velde, et al. Expires March 17, 2016 [Page 2] Internet-Draft Flowspec Path-id Redirect September 2015 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-Path-id flow-spec action facilitating an anchor point for policy-based forwarding onto an engineered path. The router consuming and utilizing the flowspec rule makes a local mapping between the flowspec signalled redirect Path-id and locally available redirection information referenced by the Path-id. This locally available redirection information is derived from out-of-band programming or signalling. The redirect-to-Path-id is encoded in a newly defined BGP extended Path-id community. The construction of the Path-id redirect table and the technology used to create an engineered path are out-of-scope of this document. 2. Redirect to Path-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 redirection Path-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 Path-id' action. In the new extended community the 4-byte or 16-byte global administrator field encodes the 32-bit or 128-bit Path-id's providing the redirection Path-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 Van de Velde, et al. Expires March 17, 2016 [Page 3] Internet-Draft Flowspec Path-id Redirect September 2015 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 Path-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. 3. Redirect using localized Path-id Router Mapping When a BGP speaker receives a flow-spec route with a 'redirect to Path-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 locally engineered Paths referenced by the extended community's global administrator field. The BGP speaker is expected to do a local Path-id table lookup and identify inside this table a redirect path referenced by the Flowspec Path-id community field. The router local Path-id table contains a list of Path-id's mapped to redirect information. The redirect information can be a next-hop IP address, a local next-hop Interface or a next-hop tunnel. o When the redirect information is a Next-hop IP address, then a recursive routing lookup to this destination address is performed and the traffic matching the flowspec rule is redirected to this next-hop IP address. 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 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...). 4. 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 Path-id' extended community, as it is to all types of flow-spec routes. This means that a flow-spec route with a destination prefix subcomponent SHOULD NOT be accepted from an EBGP Van de Velde, et al. Expires March 17, 2016 [Page 4] Internet-Draft Flowspec Path-id Redirect September 2015 peer unless that peer also advertised the best path for the matching unicast route. TBC (add what to check regarding Path-id and redirect-ip Next-hop usage 5. Localized Path-id Table Each router participating in the Path-id based Flowspec redirect has a locallized Path-id indexed table. The exact nature on how this table is populated is out of scope of this document. The Path-id locallized table provides a list of Path-id's, each followed by a set of Labels or encapsulation information to push for the traffic matching the flowspec rule. If the flowspec rule signals multiple Path-id communities, then it is a localized decision on the Flowspec consuming device how the set of Path-id's will be pushed upon Flowspec matching traffic. 6. Security Considerations A system using 'redirect to Path-id' extended community can cause during the redirect mitigation of a DDoS attack an overflow of traffic being received by the mitigation infrastructure. 7. Acknowledgements This document has been contributed by Adam Simpson, Mustapha Aissaoui, Jan Mertens. 8. 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'. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . Van de Velde, et al. Expires March 17, 2016 [Page 5] Internet-Draft Flowspec Path-id Redirect September 2015 [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, . 9.2. Informative References [3] Uttaro, J., Filsfils, C., Filsfils, C., Alcaide, J., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", January 2014. Authors' Addresses Gunter Van de Velde 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 March 17, 2016 [Page 6]