[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-simpson-idr-flowspec-redirect) 00 01 02

IDR Working Group                                             J. Uttaro
Internet-Draft                                                     AT&T
Intended status: Standards Track
Expires: Aug 2, 2015                                            J. Haas
                                                       Juniper Networks

                                                              M. Texier
                                                         Arbor Networks

                                                               A. Karch
                                                         A. Sreekantiah
                                                                 S. Ray
                                                          Cisco Systems

                                                             A. Simpson
                                                          W. Henderickx
                                                         Alcatel-Lucent

                                                            Feb 2, 2015

                    BGP Flow-Spec Redirect to IP Action
                draft-ietf-idr-flowspec-redirect-ip-02.txt


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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on Aug 2, 2015.







Simpson, et al           Expires Aug 2, 2015                   [Page 1]


Internet-Draft  draft-ietf-idr-flowspec-redirect-ip-02         Feb 2015


Copyright Notice

   Copyright (c) 2012 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.

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 [RFC 5575] defines a redirect-to-VRF action for
   policy-based forwarding but this mechanism can be difficult to use,
   particularly in networks without L3 VPN infrastructure.

   This draft defines a new redirect-to-IP flow-spec action that
   provides a simpler method of policy-based forwarding. The details of
   the action, including the IPv4 or IPv6 target address, are encoded
   in newly defined BGP extended communities.

Table of Contents


   1. Introduction...................................................3
   2. Terminology....................................................3
   3. Redirect to IP Extended Communities............................3
      3.1. Validation Procedures.....................................5
   4. Security Considerations........................................6
   5. IANA Considerations............................................6
   6. References.....................................................6
      6.1. Normative References......................................6
      6.2. Informative References....................................6
   7. Contributors...................................................7
   8. Acknowledgments................................................7





Simpson, et al.          Expires Aug 2, 2015                   [Page 2]


Internet-Draft  draft-ietf-idr-flowspec-redirect-ip-02         Feb 2015


1. Introduction

   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.

   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 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. Using the redirect-to-VRF action for
   redirecting traffic towards an alternate destination is useful for
   DDoS mitigation but it can be complex and cumbersome, particularly
   in networks without L3 VPN infrastructure.

   This draft proposes a new redirect-to-IP flow-spec action that
   provides a simpler method of policy-based forwarding. The details of
   the action, including the IPv4 or IPv6 target address, are encoded
   in newly defined BGP extended communities.

2. Terminology

   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].

3. Redirect to IP Extended Communities

   This document defines two new BGP extended communities. The extended
   communities have a type indicating they are transitive and IPv4-
   address-specific or IPv6-address-specific, depending on whether the
   redirection target address is IPv4 or IPv6. The sub-type value [to
   be assigned by IANA] indicates that the global administrator and
   local administrator fields encode a flow-spec 'redirect to IP'
   action. In the new extended communities the 4-byte or 16-byte global
   administrator field encodes the IPv4 or IPv6 address that is the
   redirection target address and the 2-byte local administrator field
   is formatted as shown in Figure 1.









Simpson, et al.          Expires Aug 2, 2015                   [Page 3]


Internet-Draft  draft-ietf-idr-flowspec-redirect-ip-02         Feb 2015


                      Figure 1 : Local Administrator

                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |          Reserved           |C|
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   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.

   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.

   When a BGP speaker receives a flow-spec route with a 'redirect to
   IP' 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 IPv4 or IPv6 address in the extended
   community's global administrator field (the 'target address').  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 redirected/copied packets based on the resulting route
   (the 'target route'). If the 'target route' has multiple ECMP next-
   hops the redirected/copied packets SHOULD be load-shared across
   these next-hops according to the router's ECMP configuration. If the
   'target route' has one or more tunnel next-hops then the appropriate
   encapsulations SHOULD be added to the redirected/copied packets. 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 multiple 'redirect
   to IP' extended communities and this route represents the one and
   only best path, it SHOULD load-share the redirected/copied packets
   across all the 'target addresses' according to its ECMP
   configuration. 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 'target addresses' it SHOULD
   deterministically select one 'target address' and ignore the others.




Simpson, et al.          Expires Aug 2, 2015                   [Page 4]


Internet-Draft  draft-ietf-idr-flowspec-redirect-ip-02         Feb 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 or more 'redirect to IP' extended communities, the BGP
   speaker SHOULD load-share the redirected/copied packets across all
   the 'target addresses', 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 or more
   'redirect to IP' extended communities and one or more 'redirect to
   VRF' extended communities, and this route represents the one and
   only best path, the 'redirect to IP' 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 IP' 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 IP' and 'redirect to VRF'
   extended communities, the BGP speaker SHOULD apply the 'redirect to
   IP' 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.

   3.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 IP' 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
   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-


Simpson, et al.          Expires Aug 2, 2015                   [Page 5]


Internet-Draft  draft-ietf-idr-flowspec-redirect-ip-02         Feb 2015


   spec route has a 'redirect to IP' extended community with a 'target
   address' X (in the global administrator field) 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 IP'
   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 IP' extended community
   is allowed to cross AS boundaries. The validation check described in
   section 3.1 significantly reduces this risk.

5. 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 IPv4'.

   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 IPv6'.

   IANA is requested to deprecate the type 0x0800 type/sub-type.


6. References

   6.1. Normative References

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

   6.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.






Simpson, et al.          Expires Aug 2, 2015                   [Page 6]


Internet-Draft  draft-ietf-idr-flowspec-redirect-ip-02         Feb 2015


   [IPV6-FLOW]      R. Raszuk, B. Pithawala, D. McPherson,
                    "Dissemination of Flow Specification Rules for
                    IPv6", draft-ietf-idr-flow-spec-v6-00, June 2011.

   [VALIDATE]       Uttaro, J., Filsfils, C., Mohapatra, P., Smith, D.,
                    "Revised Validation Procedure for BGP Flow
                    Specifications", draft-ietf-idr-bgp-flowspec-oid-
                    00, June 2012.

7. Contributors

   David Smith
   Cisco
   111 Wood Avenue South
   Iselin, NJ  08830
   USA
   E-mail: djsmith@cisco.com


8. Acknowledgments

   The authors would like to thank Han Nguyen and Robert Raszuk for
   their feedback and suggestions.

   This document was prepared using 2-Word-v2.0.template.dot.
























Simpson, et al.          Expires Aug 2, 2015                   [Page 7]


Internet-Draft  draft-ietf-idr-flowspec-redirect-ip-02         Feb 2015


Authors' Addresses

   James Uttaro
   AT&T
   200 S. Laurel Avenue
   Middletown, NJ  07748
   USA
   Email: ju1738@att.com

   Jeffrey Haas
   Juniper Networks
   1194 N. Mathida Ave.
   Sunnyvale, CA 94089
   USA
   Email: jhaas@juniper.net

   Andy Karch
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA
   Email: akarch@cisco.com

   Saikat Ray
   Cisco Systems, Inc.
   170, West Tasman Drive
   San Jose, CA  95134
   USA
   Email: sairay@cisco.com

   Pradosh Mohapatra
   Cumulus Networks
   Email: pmohapat@cumulusnetworks.com

   Wim Henderickx
   Alcatel-Lucent
   Copernicuslaan 50
   2018 Antwerp, Belgium
   Email: wim.henderickx@alcatel-lucent.be

   Adam Simpson
   Alcatel-Lucent
   600 March Road
   Ottawa, Ontario K2K 2E6
   Canada
   Email: adam.simpson@alcatel-lucent.com



Simpson, et al.          Expires Aug 2, 2015                   [Page 8]


Internet-Draft  draft-ietf-idr-flowspec-redirect-ip-02         Feb 2015


   Matthieu Texier
   Arbor Networks
   38 Rue de Berri
   75008 Paris
   Email: mtexier@arbor.net












































Simpson, et al.          Expires Aug 2, 2015                   [Page 9]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/