One document matched: draft-hares-idr-flowspec-combo-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 RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.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 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 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-wide-bgp-communities SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-wide-bgp-communities.xml">
<!ENTITY I-D.eddy-idr-flowspec-exp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.eddy-idr-flowspec-exp.xml">
<!ENTITY I-D.eddy-idr-flowspec-packet-rate SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.eddy-idr-flowspec-packet-rate.xml">
<!ENTITY I-D.hao-idr-flowspec-nvo3 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hao-idr-flowspec-nvo3.xml">
<!ENTITY I-D.hao-idr-flowspec-redirect-tunnel SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hao-idr-flowspec-redirect-tunnel.xml">
<!ENTITY I-D.liang-idr-bgp-flowspec-label SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.liang-idr-bgp-flowspec-label.xml">
<!ENTITY I-D.liang-idr-bgp-flowspec-time SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.liang-idr-bgp-flowspec-time.xml">
<!ENTITY I-D.litkowski-idr-flowspec-interfaceset SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.litkowski-idr-flowspec-interfaceset.xml">
<!ENTITY I-D.li-idr-flowspec-rpd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.li-idr-flowspec-rpd.xml">
<!ENTITY I-D.vandevelde-idr-flowspec-path-redirect SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vandevelde-idr-flowspec-path-redirect.xml">
<!ENTITY I-D.wu-idr-flowspec-yang-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wu-idr-flowspec-yang-cfg.xml">
<!ENTITY I-D.rosen-idr-tunnel-encaps SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosen-idr-tunnel-encaps.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.hares-i2rs-pkt-eca-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-pkt-eca-data-model.xml">
<!ENTITY I-D.hares-i2rs-fb-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-fb-rib-data-model.xml">
<!ENTITY I-D.kini-i2rs-fb-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kini-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-combo-00.txt" ipr="trust200902">
<front>
<title abbrev="BNP Generic Policy/Filter IM">An Information Model for Basic Network Policy and Filter Rules </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 (RFC5575) 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-Match Condition-Action policies.
The initial set of policy (RFC5575 and RFC7674) for this
policy includes 12 types of match filters encoded in the NLRI
for two types of SAFIs (IP-only SAFI, 133; VPN SAFI, 134) for IPv4.
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 provides rules for combining new flow specification
packet ECA policies which support IPv6, L2, nvo03 and MPLS match filters,
and new actions. This document also provides rules for the interaction of
IDR Flow Specification policy (session ephemeral policy) with policy found in
I2RS (reboot ephemeral policy), and policy found in ACLs and Policy routing
(configuration policy).
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> Section 1 of this draft contains an introduction to BGP flow specification
<xref target="RFC5575"></xref> and drafts expanding the RFC5575 state.
Section 2 contains the definitions related to this draft.
Section 3 provides an overview of existing and proposed flow specification policy
rules decribed in terms of packet event, packet match conditions,
and actions (packet forwarding or packet match).
The flow specification policies reviewed include policy in RFCs (<xref target="RFC5575"></xref>,
<xref target="RFC7674"></xref>), IDR WG documents (<xref target="I-D.ietf-idr-flow-spec-v6"></xref>,
<xref target="I-D.ietf-idr-flowspec-l2vpn"></xref>), and the following proposed IDR WG documents
<list style="symbols">
<t><xref target="I-D.eddy-idr-flowspec-packet-rate"></xref> (traffic limiting by packet rate),
</t>
<t><xref target="I-D.eddy-idr-flowspec-exp"></xref> (Extensions for BGP security and others),
</t>
<t><xref target="I-D.hao-idr-flowspec-nvo3"></xref> (flow specification for inner/outer nv03 forwarding),
</t>
<t><xref target="I-D.hao-idr-flowspec-redirect-tunnel"></xref> (redirect to tunnel),
</t>
<t><xref target="I-D.li-idr-flowspec-rpd"></xref> (Additions to BGP FlowSpecification in Attribute),
</t>
<t><xref target="I-D.liang-idr-bgp-flowspec-label"></xref> MPLS label related filters and actions,
</t>
<t><xref target="I-D.liang-idr-bgp-flowspec-time"></xref> Filters by time,
</t>
<t><xref target="I-D.litkowski-idr-flowspec-interfaceset"></xref>Filters applied by order for Interface group, and
</t>
<t><xref target="I-D.vandevelde-idr-flowspec-path-redirect"></xref>Filters applied to packet identifier,
</t>
</list>
</t>
<t>Section 4 describes the default precedence order for BGP flow specification policy
based on Flow Specification packet events, packet match conditions, and the
packet match actions; and a extended community action to be used for "ordering action".
Initial validation rules requires the passing of a IPv4 route
associated with the BGP Flow specification rules. Section 4 also provides
proposes new rules for validating BGP Flow Specification routes based on
the new technologies of BGP ROAs (<xref target="RFC6482"></xref>, <xref target="RFC6483"></xref>)
and BGPSEC protocol <xref target="I-D.ietf-sidr-bgpsec-protocol"></xref>.
Section 5 expands this precedence order to specify how the current
BGP Flow specification interacts with the following non-BGP Filter packet filter forwarding specifications:
<list style="symbols">
<t>I2RS Filter-Based RIB (<xref target="I-D.kini-i2rs-fb-rib-info-model"></xref>,
<xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>),</t>
<t>Policy Routing (aka Filter RIB), and </t>
<t>ACLs.</t>
</list>
</t>
<t>
Section 6 suggests the benefits of creating a Flow Specification version 2
with a new NRLI encoding that can allow ordering of flow specification filters and actions.
Section 8 describes changes for the proposed Flow Specification Yang Module
(<xref target="I-D.wu-idr-flowspec-yang-cfg"></xref>.
</t>
<t>
Section 9 discusses the security considerations for all the BGP
Flow Specifications.
</t>
<section title="Overview of RFC5575">
<t><xref target="RFC5575"></xref> describes the dissemination of
flow specification rules via groups BGP Multi-Protocol NLRIs and
BGP communities. A flow specification operates on packets received
in a router when the flow specification feature is configured.
The flow specification specifies match conditions for filters
for packets received by a router and actions to do
based on a match of those filters. If one considers the
reception of a packet as an event, then a BGP flow specifications
can be considered a set of minimalistic
Event-Match Condition-Action policies (ECA policies). This set is minimalistic
because there is only one event - the reception of a packet.
BGP Flow specifications are BGP policy passed between peers.
</t>
<t>The BGP flow specification policy is specified in filters contained in the
MP-BGP NLRIs and actions contained within BGP Extended communities.
The BGP peer propagates the flow-specifications between domains in
order to automate inter-domain coordination of traffic filtering.
Two applications that are using this are: distributed denial of
service attack suppression and traffic filtering in BGP/MPLS VPN service.
BGP. BGP flow specifications use SAFI 133 non-VPN flow specifications,
and SAFI 134 for BGP VPN flow specificatinos.
</t>
<t>BGP Flow specification are validated based on:
<list>
<t>a) originator of flow specification matching the originator of the
best-match unicast route for the destination prefix
embedded in the flow specification, and
</t>
<t>b) no more specific unicast routes, when compared with flow
destination prefix, that have been received from differenting
neighboring AS than the best-match unicast route
</t>
</list>
Originator is specified by BGP originator path attribute or
transport address of the BGP peer sending the BGP Flow specification.
To support BGP flow specification, implementations are required to
enforce the neighbor AS in the AS_PATH attribute is in the
left-most position of AS_PATH.
</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 | | | | | |(type-) || || |
+--------+ +--------+ +------+ +--------++--------++------+
*1 match operator for Types 3-12. Match operator supports
pairs of matching operators.
Figure 1: BGP Flow Specification Policy
</artwork>
</figure>
</t>
<t>Match operators includes a sequence of match operations
each with the form [op, value] where match can match values
greater, lessthan, or equal to teh value. The sequence of
match operators can be combined as logical AND or ORs.
</t>
</section>
<section title="Flow Specifications: Ephemeral or not? ">
<t>
BGP Flow specification does not indicate what happens to the
flow specifications if a BGP peering session closes.
<xref target="RFC5575"></xref> specifies a link to received "best-match"
unicast routes, but does not provide any standard way of
determining whether the flow specification sent by the BGP peer is
kept after the BGP session closes. It is unclear whether
BGP Flow specifications disappear when a BGP session closes (denoted
as BGP session ephemeral), or disapppear when the BGP module's hardware or
software reboots (reboot ephemeral), or it is kept like
configuration state that survives a reboot.
This document in section 5 proposes that BGP Flow Specification is
by default considered BGP session ephemeral disappearing when the
BGP Session closes, and processes a precedence between the different types
of ephemeral state.
</t>
<t>Why is this precedence needed?
</t>
<t><xref target="RFC5575"></xref> states that Flow specification
takes advantage of the "ACL" feature (section 1), but it does not
state how BGP Flow specification interacts with ACL features.
NETCONF <xref target="RFC6241"></xref> or RESTCONF
<xref target="I-D.ietf-netconf-restconf"></xref>
can be used to set ACL configuration state using
the <xref target="I-D.ietf-netmod-acl-model"></xref>
yang data module.
</t>
<t><xref target="I-D.litkowski-idr-flowspec-interfaceset"></xref>
proposes an action which defines that a specific ordering of
BGP flow-specifications and ACLs interaction for a set of interfaces
for the drop/forward actions (see section 5.2 for a review).
Section 5.1 proposes a default precedence between different types of
flow Specification and an action. Section 5.2 proposed an action which
augments <xref target="I-D.litkowski-idr-flowspec-interfaceset"></xref>
to set an alternate order of precedence of flow specification drafts.
</t>
<t>I2RS Filter-Based RIB (FB-RIB) also specifies another way to do flow
filtering per packet/frame being received
(<xref target="I-D.kini-i2rs-fb-rib-info-model"></xref>,
<xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>)
using a packet filter event-match_condition-action policy
(draft-hares-i2rs-pkt-eca-data-model).
I2RS protocol allows a I2RS Client to talk to an I2RS Agent
within a routing device (<xref target="I-D.ietf-i2rs-architecture"></xref>)
to set ephemermal policy which is module ephemeral and box ephemeral.
Similar to BGP flow specification, the I2RS Filter-Based
RIBs focus on a minimalistic event-match_condition-action (ECA)
policy with a single event - the reception of a packet/frame on by a routing device.
The I2RS match_conditions examine frame/packet information (L1-L4, NV03,
and SFC), and I2RS match_actions that modify packet/frame information.
Figure 2 shows the structure of packet filtering ECA rules
from draft-hares-i2rs-pkt-eca-data-model)
used by I2RS Filter-Based RIB (FB-RIB). Note that these
each rule has policy rule name,
policy rule order number, and rule status.
</t>
<t>
Section 5 compares the filters and actions between
BGP Flow Specification, I2RS Filter-Based RIB,
Filter-RIB (aka Policy-Based Routing), and the ACL.
The I2RS packet filter rules also allow the rule to be ordered and
named. I2RS flow-based filters are ephemeral state
<xref target="I-D.ietf-i2rs-ephemeral-state"></xref>
are stored as ephemeral state which is lost upon a reboot.
</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>
</section>
<section title="BGP Flow Specification and logging">
<t><xref target="RFC5575"></xref> specifies the Traffic Action
Extended Community which specifies a Terminal (T) action flag and Sampling (S) flag.
The sample flag indicates that "traffic sampling and logging"
[is enabled] for a set of flow specifications in a BGP packet.
the details of traffic sampling and logging are not specified in
this standard. Logging and sampling provide valuable information
to establish the impact of BGP Flow specification in order to
automatic intra-AS DoS prevention or inter-AS automation of DOS or
VPN traffic filters. <xref target="RFC5575"></xref> was
written before the advent of yang modules that specify operational
state <xref target="I-D.ietf-netmod-opstate-reqs"></xref>.
<xref target="I-D.wu-idr-flowspec-yang-cfg"></xref>
proposes a BGP Flow Specification Yang Data model with
BGP Flow Specification configuration, operational state for BGP Flow specifications
received from peers (BGP Session Ephemeral state), and statistics on
the use of filters, actions, and dropped packets.
Section 7 describes how the logging and notifications
for BGP Flow specifications can be added to this yang module.
</t>
</section>
<section title="BGP Flow Specification 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>.
<xref target="RFC5575"></xref> states "as long as traffic filtering
rules are restricted to match the corresponding unicast routing
paths for relevant prefixes, the security characteristics of this
protocol are equivalent to existing security properties of
BGP unicast properties", and "where this is not the case, this would
open the door to further denial of service attack" (section 10).
<xref target="I-D.eddy-idr-flowspec-exp"></xref> suggests passing BGP
Flow Specification in BGPSEC. Section 10 summarizes the security issues
with the current <xref target="RFC5575"></xref> and the enhancements described
in this draft, and discusses the proposed fixes that
that <xref target="I-D.eddy-idr-flowspec-exp"></xref> provides.
</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>ephemeral - state which does not survive a particular event.</t>
<t>BGP Session ephemeral state - state which does not survive the loss of BGP peer,</t>
<t>Reboot ephemeral state - state which does not survive the reboot of a software module,
or a hardware reboot.</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="BGP Flow Specification Policy - Original and Expansions">
<section title="Packet Reception Event">
<t>The reception of a packet is the event that causes the BGP policy to
enact. By default the BGP Flow specification applies to all interfaces.
This can be restricted by a BGP Flow Specification Action or policy
local to a node running the BGP peer session.
</t>
<t>
The definition of a packet is not limited to a IP packet (IPv4 or IPv6)
but also includes mpls packets, L2 frames (802.1Q), encapsulated packets
(NVGRE or VXLAN or any other NV03 encapsulation).
</t>
<t>
The same definition of the event is utilized by the I2RS Filter-based RIBs
(<xref target="I-D.kini-i2rs-fb-rib-info-model"></xref> and
<xref target="I-D.hares-i2rs-fb-rib-data-model"></xref> and the Filter-Based RIBs
(draft-hares-rtgwg-fb-rib-data-model), and ACL filters
<xref target="I-D.ietf-netmod-acl-model"></xref>.
</t>
<t>
These packet events are the standardized packet events. Additional packet events
for vendors may augment these standards events.
</t>
</section>
<section title="BGP Flow Specification Match Filters">
<t><xref target="RFC5575"></xref> defines match conditions for IPv4 to be carried
with the NLRI format for 12 types of packet match events (see figure 3), and
that all filters specified must be combined by a "AND". The proposed expansions
to this filter list utilizing the Flow Specification NLRI are listed in
figure 4. <xref target="I-D.li-idr-flowspec-rpd"></xref> proposed a
BGP Attribute which contains additional flow specification filters, and
actions. Figure 5 contains the match filters from this draft.
</t>
<t>
The proposals to expand flow specification beyond
<xref target="RFC5575"></xref> filter specifications include:
<list style="symbol">
<t> Matches for the inner-outer header for encapsulated traffic for
being specified for the NV03 networks (MF-1, MF-2, MF-3) in
<xref target="I-D.hao-idr-flowspec-nvo3"></xref>,
</t>
<t>extended match filters carried in BGP attribute
which includes time (MF-5) for enacting flow-specification filter rules
(<xref target="I-D.li-idr-flowspec-rpd"></xref>,
<xref target="I-D.liang-idr-bgp-flowspec-time"></xref>).
</t>
</list>
</t>
<t>
One filter that seems obvious is the filter for the MPLS
labels. However, no proposal includes this Match filter for MPLS.
</t>
<t>
The precedence order for the match filter rules was specified
in <xref target="RFC5575"></xref> and expanded in
<xref target="I-D.ietf-idr-flowspec-l2vpn"></xref>. The
combined precedence is shown in figure 4.
</t>
<t>
<figure>
<artwork>
Table 1: IDR WG BGP Flow Specification Match Filter
+------+--------------------+-------------+-----------------------+
|type# | Type Name | Match | Reference |
+======+====================+=============+=======================+
| 1 | Destination Prefix | IPv4 Prefix | RFC5575 |
| | | IPv6 Prefix | ietf-idr-flow-spec-v6 |
| 2 | Source Prefix | IPv4 Prefix | RFC5575 |
| | | IPv6 Prefix | ietf-idr-flow-spec-v6 |
| 3 | IP protocol |IPv4 Protocol| RFC5575 |
| | | number | |
| 3 | Next Header |IPv6 protocol| ietf-idr-flow-spec-v6 |
| 4 | Port (source or | Port number | RFC5575 |
| | destination port) | | RFC5575 |
| 5 | Source port | Port number | RFC5575 |
| 6 | Destination port | Port number | RFC5575 |
| 7 | ICMP type | ICMP type | RFC5575 |
| 8 | ICMP code | ICMP code | RFC5575 |
| 9 | TCP Flags | 1 or 2 byte | RFC5575 |
| | | bitmask for | RFC5575 |
| | | TCP flags | |
| 10 | Packet length | # of bytes | RFC5575 |
| | (for IP packet) | | |
| 11 | DSCP | IPv4 DSCP | RFC5575 |
| | | (6 bit mask)| RFC5575 |
| 11 | Traffic class | IPv6 traffic| ietf-idr-flow-spec-v6 |
| | | (8 bit mask)| |
| 12 | IPv4 Fragment | 4 bit mask | RFC5575 |
| 13 | IPv6 Flow | 20 bit flow | ietf-idr-flow-spec-v6 |
| 14 | Ethernet type | 2 bytes |ietf-idr-flowspec-l2vpn|
| 15 | Source MAC | MAC address |ietf-idr-flowspec-l2vpn|
| 16 | Destination MAC | MAC Address |ietf-idr-flowspec-l2vpn|
| 17 | DSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn|
| 18 | SSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn|
| 19 | LLC Control field | 1 octet |ietf-idr-flowspec-l2vpn|
| 20 | SNAP | 5 octets |ietf-idr-flowspec-l2vpn|
| 21 | VLAN ID | 1 or 2 bytes|ietf-idr-flowspec-l2vpn|
| 22 | VLAN COS | 3 bit COS |ietf-idr-flowspec-l2vpn|
| 23 | Inner VLAN ID | 1 or 2 bytes|ietf-idr-flowspec-l2vpn|
| 24 | Inner VLAN COS | 1 or 2 bytes|ietf-idr-flowspec-l2vpn|
+======+====================+=============+=======================+
Figure 3
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
Table 2: Proposed BGP Flow Specification Match Condition Filters
+------+--------------------+-------------+-----------------------+
|type# | Type Name | Match | Reference |
+======+====================+=============+=======================+
| MF-1 | Delimiter type | 2 bytes | hao-idr-flowspec-nv03 |
| | (Encapsulation type| | |
| | VXLAN or NVGRE) | | |
| | | | |
| MF-2 | VNID | 24 bit VN | hao-idr-flowspec-nv03 |
| |(virtual network ID)| | |
| | | | |
| MF-3 | Flow ID |8 bit flow ID| hoa-idr-flowspec-nv03 |
| | (NVGRE Flow ID ) | | |
| | | | |
| MF-4 | MPLS LSP | TBD | not specified |
| |(label 20 bits, | Label stack | |
| | EXP (3 bits), S Bit| | |
| | TTL (8 bits) | | |
| | | | |
| MF-5 | Interface | TBD | not specified |
| |(Group ID, intf id) | | |
+======+====================+=============+=======================+
Figure 4
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
Table 3: Proposed BGP Flow Specifications Match in BGP Attribute
+------+--------------------+-------------+-----------------------+
|type# | Type Name | Match | Reference |
+======+====================+=============+=======================+
| MF-6 | Time | ?? | liang-idr-bgp-flowspec|
| | | | -time |
| MF-7 | Policy from IPv4 | ?? | li-idr-flowspec-rpd |
| | Neighbor | ?? | |
| MF-8 | Policy from IPv6 | ?? | li-idr-flowspec-rpd |
| | Neighbor | ?? | |
| MF-9 | Policy with ASpath | ?? | li-idr-flowspec-rpd |
+======+====================+=============+=======================+
Figure 5
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
Precedence logic for BGP Flow Specifications
(RFC5575, draft-idr-bgp-flowspec-l2vpn)
flow-rule-cmp (a,b)
{
comp1 = next_component(a);
comp2 = next_component(b);
while (comp1 || comp2) {
// component_type returns infinity on end of list
if (component_type(comp1) < component_type(comp2)) {
return A_HAS_PRECEDENCE;
}
if (component_type(comp1) > component_type(comp2)) {
return B_HAS_PRECEDENCE;
}
// IP values)
if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) {
common = MIN(prefix_length(comp1),prefix_length(comp2));
cmp = prefix_compare (comp1,comp2,common);
// not equal, lowest value has precedence
// equal, longest match has precedence;
} else if (component_type (comp1) == MAC_DESTINATION ||
MAC_SOURCE) {
common = MIN(MAC_address_length(comp1),
MAC_address_length(comp2));
cmp = MAC_Address_compare(comp1,comp2,common);
//not equal, lowest value has precedence
//equal, longest match has precedence
} else {
common = MIN(component_length(comp1),
component_length(comp2));
cmp = memcmp(data(comp1), data(comp2), common);
//not equal, lowest value has precedence
//equal, longest string has precedence
}
}
}
Figure 6
</artwork>
</figure>
</t>
</section>
<section title="BGP Flow Specification Actions">
<t> <xref target="RFC5575"></xref> also defines four actions which would be
carried in BGP extended communities: traffic rate (in bytes), traffic action, redirect
to IPv4 VPAN, and traffic marking. Traffic action has two bits Terminal bit (T) and
Sample (S) bit. If the Terminal Bit is set, the the node apply all filter rules
based as defined by "AND" and precedence. If the terminal bit is clear,
then the flow specification process is to stop.
The Sample bit implies that the flow specification enables sampling and logging
for this event.
</t>
<t>
Unfortunately, <xref target="RFC5575"></xref>
was unclear about the "redirect to IP VPN action" and did not handle IPv6.
<xref target="RFC7674"></xref> was written to clarify
<xref target="RFC5575"></xref> by clearly specifying the 3 extended communities
that "IPv4 VPN" needed to support AS 4 byte, and IPv4 address Routing Distinguishers (RDs).
<xref target="I-D.ietf-idr-flow-spec-v6"></xref>
was written to extend this work to IPv6 filters, and to include the
IPv6 flow in the filter set as figure 5 shows.
</t>
<t>
Proposals to extend these standardized actions include:
<list style="symbols">
<t>(FA1) <xref target="I-D.eddy-idr-flowspec-packet-rate"></xref>
specifies a traffic rate limit by packets the number of packets forwarded,
</t>
<t>(FA2)<xref target="I-D.li-idr-flowspec-rpd"></xref> specifies
an "R" bit for traffic action that allows
a BGP Attribute to pass additional BGP Flowspecification
match filters and actions,
</t>
<t>(FA3) <xref target="I-D.hao-idr-flowspec-redirect-tunnel"></xref>
specifies a redirection to a tunnel specified in
<xref target="I-D.rosen-idr-tunnel-encaps"></xref>,
</t>
<t>(FA4)<xref target="I-D.ietf-idr-flowspec-l2vpn"></xref>
specifie push, pop, or swap VLANs before forwarding,
</t>
<t>(FA5) <xref target="I-D.ietf-idr-flowspec-l2vpn"></xref>
specifies the ability to replace TPIDs
values with new values before forwarding,
</t>
<t>(FA6) <xref target="I-D.liang-idr-bgp-flowspec-label"></xref>
specifies push/pop/swap on MPLS labels before forwarding,
</t>
<t>(FA7)<xref target="I-D.litkowski-idr-flowspec-interfaceset"></xref>
which specifies that ACL filters plus BGP flow specification filters
will determine the acceptance/drop of inbound packet, and
the forwarding/drop of outbound packets.
</t>
</list>
Figure 8 shows these flow specifications.
</t>
<t> <xref target="RFC5575"></xref> indicates that the
actions specified in the document represent only the
"subset of filtering actions that can be interpreted
across the network". As additional standardized
actions occur, the non-standard action will need
to have a precedence below the standardized actions.
</t>
<t>One the probems with adding the actions is that precedence
has not been set for the actions. </t>
<t>
<figure>
<artwork>
Table 4: BGP Flow Specifications in RFC5575 and RFC7674
+-------+--------------------+-------------+-----------------------+
|type# | Action name | action | Reference |
+=======+====================+=============+=======================+
|0x8006 | Traffic Rate | 2 octet AS | RFC5575 |
| | (in bytes ) |4 octet float| |
| | | | |
|0x8007 | Traffic Action |6 octet bit | RFC5575 |
| |(S:Sample and log, |mask:S,T bits| |
| | T:last flowspec | | |
|0x8008 | Redirect (IP VPN) |Route Target | RFC5575 and RFC7674 |
| | (RD: 2 octet AS, |(6 octet) | |
| | 4 octet value) | | |
|0x8108 | Redirect (IP VPN) |Route Target | RFC7674 |
| | (RD: 4 octet IPv4 |(6 octet) | |
| | address, 2 byte | | |
| | value) | | |
|0x8208 | Redirect (IP VPN) |Route Target | RFC7674 |
| | (RC: 4 byte AS, | | |
| | 2 byte value ) | | |
+=======+====================+=============+=======================+
Figure 7
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
Table 5: Proposed Flow Specification Actions
+----- -+--------------------+-------------+-----------------------+
|type# | Action name | action | Reference |
+=======+====================+=============+=======================+
| FA1 | Traffic Rate | 2 octet AS | eddy-idr-flowspec- |
| | (in packets) |4 octet float| packet-rate |
| | | | |
| FA2 | Extended Traffic | R bit | li-idr-flowspec-rpd |
| | Extension for R | P bit | Alternate action |
| | to take additional | | procedures(this draft)|
| | Flow specifications| | |
| | from BGP Flow spec | | |
| | Policy attribute | | |
| | | | |
| FA3 | Redirect to tunnel |6 octets | hao-idr-flowspec- |
| | (tunnel in |1 bit flag | redirect-to-tunnel |
| | BGP Attribute) |(C=applies to| |
| | | copies only)| |
| | | | |
| FA4 | VLAN-action | bitmask |idr-bgp-flowspec-l2vpn |
| |(push, pop, swap) | | |
| | | | |
| FA5 | TPID Action |6 octets |idr-bgp-flowspec-l2vpn |
| | (NVGRE Flow ID ) | | |
| | | | |
| FA6 | Label Action |MPLS Tag, |liang-idr-bgp-flowspec-|
| |(push/pop/swap MPLS |TTL(1 octet) | label-01 |
| |label uses Exp flag,| S bit | |
| |TTL, Stack flag (S))| | |
| | | | |
| FA7 | Alternate NLRI | validation |eddy-idr-flowspec-exp |
| | Validation | bit mask |(some functions) |
| | (mask for support | | |
| | of RFC5755, ROA | | |
| | and bgpsec-protocol| | |
| | AS path) and L2MAC | | |
| | NRLI for IP Address| | |
| | | | |
| FA8 | for Interface set | 4 Byte AS |litkowski-idr-flowspec-|
| | filter ACL + Flow | 2 byte | interfaceset |
| | specification rules| interface | |
| | | group ID | |
+=======+====================+=============+=======================+
Note: FA8 is really a filer plus an action:
FA8-filter: Restrict processing for filters to set of interfaces
FA8-Action: Forward only if: ACL + Flow-Specification filters
suggest forwarding.
Figure 8
</artwork>
</figure>
</t>
</section>
<section title="BGP Flow Specification Security">
<t><xref target="RFC5575"></xref> requires
BGP flow specification is not required to pass in
BGPSEC <xref target="I-D.ietf-sidr-bgpsec-protocol"></xref>.
<xref target="RFC5575"></xref> states "as long as traffic filtering
rules are restricted to match the corresponding unicast routing
paths for relevant prefixes, the security characteristics of this
protocol are equivalent to existing security properties of
BGP unicast properties", and "where this is not the case, this would
open the door to further denial of service attack" (section 10).
</t>
<t>
<xref target="RFC5575"></xref> requires an extension of the
BGP route selection procedures <xref target="RFC4271"></xref>
in section 9.1.2 in order to validate the BGP flow specification
NLRI. The BGP Flow Specification NLRI is valid if and only if:
<list style="symbols">
<t>"the originator of the flow specification matches the
orginator of the the best-match unicast route for the destination
prefix embedded in the flow specification",</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>
This set of validation requirements also require that
BGP implementations are required to enforce the
AS_PATH attribute having the neighbor AS in the left-most position.
</t>
<t> These validation steps required a unicast IPv4 or IPv6 route be
transmitted with L2VPN (<xref target="I-D.ietf-idr-flowspec-l2vpn"></xref>)
and the NV03 flow specifications <xref target="I-D.hao-idr-flowspec-nvo3"></xref>
to validate the path. These specifications do not provide additional details
on any additional validation needed for the L2VPN or NV03 Case.
</t>
<t>Since <xref target="RFC5575"></xref> BGP Route Origin validation
<xref target="RFC6482"></xref> has been standardized, and
the BGPSEC protocol <xref target="I-D.ietf-sidr-bgpsec-protocol"></xref>
has been developed.
<xref target="I-D.eddy-idr-flowspec-exp"></xref> specifies cryptographic
enhancements that include:
<list style="symbols">
<t>creating a BGP identifier (in BGP attribute or in BGPSEC signature),
</t>
<t>Expanding BGPSEC coverage for Route Orgination Authorization (ROA)
to cover the orignator of the BGP Flow specification for the
BGP Flow specification SAFIs.
</t>
<t>Covering the BGP Extended Communities with BGP signature.
</t>
</list>
</t>
<t>This document describes the precedence of these BGP security features.
</t>
</section>
</section>
<section title="Precedence Ordering for BGP Flow specification">
<t>
BGP Flow specification is session ephemeral state which will not
persist when the BGP peer session closes.
I2RS Filter-Based RIB is reboot ephemeral state which will
not persist when the routing entity reboots.
Policy RIB (aka Filter Forwarding RIB) and ACLs are configuration
state which can persist over the reboot of a system.
</t>
<section title="New Validation Rules for BGP Flow Specification: Precedence with ROA">
<t>
This precedence within BGP Session Ephemeral state depends on the
preference associated with valid BGP Session flow specification NLRI
received within a BGP State. Since <xref target="RFC5575"></xref>
was published, additional mechanisms to validate originating prefixes
with an AS with Prefix Orgin Validation (ROA), and the
BGPSEC Secure Path have been standardized. The precedence of these
mechanisms should be from BGP Security to ROA to
<xref target="RFC5575"></xref>. The BGP
peers 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="Default Match Condition Filter Precedence Ordering">
<t>Match conditions depends on an "AND" of all rules within
a Flow Specification policy. A Flow specification policy is
defined by a sequence of BGP Flow specification NLRIs
with filter-match rules. The sequence of Flow Specification rules
are terminate Traffic Action with a T-Bit flag set to zero.
</t>
<t>
Match condition processing occurs in the following overall precedence:
<list style="numbers">
<t>IP Protocol (1-13), </t>
<t>NV03-matches (MF-1 to MF-3),</t>
<t>Other overlay matches (spring, SFC) </t>
<t>L2VPN matches (14-24), </t>
<t>MPLS matches (MF-4), </t>
<t>L2VPN matches (currently 14-24), </t>
<t>interfaces matches (MF-5), </t>
<t>time matches (MF-6), and </t>
<t>Non-Standardized (First-Come-First Serve(FCFS)) match
conditions (see <xref target="RFC5575"></xref> section 11)
</t>
</list>
Table 6 in figure 9 shows the filter by filter
precedence order. All flow specification filters
combine as an "AND" of all filters.
A re-ordering of match filters is only possible in the
the proposed version 2 of BGP Flow specification.
</t>
<t>
<figure>
<artwork>
Table 6: Flow Specification Match Filter Precedence Order
+------+--------------------+-------------+-----------------------+
|type# | Type Name | Match | Reference |
+======+====================+=============+=======================+
| 1 | Destination Prefix | IPv4 Prefix | RFC5575 |
| | | IPv6 Prefix | ietf-idr-flow-spec-v6 |
| 2 | Source Prefix | IPv4 Prefix | RFC5575 |
| | | IPv6 Prefix | ietf-idr-flow-spec-v6 |
| 3 | IP protocol |IPv4 Protocol| RFC5575 |
| | | number | |
| 3 | Next Header |IPv6 protocol| ietf-idr-flow-spec-v6 |
| 4 | Port (source or | Port number | RFC5575 |
| | destination port) | | RFC5575 |
| 5 | Source port | Port number | RFC5575 |
| 6 | Destination port | Port number | RFC5575 |
| 7 | ICMP type | ICMP type | RFC5575 |
| 8 | ICMP code | ICMP code | RFC5575 |
| 9 | TCP Flags | 1 or 2 byte | RFC5575 |
| | | bitmask for | RFC5575 |
| | | TCP flags | |
| 10 | Packet length | # of bytes | RFC5575 |
| | (for IP packet) | | |
| 11 | DSCP | IPv4 DSCP | RFC5575 |
| | | (6 bit mask)| RFC5575 |
| 11 | Traffic class | IPv6 traffic| ietf-idr-flow-spec-v6 |
| | | (8 bit mask)| |
| 12 | IPv4 Fragment |4 bit mask | RFC5575 |
| 13 | IPv6 Flow |20 bit flow | ietf-idr-flow-spec-v6 |
| 14 | Delimiter type | 2 bytes | hao-idr-flowspec-nv03 |
| MF-1 | (Encapsulation type| | |
| | VXLAN or NVGRE) | | |
| | | | |
| 15 | VNID | 24 bit VN | hao-idr-flowspec-nv03 |
| MF-2 |(virtual network ID)| | |
| | | | |
| 16 | Flow ID |8 bit flow ID| hoa-idr-flowspec-nv03 |
| MF-3 | (NVGRE Flow ID ) | | |
| | | | |
| 17 | Segment ID | | |
|18-25 | Other packet ids | | |
| | above MPLS | | |
| 29 | MPLS LSP | TBD | not specified |
| MF-4 |(label 20 bits, | Label stack | |
| | EXP (3 bits), S Bit| | |
| | TTL (8 bits) | | |
| | | | |
| | | | |
| 30 | Ethernet type | 2 bytes |ietf-idr-flowspec-l2vpn|
| 31 | Source MAC |MAC address |ietf-idr-flowspec-l2vpn|
| 32 | Destination MAC |MAC Address |ietf-idr-flowspec-l2vpn|
| 33 | DSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn|
| 34 | SSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn|
| 35 | Control filed in |
| | LLC| |1 octet |ietf-idr-flowspec-l2vpn|
| 36 | SNAP | 5 octet |ietf-idr-flowspec-l2vpn|
| 37 | VLAN ID |1 or 2 bytes |ietf-idr-flowspec-l2vpn|
| 38 | VLAN COS | 3 bit COS |ietf-idr-flowspec-l2vpn|
| 39 | Inner VLAN ID |1 or 2 bytes |ietf-idr-flowspec-l2vpn|
| 40 | Inner VLAN COS |1 or 2 bytes |ietf-idr-flowspec-l2vpn|
| 41 | Interface | TBD | not specified |
| |(Group ID, intf id) | | |
| 42 |Time | | |
| 65 |FCFS matches | | non-standard actions |
+======+====================+=============+=======================+
Figure 9
</artwork>
</figure>
</t>
</section>
<section title="Default Flow Specification Action Precedence and Incompatiabilites">
<t>
Some BGP Flow Specification actions can conflict with other
BGP Flow specification Actions. Table 7 in figure 10 shows
the default precedence order and the potential conflicting actions.
Existing actions with conflicts denote the default action
taken on conflicting actions.
</t>
<t>
Each flow specification that specifies a BGP action
must create a "BGP Flow Specification Action Conflicts"
section within the flow specification. In this section,
the flow specification must point to this document indicating
the precedence between actions, and indicate how the action handles
the conflict. All Standards actions have precedence overall
FCFS actions incoded in BGP Extended Communities.
</t>
<t>R-Policy bit - Additional BGP Version 2 Flow specification
has additional filters and policy in BGP Attribute X. </t>
<t>TP-Mod bit - make modifications to packet before sending
to the IP-VPN via a tunnel, </t>
<t>R-Intf bit - process restrict to interface sets</t>
<t>
Two bits are added to the Extended Traffic Action Flag so that
the total flags are:
<list>
<t>R - Additional Policy in a BGP Flow Specification version 2
NLRI, BGP attribute (or BGP wide communities).</t>
</list>
</t>
<t>
</t>
<t>
<figure>
<artwork>
Table 7 - Action Precedence and Conflicts between Actions
+-----+---------------------+----------------------------------+
|order| Action | Possible Conflicting Actions |
+=====+=====================+==================================+
| FA7 | Alternate NLRI | none |
| 1 | Validation | |
| | (mask for support | |
| | of RFC5755, ROA | |
| | and bgpsec-protocol | |
| | AS path) and L2MAC | |
| | NRLI for IP Address | |
| | | |
| 2 | Traffic Rate(0x8006)| Traffic rate in packets (FA1) |
| | in bytes | |
| | | Default Conflict action: |
| | | Allow traffic monitoring by bytes|
| | | and packets, but process byte |
| | | rate limit checks first |
| | | |
| 3 | Traffic Rate (FA1) | traffic rate in bytes (0x8006) |
| | in packets | |
| | | Default Conflict action: same |
| | | as in Traffic Rate action |
| | | conflict |
| | | |
| 4 | Traffic Action | Extended Traffic action with |
| | (0x8007) | "R-Policy" bit(FA2), "TN-P" bit, |
| | | R-intf bit |
| | | |
| | | Default conflict action: Process |
| | | Traffic Action, then Extended |
| | | traffic action |
| | | |
| 5 | Extended Traffic | Traffic Action (0x8007) |
| | Action (FA2) |"R" bit(FA2), "TN-P" bit (above) |
| | | R-Intf bit |
| | | |
| | | Default conflict action: Process |
| | | Traffic action, then extended |
| | | traffic action |
| | | |
| 6 | Redirect to IP-VPN | Redirect to IP Tunnel (FA3) |
| | 0x8008: 2 byte AS RD| VLAN-action (FA4), |
| | 0x8108: 4 byte IP RD| TPID-action (FA5) |
| | 0x8208: 4 byte AS RD| Label-action (FA6) |
| | | interface set (FA7) |
| | | |
| | | Default Conflict action: |
| | | Process forward to IP-VPN first |
| | | and ignore other conflicting |
| | | actions unless TN-Mod bit set in |
| | | Extended action.
| | | If TN-Mod set then process the |
| | | conflict actions which change |
| | | the packet prior to forwarding |
| | | the packet via tunnel to IP-VPN. |
| | | |
| | | If I bit set, process interface |
| | | restriction's narraowing of scope|
| | | to certain interfaces before |
| | | processing other options, and |
| | | process interface restrictions |
| | | implied in outboudn direction |
| | | before sending packet. |
| | | outbound policy before any other |
| | | If "R" bit set use version 2 of |
| | | BGP Flow Specification handling |
| | | |
| 7 | Redirect to IP | Redirect to IP VPN (0x8008, |
| | Tunnel (FA3) | 0x8108, 0x8208) |
| | | VLAN-action (FA4), |
| | | TPID-action (FA5), |
| | | Label action (FA6), |
| | | interface set (FA7) |
| | | |
| | | Default Conflict actions: |
| | | Refer to processing in redirect |
| | | IP-VPN tunnel |
| | | |
| 8 | VLAN action (FM4) | Redirect to IP-VPN (0x8008, |
| | | 0x8108, 0x8208), |
| | | Redirect to tunnel (FA3), |
| | | VLAN-action (FA4), |
| | | TPID-action (FA5), |
| | | Label action (FA6), |
| | | interface set (FA7) |
| | | |
| | | Default Conflict actions: |
| | | Refer to processing in redirect |
| | | IP-VPN tunnel |
| | | |
| 9 | TPID action (FM5) | Redirect to IP-VPN (0x8008, |
| | | 0x8108, 0x8208), |
| | | Redirect to tunnel (FA3), |
| | | VLAN-action (FA4), |
| | | TPID-action (FA5), |
| | | Label action (FA6), |
| | | interface set (FA7) |
| | | |
| | | Default Conflict actions: |
| | | Refer to processing in redirect |
| | | IP-VPN tunnel |
| | | |
| 10 | Label Action (FM6) | Redirect to IP-VPN (0x8008, |
| | | 0x8108, 0x8208), |
| | | Redirect to tunnel (FA3), |
| | | VLAN-action (FA4), |
| | | TPID-action (FA5), |
| | | Label action (FA6), |
| | | interface set (FA7) |
| | | |
| | | Default Conflict actions: |
| | | Refer to processing in redirect |
| | | IP-VPN tunnel |
| | | |
| 11 | interface Set (FM8a)| Redirect to IP-VPN (0x8008, |
| | | 0x8108, 0x8208), |
| | | Redirect to tunnel (FA3), |
| | | VLAN-action (FA4), |
| | | TPID-action (FA5), |
| | | Label action (FA6), |
| | | |
| | | Default Conflict actions: |
| | | Refer to processing in redirect |
| | | IP-VPN tunnel |
| | | |
| 12 | Filter precedence | reorder default filter precedence|
| | (FM8b) | 0 = BGP Flow-Spec only |
| | [proposed] | 1 = ACL + BGP Flow-Spec |
| | | 2 = I2RS FB-RIB + BGP FS |
| | | 3 = ACL + I2RS FB-FIB + BGP FS |
| | | 4 = Config FB-RIB + BGP FS |
| | | 5 = ACL + config FB-RIB + BGP FS |
| | | 6 = Config FB-RIB + I2RS FB-RIB +|
| | | BGP FS |
| | | 7 = ACL + config FB-FIB + I2RS |
| | | |
|13-63| | Reserved for other standards |
| | | actions |
| | | |
|65+ | FCFS actions | FCFS Actions |
+=====+=====================+==================================+
Figure 9
</artwork>
</figure>
</t>
</section>
<section title="FCFS Flow Specification Match Condition Filter Interaction">
<t> <xref target="RFC5575"></xref> allowed for
non-IETF standardized Flow Specification filters and
extended community actions. The beginning order of precedence for
non-IETF standardized FCFS BGP Flow specification match filters is 65.
The network management yang modules SHOULD
store the BGP Flow Specification match type byte for both
IETF Standardized BGP Flow Specification Match Filters,
FCFS BGP BGP Flow Specification Match filters.
</t>
</section>
<section title="FCFS Extended Communities with BGP Flow Specification Actions">
<t><xref target="RFC7153"></xref>allows for FCFS (First Come First Serve)
allocation of BGP transitive types. If an action is specified in the
FCFS registry, the default precedence is after all standardized
BGP Flow Specification actions(action 65+). The BGP Flow Specification Yang models
should store the Extended Community value for the FCFS based Flow Specification
action. If the precedence ordering has been changed by the FCFS,
this should be stored in the configuration of BGP Flow Specification and
in the operational state.
</t>
</section>
<section title="Ordering Filters and Actions ">
<t>
There are the following ways to get ordered filters and actions:
<list style="symbols">
<t>add an attribute with ordered match filters and
ordered actions as <xref target="I-D.li-idr-flowspec-rpd"></xref>,</t>
<t>Add an NLRI with filters and ordered actions,
</t>
<t>add an NLRI with ordered filters and use
Wide Communities <xref target="I-D.ietf-idr-wide-bgp-communities"></xref>
to get ordered actions
</t>
</list>
</t>
<section title="Additions to Attribute approach">
<t>
To get ordered an ordered match field in <xref target="I-D.li-idr-flowspec-rpd"></xref>
the following additions would need to be made for the match field format:
<list style="symbols">
<t>Match order field</t>
</list>
</t>
<t>
<figure>
<artwork>
match type [bit 1 - deny/permit]
0-permit, 1 -deny
+------------------------+
| match type (2 octets) |
+------------------------+
| number of sub-TLVS |
| (2 octets) |
+------------------------+
| sub-TLVs (variable) |
| +====================+ |
| | order (2 octets) | |
| +--------------------+ |
| | type (2 octets) | |
| +--------------------+ |
| | length (2 octets) | |
| +--------------------+ |
| | value (variable) | |
| +====================+ |
+------------------------+
figure 10 - match field revision
</artwork>
</figure>
</t>
<t>The action field would be expanded to include
an action order field (2 octets) as follows:
</t>
<t>
<figure>
<artwork>
+--------------------------+
| Action order (2 octets) |
+--------------------------+
| Action type (2 octets) |
+--------------------------+
| Action length (2 octets) |
+--------------------------+
| Action Values (variable) |
+--------------------------+
figure 11 - Action field revision
</artwork>
</figure>
</t>
</section>
<section title="NLRI and Wide Community">
<t>
The new BGP NLRI would have the following format
to order filters:
</t>
<t>
<figure>
<artwork>
+------------------------+
|length (2 octets) |
+------------------------+
| number of sub-TLVS |
| (2 octets) |
+------------------------+
| sub-TLVs (variable) |
| +====================+ |
| | order (2 octets) | |
| +--------------------+ |
| | type (2 octets) | |
| +--------------------+ |
| | length (2 octets) | |
| +--------------------+ |
| | value (variable) | |
| +====================+ |
+------------------------+
Figure 12 - NRLI revision
</artwork>
</figure>
</t>
<t>
The BGP Wide community would
need to have an atom (TBD)
that indicates BGP Flow Specification
actions. The atom would have
the following information within it:
<figure>
<artwork>
+--------------------------+
| order (2 octets) |
+--------------------------+
| Action type (2 octets) |
+--------------------------+
| Action length (2 octets) |
+--------------------------+
| Action Values (variable) |
+--------------------------+
Wide Community Atom
figure 13
</artwork>
</figure>
</t>
</section>
</section>
</section>
<section title="Precedence among Routing Functions">
<section title="Precedence ordering Multiple Routing Filtering policy">
<t>
This precedence for flow policy amoung routing functions
SHOULD go from the most dynamic overwriting the
the least dynamic. The order from dynamic to least is:
<list style="numbers">
<t>BGP Session flow specification ephemeral state with
action based ephemeral state that specified interactions according to
interface specification (FA8a and FA8b) from
<xref target="I-D.litkowski-idr-flowspec-interfaceset"></xref>,</t>
<t>BGP Flow specification Session ephemeral state, </t>
<t>I2RS reboot ephemeral state,</t>
<t>Filter-Based RIB (aka Policy RIB configuration State)
(hares-rtgwg-fb-rib-data-model),</t>
<t>ACL configuration state
<xref target="I-D.ietf-netmod-acl-model"></xref>, </t>
<t>routing-config configuration state
<xref target="I-D.ietf-netmod-routing-cfg"></xref>,</t>
<t>interface addresses <xref target="RFC7223"></xref>.
</t>
</list>
</t>
<t>
The filtering process for a packet received
should attempt to match the more dynamic policy
prior to matching a less dynamic policy.
</t>
<t>This standardized order may be modified by
local configuration policy on Flow Specification filtering precedence,
but if it does the BGP FlowSpecification Yang Model show
indicate the current precedence.
</t>
</section>
<section title="Precedence for re-ordering Match Policy">
<t>
Actions that change interact between levels of policy need to be
defined in terms of policy actions in BGP Flow Specification.
For example <xref target="I-D.litkowski-idr-flowspec-interfaceset"></xref>
provides a definition of the following combination of filter
rules between ACLs and BGP flow Specifications:
<list style="numbers">
<t>Forward if both ACL forward and BGP Flow Specification Forward
</t>
<t>Drop if either ACL drops or BGP Flow Specification drops.
</t>
</list>
</t>
</section>
</section>
<section title="Flow Specification Version 2 - to be or not to be">
<t>Pro - for version 2</t>
<t>
The current version 1 of the Flow Specification does not have ordering
of packet ECA policy rules, flow specification filters, or flow specification
actions other than the default precedence. Current implementations of
BGP flow specification are finding this lack of ordering to cause operational
difficulties.
</t>
<t>
Con - for version 2 </t>
<t>Version 2 must be coded. It can either be a BGP
attribute with the policy rules (NLRI filters and actions)
inside such as described in <xref target="I-D.li-idr-flowspec-rpd"></xref>
or it can be a combination of a new BGP Flow Specification
version 2 NLRI + Wide Community actions (with ordering).
</t>
<t>(Additional comments will be added here)</t>
</section>
<section title="Flow Specification Yang models">
<t> The Flow Specification Yang models are expressing
the same policy as the Filter-Based RIB Yang modules for
I2RS and configuration. Aligning these
three yang data models should improve the
management of the different levels of filter-based forwarding
(BGP Session ephemeral, I2RS reboot ephemeral, config filter-based forwarding).
</t>
<t>
This section compares BGP Flow Specification yang model in
<xref target="I-D.wu-idr-flowspec-yang-cfg"></xref>
and the I2RS FB-RIB data model is described in
<xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>
which uses the packet reception ECA policy data model
found in <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>.
A comparison of the policy structures is given in table 8, and
the operation status model is given in table 9.
</t>
<t>
The packet reception ECA policy data model is also used to
describe configured packet reception filter RIBs which
(aka Policy Routing) described in (draft-hares-rtgwg-fb-rib-00.txt).
</t>
<t>
<figure>
<artwork>
Table 8 - comparison of Yang Data models
+-------------+----------------------+-----------------------+
| component | BGP Flow Spec | I2RS FB-RIB + |
| | Yang | Packet-ECA Yang |
+==============+=====================+=======================+
|Policy |flowspec-policy* |group* [group-name] |
| +-name | [policy-name] | |
| +-vrf |+-rw vrf-name | +-rw vrf-name |
| +-AFI |+-rw address-family | +-rw address-famil |
| +-rules |+-rw flowspec-rule* | +-rw group-rule-list |
| || [rule-name] | | [rule-name] |
| +-rule-name ||+-rw rule-name | |+-rw rule-name |
| +-rule-order||+-rw traffic-filters| |+-rw rule-order |
| ||+-rw traffic-actions| +-rw eca-rules |
| | | | [order-id rule-name]|
| | | | +-rw installer |
| | | | +-rw eca-matches |
| | | | +-rw eca-qos-actions|
| | | | +-rw eca-fwd-actions|
+--------------+---------------------+-----------------------+
figure 14 - Comparison of Yang modules (Config state)
</artwork>
</figure>
</t>
<t>
Note:The Yang "traffic-filters" found are the same as eca-matches
found in <xref target="I-D.wu-idr-flowspec-yang-cfg"></xref>
are the same filters found in
<xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>.
The "traffic actions" found in <xref target="I-D.wu-idr-flowspec-yang-cfg"></xref>
can be broken into modify actions and
forwarding actions as <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref> does.
</t>
<t>
<figure>
<artwork>
Table 9 - comparison of Yang operational state
+------------+----------------------+-------------------------+
| component | BGP Flow Spec | I2RS FB-RIB |
| | Yang | Packet-ECA Yang |
+============+======================+=========================+
|opstate |flowspec-state |ietf-fb-ribs-oper-status |
| +-rib |+-ro flowspec-rib |+-ro fb-rib-oper-status* |
| | | | +-ro fb-rib-name |
| +-groups | | | +-ro group-status |
| +-rules | +-ro flowspec-entry*| +-ro rules_opstate |
| [index] | [index] | [rule-order, rule-name]|
| | | | |
|statistics | | | |
| +-rules |+-ro flowspec-stats* | +-ro rules_opstats |
| | | [rule-order, rule-name]|
| | +-ro vrf-name | |
| | +-ro address-family | |
| | +-ro flowspec-rule- | |
| | | stats | |
| | | | |
| | |+-ro traffic-filters| |
| | |+-ro traffic-action | |
| | |+-ro classified-pkts| | +--ro pkts-match |
| | | | | +--ro pkts-modified |
| | |+-ro drop-pkts | | +--ro pkts-dropped |
| | |+-ro drop-bytes | | +--ro bytes-dropped |
| | | | +--ro pkts-forwarded |
| | | | +--ro bytes-forwarded|
+------------+----------------------+-------------------------+
figure 15 - Comparison of Yang Models (Operation State)
</artwork>
</figure>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section complies with <xref target="RFC7153"></xref>
</t>
<t>TBD. There are a lot of assignments which will
be filled in after the initial review of the technology.
</t>
</section>
<section title="Security Considerations">
<t>The new BGP Validation described in section 4.1
with the ROA improves on <xref target="RFC5575"></xref>
security by improving the validation of the originating
AS having permissions to send Flow specifcation for a prefix.
The validation of the path attributes and/or path requires
the BGPSEC <xref target="I-D.ietf-sidr-bgpsec-protocol"></xref>.
<xref target="I-D.eddy-idr-flowspec-exp"></xref> contains
suggestions on how to implement this with flow specification,
but at this time the authors consider the technology described
in <xref target="I-D.eddy-idr-flowspec-exp"></xref> so
this draft does not suggest mandating it. However, it
encourages the develop of such work that pairs
BGP Flow Specification with BGPSEC protocol. When this
work matures, this specification or BGP Flow Specification
version 2 should implement it.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4271;
&RFC4360;
&RFC4760;
&RFC5226;
&RFC5575;
&RFC6241;
&RFC6482;
&RFC6483;
&RFC7153;
&RFC7223;
&RFC7674;
</references>
<references title="Informative References">
&RFC4303;
&I-D.ietf-idr-flowspec-l2vpn;
&I-D.ietf-idr-flow-spec-v6;
&I-D.ietf-idr-wide-bgp-communities;
&I-D.eddy-idr-flowspec-packet-rate;
&I-D.eddy-idr-flowspec-exp;
&I-D.hao-idr-flowspec-nvo3;
&I-D.hao-idr-flowspec-redirect-tunnel;
&I-D.liang-idr-bgp-flowspec-label;
&I-D.liang-idr-bgp-flowspec-time;
&I-D.litkowski-idr-flowspec-interfaceset;
&I-D.li-idr-flowspec-rpd;
&I-D.rosen-idr-tunnel-encaps;
&I-D.vandevelde-idr-flowspec-path-redirect;
&I-D.wu-idr-flowspec-yang-cfg;
&I-D.ietf-sidr-bgpsec-protocol;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.hares-i2rs-pkt-eca-data-model;
&I-D.hares-i2rs-fb-rib-data-model;
&I-D.kini-i2rs-fb-rib-info-model;
&I-D.ietf-netmod-acl-model;
&I-D.ietf-netmod-opstate-reqs;
&I-D.ietf-netmod-routing-cfg;
&I-D.ietf-netconf-restconf;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:09:18 |