One document matched: draft-vandevelde-idr-flowspec-path-redirect-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 05:31:57 |