Skip to main content

Flowspec Path-id Redirect
draft-vandevelde-idr-flowspec-path-redirect-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Gunter Van de Velde , Wim Henderickx , Keyur Patel
Last updated 2016-01-07 (Latest revision 2015-09-15)
Replaced by draft-ietf-idr-flowspec-path-redirect
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state Candidate for WG Adoption
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-vandevelde-idr-flowspec-path-redirect-00
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,
              <http://xml.resource.org/public/rfc/html/rfc2119.html>.

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,
              <http://www.rfc-editor.org/info/rfc5575>.

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]