One document matched: draft-hares-idr-flowspec-v2-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC4761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4761.xml">
<!ENTITY RFC4762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC6074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6074.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6482 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6482.xml">
<!ENTITY RFC6483 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6483.xml">
<!ENTITY RFC7153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7153.xml">
<!ENTITY RFC7223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7223.xml">
<!ENTITY RFC7674 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7674.xml">
<!ENTITY I-D.ietf-idr-flow-spec-v6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flow-spec-v6.xml">
<!ENTITY I-D.ietf-idr-flowspec-l2vpn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-l2vpn.xml">
<!ENTITY I-D.ietf-idr-bgp-flowspec-oid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-flowspec-oid.xml">
<!ENTITY I-D.ietf-idr-wide-bgp-communities SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-wide-bgp-communities.xml">
<!ENTITY I-D.raszuk-idr-rfc5575bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.raszuk-idr-rfc5575bis.xml">
<!ENTITY I-D.ietf-idr-flowspec-packet-rate SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.eddy-idr-flowspec-packet-rate.xml">
<!ENTITY I-D.ietf-sidr-bgpsec-protocol SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-bgpsec-protocol.xml">
<!ENTITY I-D.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-pkt-eca-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-pkt-eca-data-model.xml">
<!ENTITY I-D.ietf-i2rs-fb-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-fb-rib-data-model.xml">
<!ENTITY I-D.ietf-i2rs-fb-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-fb-rib-info-model.xml">
<!ENTITY I-D.ietf-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-acl-model.xml">
<!ENTITY I-D.ietf-netmod-opstate-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-opstate-reqs.xml">
<!ENTITY I-D.ietf-netmod-routing-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-routing-cfg.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.ietf-sidr-bgpsec-protocol SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.I-D.ietf-bgpsec-protocol.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-idr-flowspec-v2-00.txt" ipr="trust200902">
<front>
<title abbrev="BGP FlowSpec v2">BGP Flow Specification Version 2 </title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>IDR Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>BGP Flow Specification</keyword>
<abstract>
<t>BGP flow specification version 1 (RFC5575) describes the distribution
of traffic filter policy (traffic filters and actions) which are distributed
via BGP to BGP peers. Three applications utilize this traffic filter policy:
(1) mitigation of Denial of Service (DoS), (2) enabling of traffic filtering
in BGP/MPLS VPNS, and (3)centralized traffic control for networks with
SDN or NFV controllers. Application of centralized traffic utilizing
BGP Flow Specification traffic filters may need user-ordered filters
rather than RFC5575's strict ordering of filters and defined ordering of actions.
</t>
<t>This document proposes a new BGP Flow specification version 2
that supports user-order of filters and actions plus allowing more actions
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>BGP flow specification <xref target="RFC5575"></xref>
describes the distribution of filters and actions that apply when packets are received on a
router with the flow specification function turned on.
If one considers the reception of the packet as an event,
then BGP flow specification describes a set of minimalistic
Event-MatchCondition-Action (ECA) policies were the
match-condition is defined in the BGP NLRI, and the action is defined
either by the default condition (accept traffic) or actions
defined in Extended BGP Communiites values <xref target="RFC4360"></xref>.
</t>
<t>
The initial set of policy <xref target="RFC5575"></xref> and <xref target="RFC7674"></xref>
for this policy includes 12 types of match filters encoded in two application
specific AFI/SAFIs for the IPv4 AFI.
<list>
<t>IP traffic: AFI:1, SAFI, 133;
</t>
<t>BGP/MPLS VPN AFI:1 VPN SAFI, 134) for IPv4.
</t>
</list>
</t>
<t>The popularity of these flow specification filters in deployment for
DoS and SDN/NFV has led to the requirement for
more BGP flow specification match filters in the NLRI and more
BGP flow specification actions.
</t>
<t>This document describes distribution of two new BGP Flow Specification NLRI
(2 AFI/SAFI pairs) that allow user-ordered list of traffic match filters,
and user-ordered traffic match actions encoded in BGP Wide Communities.
<list style="symbols">
<t>section 2 - Definitions,</t>
<t>section 3 - Rules for dissemination of Flow Specification v2,
</t>
<t>section 4 - Optional Security, </t>
<t>section 5 - IANA considerations,</t>
<t>section 6 - security considerations.</t>
</list>
</t>
<t>The rest of this section provides background on BGP Flow Specification
filters interaction with I2RS Filter-Based RIBs carried by NETCONF/RESTCONF protocol.
Figure 1 below is a logial description of BGP Flow Specification rules
that combine filters in BGP NLRI with actions in BGP Extended communities.
</t>
<t>
<figure>
<artwork>
+-----------------------------+
| Flow Specification (FS) |
| Policy |
+-----------------------------+
^ ^
| |
| |
+--------^-------+ +-------^-------+
| FS Rule | | FS Rule |
+----------------+ +---------------+
: :
: :
......: :.....
: :
+---------V---------+ +----V-------------+
| Rule Condition | | Rule Action |
| in BGP NLRIs | | in BGP extended |
| SAFI 133, 134 | | Communities |
+-------------------+ +------------------+
: : : : : :
.....: . :..... .....: . :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------+ +--V-----++--V---+
| Match | | match | |match | | Action | | action ||action|
|Operator| |Variable| |Value | |Operator| |variable|| Value|
|*1 | | | | | |(subtype| | || |
+--------+ +--------+ +------+ +--------+ +--------++------+
*1 match operator may be complex.
Figure 1: BGP Flow Specification Policy
</artwork>
</figure>
</t>
<t>
BGP Flow Specification (BGP-FS) (<xref target="RFC5575"></xref> and
<xref target="I-D.raszuk-idr-rfc5575bis"></xref>) describes how to distribute the
BGP Flow Specification policy as BGP routes which are locally configured on
the originating BGP peer. Like BGP routes, if
the BGP peer session drops then BGP Flow Specification routes are
dropped. <xref target="RFC5575"></xref> and <xref target="I-D.raszuk-idr-rfc5575bis"></xref>
do not indicate how the BGP Flow Specification policy is installed in the kernel.
</t>
<section title="RFC5575 vs. NETCONF/RESTCONF/I2RS Flow Filters">
<t><xref target="RFC5575"></xref> describes the dissemination of
flow specification rules policy is similar to the
the statically configured Filter-Based RIB described
in <xref target="I-D.ietf-i2rs-fb-rib-data-model"></xref>, and
the I2RS Filter-Based RIB (<xref target="I-D.ietf-i2rs-fb-rib-info-model"></xref>,
<xref target="I-D.ietf-i2rs-fb-rib-data-model"></xref>,
<xref target="I-D.ietf-i2rs-pkt-eca-data-model"></xref>).
These FB-RIBs start on the reception of a packet using
match filters to match frames (L2) or packet data (L3/L4/Application),
and perform actions as shown in figure 2.
</t>
<t>
<figure>
<artwork>
+-----------+ +------------+
|Rule Group | | Rule Group |
+-----------+ +------------+
^ ^
| |
| |
+--------^-------+ +-------^-----------+
| Rule | | Rule |
+----------------+ +-------------------+
: : : :
:.................: : : :
: |.........: : :
+--V--+ +--V--+ : :
| name| |order| .........: :.....
+-----+ +-----+ : :
: :
+--------------V-------+ +--V------------+
| Rule Match condition | | Rule Action |
+----------------------+ +---------------+
: : : : : :
.....: . :..... .....: . :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+
| Match | | match | |match | | Action || action ||action|
|Operator| |variable| |Value | |Operator||Variable|| Value|
+--------+ +--------+ +------+ +--------++--------++------+
Figure 2: I2RS Filter-Based RIB Policy
</artwork>
</figure>
</t>
<t><xref target="I-D.ietf-i2rs-fb-rib-data-model"></xref>
suggests that the storage of BGP Flow Specification routes in the kernel
should utilize the same format as the statically configured FB-RIB
and the I2RS ephemeral FB-RIB so that these traffic filters may be compared.
This draft also proposes that precedence between these three sources of
filters in the kernel (statically configured, I2RS ephemeral, and BGP
ephemeral routes) can either set by local policy or defaults. If it is
set by defaults <xref target="I-D.ietf-i2rs-fb-rib-data-model"></xref>
suggests the default precedence between static, I2RS, and BGP-FS installed
filters is:
<list style="symbols">
<t>static FB-RIB -highest precedence (wins all ties)
</t>
<t>I2RS FB-RIB - middle preference (wins over BGP-FS originated routes,
loses to static FB-RIB), </t>
<t>BGP-FS installed Filters - lows preference (loses to static and I2RS FB-RIB)</t>
</list>
</t>
</section>
</section>
<section title="Definitions">
<section title="Definitions and Acronyms">
<t><list>
<t>NETCONF: The Network Configuration Protocol <xref target="RFC6241"></xref>.</t>
<t>RESTconf - http programmatic protocol to access yang modules
<xref target="I-D.ietf-netconf-restconf"></xref></t>
<t>BGPSEC - secure BGP <xref target="I-D.ietf-sidr-bgpsec-protocol"></xref>.</t>
<t>I2RS - Interface to Routing System <xref target="I-D.ietf-i2rs-architecture"></xref>.</t>
<t>BGP Session ephemeral state - state which does not survive the loss of BGP peer,</t>
<t>Ephemeral state - state which does not survive the reboot of a software module,
or a hardware reboot. Ephemeral state can be ephemeral configuration state or
operational state.</t>
<t>configuration state - state which persist across a reboot of software module within
a routing systsem or a reboot of a hardware routing device.</t>
</list>
</t>
</section>
<section title="RFC 2119 language">
<t> 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 <xref target="RFC2119"></xref>.
</t>
</section>
</section>
<section title="Dissemination of BGP Flow Specification version 2 NLRI and Wide Communities ">
<t>
The BGP Flow Specification version 2 (BGP-FS v2) uses an NRLI with the format for
AFI/SAFI (SAFI = TBD) for IP flow, and AFI/SAFI for BGP/MPLS (SAFI = TBD).
This NLRI information is encoded using MP_READ_NRI and MP_UNREACH_NLRI attributes defined in
<xref target="RFC4760"></xref>. Whenever the corresponding application does not require
Next-HOP information, this shall be encoded as zero-octet length Next Hop in the MP_REAC_NLRI
and ignored upon receipt.
</t>
<t>Implementatinos wishing to exchange flow specificastion rules MUST use
BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code
(Code 1) as defined in <xref target="RFC4760"></xref>.
</t>
<section title="Encoding of BGP-FS v2 Filters">
<t>
The AFI/SAFI NLRI for BGP Flow Specification has the format
<figure>
<artwork>
+------------------------+
|length (2 octets) |
+------------------------+
| Sub-TLVs (variable) |
| +====================+ |
| | order (2 octets) | |
| +--------------------+ |
| | type (2 octets) | |
| +--------------------+ |
| | length (2 octets) | |
| +--------------------+ |
| | value (variable) | |
| |[multiples of | |
| | 2 octets] | |
| +====================+ |
+------------------------+
Figure 16 - NRLI revision
</artwork>
</figure>
</t>
<t>
where:
<list style="symbols">
<t> length - is the length of the NLRI,</t>
<t> Sub-TLVs contain a user-ordered set of filter components
as defined in <xref target="RFC5575"></xref> and <xref target="I-D.raszuk-idr-rfc5575bis"></xref>.
The ranges are defined as: standard BGP Flow Specification filters (types 0x01 - 0x3FFFF), and vendor specific filters
(types 0x4ffff to 0x7FFFF) with type values 0x8000 to 0xFFFFFFFF reserved for future use.
Each sub-tlv has an length of 2 octets, and a variable length value (in multiples of 2 octets).
</t>
</list>
</t>
<t>Filters are process in the order specified by the user. If multiple filters exist for the same order,
the strict filter ordering defined in <xref target="RFC5575"></xref> and <xref target="I-D.raszuk-idr-rfc5575bis"></xref>
will be used for the filters with the same value for user order.
</t>
</section>
<section title="Encoding of BGP-FS v2 Actions">
<t>The BGP-FS version 2 actions are passed in a Wide Community <xref target="I-D.ietf-idr-wide-bgp-communities"></xref>
atom with the following format.
</t>
<t>
<figure>
<artwork>
+--------------------------+
| order (2 octets) |
+--------------------------+
| Action type (2 octets) |
+--------------------------+
| Action length (2 octets) |
+--------------------------+
| Action Values (variable) |
| (multiples of 2 octets) |
+--------------------------+
Wide Community Atom
figure 17
</artwork>
</figure>
</t>
<t>
where:
<list style="symbols">
<t>Action type (2 octets) - is the type of action. These actions can be
standardized (0x0001 - 0x3ffff), vendor specific (0x40000-0x7FFFF),
or reserved (0x0, 0x80000-0xFFFFFFFF).
</t>
<t>Action length - length of actions including variable field, </t>
<t>Action values - value of actions (variable) defined in individual
definitions.
</t>
</list>
</t>
<t>The BGP Flow Specification (BGP-FS) atom can be part of the Wide Community
container (type 1) or the BGP Flow Specification Atom can be part of the
BGP Flow Specification container (type 2) which will have:
<figure>
<artwork>
+-----------------------------+
| Source AS Number (4 octets)|
+-----------------------------+
| list of atoms (variable) |
+-----------------------------+
figure 18
</artwork>
</figure>
</t>
</section>
<section title="Required NLRI Validation">
<t>
Same as <xref target="RFC5575"></xref> and <xref target="I-D.raszuk-idr-rfc5575bis"></xref>.
</t>
</section>
</section>
<section title="Optional Security Additions">
<t>This section discusses the optional BGP Security additions for BGP-FS v2:
BGPSEC <xref target="I-D.ietf-sidr-bgpsec-protocol"></xref>, ROA
<xref target="RFC6482"></xref> and revised security for flow specification
distributed from a centralized server within an AS <xref target="I-D.ietf-idr-bgp-flowspec-oid"></xref>.
These optional security parameters can be applied per BGP peer.
</t>
<section title="BGP FS v2 and BGPSEC">
<t> <xref target="RFC5575"></xref> does not require BGP Flow specifications
to be passed BGPSEC <xref target="I-D.ietf-sidr-bgpsec-protocol"></xref>.
BGP FS v2 can be passed in BGPSEC, but it is not required.
</t>
</section>
<section title="BGP FS v2 with with ROA">
<t>
BGP-FS v2 can utilize ROAs in the validation. If BGP-FS v2 is
used with BGPSEC and ROA, the first thing is to vaildate the
route within BGPSEC and second to utilize BGP ROA to validate
the route origin.
</t>
<t> The BGP-FS peers using both ROA and BGP-FS validation
determine that a BGP Flow specification is valid
if and only if one of the following cases:
<list style="symbols">
<t>If the BGP Flow Specification NLRI has a IPv4 or
IPv6 address in destination address match
filter and the following is true:
<list style="symbols">
<t>A BGP ROA has been received to validate the originator, and</t>
<t>the route is the best-match unicast route for the destination
prefix embedded in the match filter; or </t>
</list>
</t>
<t>If a BGP ROA has not been received that matches the
IPv4 or IPv6 destination address in the destination filter, the
match filter must abide by the <xref target="RFC5575"></xref> validation rules of:
<list>
<t>The originator match of the flow specification matches the
originator of the best-match unicast route for the destination
prefix filter embedded in the flow specification", and
</t>
<t>No more specific unicast routes exist when compared with the
flow destination prefix that have been received from a different
neighboring AS than the best-match unicast route, which has been
determined in step A.
</t>
</list>
</t>
</list>
The best match is defined to be the longest-match NLRI with the highest preference.
</t>
</section>
<section title="Revise Flow Specification Security for centralized Server">
<t>
The distribution of Flow Specifications from a centralized server supports
mitigation of DoS attacks. <xref target="I-D.ietf-idr-bgp-flowspec-oid"></xref>
suggests the following redefined procedure for validation for this case:
</t>
<t>
A route is valid if the following conditions holds true:
<list style="symbols">
<t>The originator of the flow specification matches the
originator of the best-match unicast route for the
destination prefix embedded in the flow specification.
</t>
<t>The AS_PATH and AS4_PATH attribute of the flow
specification are empty (on originating AS)
</t>
<t>The AS_PATH and AS4_PATH attribute of the flow
specification does not contain AS_SET and AS_SEQUENCE
segments (on originating AS with AS Confederation)
</t>
</list>
</t>
<t>This reduced validation mechanism can be used for BGP-FS v2 within
a single domain.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section complies with <xref target="RFC7153"></xref>
</t>
<t> This document requests:
<list>
<t> SAFI be defined for IPv4 (AFI = 1), IPv6 (AFI=2), L2VPN (AFI=25) for BGP-FS
</t>
<t>SAFI be defined for BGP/MPLS IPv4 (AFI = 1), IPv6 (AFI=2), L2VPN (AFI=25) for BGP-FS
</t>
</list>
</t>
<t>Registry be created for BGP-FS V2 filter component types
with the following ranges:
<list>
<t>0x00 - reserved </t>
<t>0x01 - 0x3FFFF - standards action</t>
<t>0x40000- 0x7FFFF - vendor specific filters </t>
<t>0x80000 -0xFFFFFFFF - reserved </t>
<t>0x80000 -0xFFFFFFFF - reserved </t>
</list>
</t>
<t>Registry be created for BGP-FS v2 action types with the
following ranges:
<list>
<t> 0x0 - reserved </t>
<t>0x01 - 0x3ffff - standards action </t>
<t>0x40000 - 0x7ffff - vendor actions </t>
<t>0x80000 - 0xFFFFFFF - reserved </t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>The use of ROA improves on <xref target="RFC5575"></xref>
to check the route orgination is valid can improve the
validation sequence for a multiple-AS environment. The use of BGPSEC
<xref target="I-D.ietf-sidr-bgpsec-protocol"></xref> to secure the packet
can increase security of BGP flow specification information sent in the packet.
</t>
<t>The use of the reduced validation within an AS <xref target="I-D.ietf-idr-bgp-flowspec-oid"></xref>
can provide adequate validation for distribution of flow specification within an single
autonomous system for prevention of DDOS.
</t>
<t>Distribution of flow filters may provide insight into traffic being sent within
an AS, but this information should be composite information that does not reveal the
traffic patterns of individuals.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4271;
&RFC4360;
&RFC4760;
&RFC4761;
&RFC4762;
&RFC5226;
&RFC5575;
&RFC6241;
&RFC6482;
&RFC7153;
&RFC7223;
&RFC7674;
&I-D.ietf-idr-wide-bgp-communities;
&I-D.ietf-sidr-bgpsec-protocol;
&I-D.ietf-idr-bgp-flowspec-oid;
&I-D.raszuk-idr-rfc5575bis;
</references>
<references title="Informative References">
&RFC6074;
&RFC6483;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.ietf-i2rs-pkt-eca-data-model;
&I-D.ietf-i2rs-fb-rib-data-model;
&I-D.ietf-i2rs-fb-rib-info-model;
&I-D.ietf-netmod-acl-model;
&I-D.ietf-netconf-restconf;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:10:04 |