One document matched: draft-simpson-idr-flowspec-redirect-00.txt
Network Working Group Wim Henderickx
Internet Draft Adam Simpson
Intended status: Standards Track Alcatel-Lucent
July 4, 2011 July 4, 2011
Expires: Jan 4, 2012
Generalized Redirect Action in BGP Flow Specification Routes
draft-simpson-idr-flowspec-redirect-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF 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 Jan 4, 2012.
Copyright Notice
Copyright (c) 2010 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
Simpson, et al Expires Jan 4, 2012 [Page 1]
Internet-Draft draft-ietf-flowspec-redirect-00 July 2011
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Abstract
Flowspec is an extension to BGP that allows for the dissemination of
traffic flow specifications. This has several applications, but one
of key interest to many network operators is network-wide
distribution of traffic filtering rules as part of a threat
mitigation strategy.
Every flowspec route is effectively a rule, consisting of a matching
part (encoded in the NLRI field) and an action part. The current
standards support common filter actions including discard, rate
limit, sample, etc. and all of these actions are encoded in BGP
extended communities. For policy-based forwarding the current
standards also define a redirect-to-VRF action (again encoded in a
BGP extended community), but for some flowspec applications this can
be complex to implement, particularly in networks where L3 VPNs are
not prevalent.
This draft proposes a generalized flowspec redirect action that
allows a more complete set of policy-based forwarding actions to be
signaled with a flowspec route. This generalized action is encoded in
a BGP path attribute and uses a TLV-style encoding for future
extensibility. Two redirect action TLVs are defined in this draft:
one for redirecting matched packets towards a remote IPv4 destination
and the other for redirecting matched packets towards a remote IPv6
destination. Many routers already support these filter actions in the
datapath and so the proposed flowspec extensions are simply filling a
control plane gap.
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. The Generalized Flowspec Redirect Attribute....................3
4. Security Considerations........................................5
5. IANA Considerations............................................5
6. References.....................................................6
6.1. Normative References......................................6
6.2. Informative References....................................6
7. Acknowledgments................................................6
Simpson, et al. Expires Jan 4, 2012 [Page 2]
Internet-Draft draft-ietf-flowspec-redirect-00 July 2011
1. Introduction
Flowspec is an extension to BGP that allows for the dissemination of
traffic flow specifications. This has several applications, but one
of key interest to many network operators is network-wide
distribution of traffic filtering rules as part of a threat
mitigation strategy.
Every flowspec route is effectively a rule, consisting of a matching
part (encoded in the NLRI field) and an action part. The current
standards support common filter actions including discard, rate
limit, sample, etc. and all of these actions are encoded in BGP
extended communities. For policy-based forwarding the current
standards also define a redirect-to-VRF action (again encoded in a
BGP extended community), but for some flowspec applications this can
be complex to implement, particularly in networks where L3 VPNs are
not prevalent.
This draft proposes a generalized flowspec redirect action that
allows a more complete set of policy-based forwarding actions to be
signaled with a flowspec route. This generalized action is encoded in
a BGP path attribute and uses a TLV-style encoding for future
extensibility. Two redirect action TLVs are defined in this draft:
one for redirecting matched packets towards a remote IPv4 destination
and the other for redirecting matched packets towards a remote IPv6
destination. Many routers already support these filter actions in the
datapath and so the proposed flowspec extensions are simply filling a
control plane gap.
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. The Generalized Flowspec Redirect Attribute
All of the actions defined in the current flowspec standards,
[RFC5575] and [IPv6-FLOW], are encoded using BGP extended
communities. While it would be desirable to define new BGP extended
communities for the new types of redirect action called for in this
document the maximum length of extended communities (7 octets of
data) makes this very limiting.
This document therefore proposes a new BGP path attribute called the
Generalized Flowspec Redirect Attribute. It is a transitive, optional
attribute of non-extended length. The value field of the path
Simpson, et al. Expires Jan 4, 2012 [Page 3]
Internet-Draft draft-ietf-flowspec-redirect-00 July 2011
attribute contains exactly one Redirect Action TLV, which has the
structure shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~
~ Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect Action TLV
Figure 1
The Redirect Action TLV has the following fields:
- Type: A single octet encoding the TLV Type. Only type 1, "Remote
IPv4 Address", and type 2 "Remote IPv6 Address" are defined in this
document.
- Length: A single octet encoding the length in octets of the TLV,
including the type and length fields. The length is encoded as an
unsigned binary integer.
- Value: A value field that contains type-dependent data. In a type 1
"Remote IPv4 Address" TLV the value field contains a 4-octet AS value
followed by a 4-octet IPv4 address. In a type 2 "Remote IPv6 Address"
TLV the value field contains a 4-octet AS value followed by a 16-
octet IPv6 address.
When a system originates a flowspec route with the intent to redirect
matched packets to a remote IPv4 address, it includes a Generalized
Flowspec Redirect Attribute containing a "Remote IPv4 Address"
Redirect Action TLV (type 1). The AS number in the TLV MUST be the AS
number of the associated IPv4 address (this will typically be the
same as the originator's AS number) or 0, if the AS number is unknown
to the originator. A 2-octet ASN is encoded in the low-order 2 octets
of the AS number field. The IPv4 address in the TLV is any routable
/32 unicast IPv4 address.
Simpson, et al. Expires Jan 4, 2012 [Page 4]
Internet-Draft draft-ietf-flowspec-redirect-00 July 2011
When a system originates a flowspec route with the intent to redirect
matched packets to a remote IPv6 address, it includes a Generalized
Flowspec Redirect Attribute containing a "Remote IPv6 Address"
Redirect Action TLV (type 2). The AS number in the TLV MUST be the AS
number of the associated IPv6 address (this will typically be the
same as the originator's AS number) or 0, if the AS number is unknown
to the originator. A 2-octet ASN is encoded in the low-order 2 octets
of the AS number field. The IPv6 address in the TLV is any routable
/128 unicast IPv6 address.
A flowspec route MUST NOT have more than one Generalized Flowspec
Redirect Attribute. Error handling must follow the procedures
outlined in [OPT-TRANS].
A flowspec route that has a Generalized Flowspec Redirect Attribute
in addition to one or more of the BGP extended community actions
defined in [RFC5575] and [IPV6-FLOW] is valid but implementations MAY
choose to ignore some or all of the BGP extended community actions
when installing a filter entry for this type of route.
A router that receives a flowspec route with a Generalized Flowspec
Redirect Attribute MAY check that the AS number in the Redirect
Action TLV (if non-zero) is the origin AS associated with its route
to the indicated remote IP address. In this case, if the AS numbers
are found to be different the router SHOULD NOT install a filter
entry for the flowspec route.
When a router receives and installs a flowspec route with a
Generalized Flowspec Redirect Attribute the resultant filter entry
should forward matched packets to the interface that is the IP next-
hop towards the signaled "Remote IPv4 Address" or "Remote IPv6
Address". The remote address may be any number of IP forwarding next-
hops away from the router installing the flowspec route. In certain
deployments the IP next-hop towards the remote IP address may be an
IP or MPLS tunnel.
4. Security Considerations
TBD
5. IANA Considerations
This document requests that IANA allocate a new BGP path attribute
type number for the Generalized Flowspec Redirect Attribute. IANA
should also establish and maintain a registry for Redirect Action
TLVs and indicate the meaning of type 1 and type 2 in this context.
Simpson, et al. Expires Jan 4, 2012 [Page 5]
Internet-Draft draft-ietf-flowspec-redirect-00 July 2011
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.
[IPV6-FLOW] R. Raszuk, B. Pithawala, D. McPherson,
"Dissemination of Flow Specification Rules for
IPv6", draft-ietf-idr-flow-spec-v6-00, June 2011.
[OPT-TRANS] J. Scudder, E. Chen, "Error Handling for Optional
Transitive BGP Attributes", draft-ietf-idr-optional-
transitive-03, Sept 2010.
7. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
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 Jan 4, 2012 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 10:22:13 |