Generalized Redirect Action in BGP Flow Specification Routes
draft-simpson-idr-flowspec-redirect-00

The information below is for an old version of the document
Document Type Expired Internet-Draft (individual)
Authors Wim Henderickx  , Adam Simpson 
Last updated 2011-07-04
Replaced by draft-ietf-idr-flowspec-redirect-ip
Stream (None)
Formats
Expired & archived
plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-simpson-idr-flowspec-redirect-00.txt

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

Wim Henderickx (wim.henderickx@alcatel-lucent.be)
Adam Simpson (adam.simpson@alcatel-lucent.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)