Internet DRAFT - draft-hao-idr-flowspec-redirect-tunnel
draft-hao-idr-flowspec-redirect-tunnel
IDR Working Group W. Hao
Z. Li
L. Yong
Internet Draft Huawei
Intended status: Standards Track
Expires: September 2016 March 18, 2016
BGP Flow-Spec Redirect to Tunnel Action
draft-hao-idr-flowspec-redirect-tunnel-01.txt
Abstract
This draft defines a new flow-spec action, Redirect-to-Tunnel, and a
new sub-TLV for Redirect-to-Tunnel extended community. A BGP UPDATE
for a flow-spec NLRI can contain the extended community. When
activated, the corresponding flow packets will be encapsulated and
carried via a tunnel. The redirect tunnel information is encoded in
BGP Path Attribute or extended community [TUNNELENCAPS][MPP] that is
carried in the BGP flow-spec UPDATE. The draft expends the tunnel
encapsulation attribute [TUNNELENCAPS] 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 September 18, 2016 [Page 1]
Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016
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. Redirect-to-Tunnel Extended Community..........................3
3. Usage Rules for Redirect-to-Tunnel Action......................6
3.1. Matching Filters for Redirect Tunnel Action...............6
3.2. Other Actions Considerations..............................6
3.3. Validation Procedures.....................................6
4. Security Considerations........................................7
5. IANA Considerations............................................7
5.1. Normative References......................................7
5.2. Informative References....................................8
6. Acknowledgments................................................8
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
Hao, et al Expires September 18, 2016 [Page 2]
Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016
service chaining, traffic steering and etc, the traffic needs to be
redirected to a tunnel directly. Redirect-to-VRF action or redirect-
to-IP action can't service this purpose. .
This draft proposes a new redirect-to-tunnel flow-spec action that
provides a straightforward policy-based forwarding. The details of
the redirect tunnel information are encoded in BGP Path Attributes
or extended communities.
2. Redirect-to-Tunnel Extended Community
To support Redirect-to-Tunnel action, besides the extended
communities in below per RFC5575, a Redirect-to-Tunnel extended
community is defined by this draft. This extended community conveys
redirecting tunnel action; the tunnel information is specified in
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 Redirect-to-Tunnel extended community 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.
Hao, et al Expires September 18, 2016 [Page 3]
Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016
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 [TUNNELENCAPs], the tunnel
type and encapsulation information such as VXLAN, NVGRE, VXLAN-GPE
are encoded in the Tunnel Encapsulation Attribute Sub-TLVs. When
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 such as RSVP-TE, LDP, Segment Routing Path
and encapsulation information are encoded in BGP Extended Unicast
Tunnel Attributes (See section 5.1 of [MPP]). Note that BGP Extended
Unicast Tunnel Attribute is used in Centralized Controller
Environment [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.
When a BGP speaker receives a flow-spec route with a Redirect-to-
Tunnel extended community and BGP tunnel encapsulation attribute
[TUNNELENCSPS], if this route represents the one and only best path,
it installs a traffic filtering rule that matches the packets
described by the NLRI field; the packets matching the rules will be
redirected (C=0) or copied (C=1) via the IP tunnel with remote
endpoint address encoded in Remote Endpoint sub-TLV of Tunnel
Encapsulation Attribute. If the 'target address' is invalid or
unreachable then the extended community and the tunnel attribute
SHOULD be ignored.
When a BGP speaker receives a flow-spec route with a Redirect-to-
Tunnel extended community and extended unicast tunnel attribute, it
installs traffic filtering rules that matches the packets described
by the NLRI field and the tunnel info. If BGP speaker can't resolve
the tunnel locally according to the unicast tunnel attribute, then
the extended community and the tunnel attribute 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
Hao, et al Expires September 18, 2016 [Page 4]
Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016
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 community 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.
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 'redirect to VRF' extended community, 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 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 September 18, 2016 [Page 5]
Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016
If the 'target route' has one or more tunnel next-hops then, in turn,
the tunneled redirect/copy packets SHOULD be encapsulated
appropriately again.
3. Usage Rules for Redirect-to-Tunnel Action
3.1. Matching Filters for Redirect Tunnel Action
Redirect-to-Tunnel action can apply to different types of flow spec
rules described in the NLRI field. Here are the types of flow spec
rules that can have the Redirect-to-Tunnel action. Applicability for
Other types of flow spec rules are for further study.
o IPv4 or IPv6
o L3VPN
o L2VPN
o NVO3
3.2. Other Actions Considerations
Flow spec rules in a NLRI can associate with one or more actions
that are specified in extended communities, which means that flow
spec packets will subject to a sequence of actions.[COMBO] specified
default ordering precedence of actions. However some actions do not
make a sense to be used with Redirect-to-Tunnel action, i.e. they
have to be used in mutually exclusive.
In general Redirect-to-Tunnel action can work with traffic rate in
Bite, traffic rate in packet, traffic action, redirect to VRF,
interface set, time actions. The use cases for Redirect-to-Tunnel
action to work with other actions are for further study. Note that:
the two actions that can be used with Redirect-to-Tunnel action may
be in mutually exclusive usage.
Memo: need a standard way to document these rules for a flow spec
action.
3.3. 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
Hao, et al Expires September 18, 2016 [Page 6]
Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016
[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 community 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.
4. 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.
5. 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.
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TUNNELENCAPS] E. Rosen, et al, "Using the BGP Tunnel Encapsulation
Attribute without the BGP Encapsulation SAFI", draft-rosen-idr-
tunnel-encaps-00, June 2015.
[MPP] Z. Li, et al, "BGP Extensions for Service-Oriented MPLS Path
Programming (MPP) ", draft-li-idr-mpls-path-programming-01, March
2015.
Hao, et al Expires September 18, 2016 [Page 7]
Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016
[COMBO] S. Hares, ''An Information Model for Basic Network Policy and
Filter Rules'', draft-hares-ide-flowspec-combo-01, March 2016.
5.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.
[Redirect to IP] J.Uttaro, et al, "BGP Flow-Spec Redirect to IP
Action ", draft-ietf-idr-flowspec-redirect-ip-02, February 2015.
6. Acknowledgments
The authors wish to acknowledge the important contributions of
Shunwan Zhuang, Qiandeng Liang.
Hao, et al Expires September 18, 2016 [Page 8]
Internet-Draft BGP FS Redirect-to-Tunnel Action March 2016
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 September 18, 2016 [Page 9]
