Generalized Redirect Action in BGP Flow Specification Routes
draft-simpson-idr-flowspec-redirect-00
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Expired & archived
|
|
|---|---|---|---|
| Authors | Wim Henderickx , Adam Simpson | ||
| Last updated | 2011-07-04 | ||
| Replaced by | draft-ietf-idr-flowspec-redirect-ip | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)