BGP Flow-Spec Redirect to Tunnel action
draft-hao-idr-flowspec-redirect-tunnel-00

IDR Working Group                                                W. Hao
                                                                  Z. Li
                                                                Y. Lucy
Internet Draft                                                   Huawei
Intended status: Standards Track

Expires: March 2016                                     October 6, 2015

                  BGP Flow-Spec Redirect to Tunnel action
               draft-hao-idr-flowspec-redirect-tunnel-00.txt

Abstract

   This draft defines a new flow-spec action, redirect-to-Tunnel, and a
   new sub-TLV for the redirect extended community to provide
   redirecting a flow to a tunnel. A BGP UPDATE for a flow-spec NLRI
   can contain the extended community. When activated, the
   corresponding flow packets will be encapsulated by a tunnel
   encapsulation protocol and then be forward to the target IP address.
   The redirected tunnel information and target IP address are encoded
   in BGP Path Attribute [TUNNELENCAPS] [MPP] that is carried in the
   BGP flow-spec UPDATE. The draft expends the tunnel encapsulation
   attribute 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 March 5                    [Page 1]
Internet-Draft     Flow Spec for Redirect-to-Tunnel       October 2015

   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 Tunnel Extended Community........................ 3
      2.1. Validation Procedures................................... 6
   3. Security Considerations...................................... 6
   4. IANA Considerations ......................................... 6
      4.1. Normative References.................................... 7
      4.2. Informative References.................................. 7
   5. Acknowledgments ............................................. 7

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
   service chaining, traffic steering and etc, the traffic needs to be
   redirected to tunnel directly. Using the redirect-to-VRF action or
   redirect-to-IP action for this will be complex and cumbersome.

Hao, et,al              Expires March 6, 2016                 [Page 2]
Internet-Draft     Flow Spec for Redirect-to-Tunnel       October 2015

   This draft proposes a new redirect-to-tunnel flow-spec action that
   provides a straightforward solution for policy-based forwarding. The
   details of the redirected tunnel information are encoded in already
   existing defined BGP Path Attributes.

2. Redirect to Tunnel Extended Community

   To support ''Redirect to Tunnel'', besides the extended communities in
   below per RFC5575, a new extended community of ''Redirect to Tunnel''
   is defined by this draft. This redirect extended community allows
   the traffic to be redirected to a set of tunnel(s) that are
   specified by 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 new extended community for ''Redirect to Tunnel'' 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.

   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, the tunnel type and
   encapsulation information such as VXLAN, NVGRE, VXLAN-GPE are
   encoded in the Tunnel Encapsulation Attribute Sub-TLVs. When

Hao, et,al              Expires March 6, 2016                 [Page 3]
Internet-Draft     Flow Spec for Redirect-to-Tunnel       October 2015

   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 and encapsulation information such as RSVP-TE,
   LDP, Segment Routing Path are encoded in BGP Extended Unicast Tunnel
   Attributes ([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.

   The following of this Section specifies a flow-spec to be redirect
   to the tunnel that is specified by BGP tunnel encapsulation
   attribute [TUNNELENCAPS]. A flow-spec to be redirected to a tunnel
   that is specified by the BGP extended unicast tunnel attribute will
   be addressed in future version.

   When a BGP speaker receives a flow-spec route with a 'redirect to
   Tunnel' 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 target IPv4 or IPv6 address encoded in
   Remote Endpoint sub-TLV of Tunnel Encapsulation Attribute. 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 tunneled redirected/copied packets based on the
   resulting route (the 'target route'). 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 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 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 communities
   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.

Hao, et,al              Expires March 6, 2016                 [Page 4]
Internet-Draft     Flow Spec for Redirect-to-Tunnel       October 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 '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 or more 'redirect to IP' extended communities; local
   policy determines which 'redirect' should be used.

   If a BGP speaker receives a flow-spec route with one 'Redirect to
   Tunnel'' and one or more 'redirect to VRF' extended communities, 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 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 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 March 6, 2016                 [Page 5]
Internet-Draft     Flow Spec for Redirect-to-Tunnel       October 2015

   If the 'target route' has one or more tunnel next-hops then, in turn,
   the tunneled redirect/copy packets SHOULD be encapsulated
   appropriately again.

2.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 tunnel' extended community, as it is to all
   types of flow-spec routes and the validation check described in
   [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 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-
   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.

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

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

Hao, et,al              Expires March 6, 2016                 [Page 6]
Internet-Draft     Flow Spec for Redirect-to-Tunnel       October 2015

4.1. Normative References

   [1]  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

         Requirement Levels", BCP 14, RFC 2119, March 1997.

4.2. Informative References

   [1]   [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J.Mauch,
         D. McPherson, "Dissemination of Flow Specification Rules", RFC
         5575, August 2009.

   [2]  [Redirect to IP] J.Uttaro, etc, " BGP Flow-Spec Redirect to IP
         Action ", draft-ietf-idr-flowspec-redirect-ip-02, February
         2015.

   [3]  [TUNNELENCAPS] E. Rosen, etc, " Using the BGP Tunnel
         Encapsulation Attribute without the BGP Encapsulation SAFI  ",
         draft-rosen-idr-tunnel-encaps-00, June 2015.

   [4]  [MPP] Z. Li, etc, " BGP Extensions for Service-Oriented MPLS
         Path Programming (MPP) ", draft-li-idr-mpls-path-programming-
         01, March 2015.

5. Acknowledgments

   The authors wish to acknowledge the important contributions of
   Shunwan Zhuang, Qiandeng Liang.

Hao, et,al              Expires March 6, 2016                 [Page 7]
Internet-Draft     Flow Spec for Redirect-to-Tunnel       October 2015

   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 March 6, 2016                 [Page 8]