One document matched: draft-ietf-idr-flowspec-mpls-match-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 RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC7153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7153.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.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.hares-idr-flowspec-combo
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-idr-flowspec-combo.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-ietf-idr-flowspec-mpls-match-00.txt" ipr="trust200902">
<front>
<title abbrev="FlowSpec MPLS Match">BGP Flow Specification Filter for MPLS Label </title>
<author fullname="Lucy Yong" initials="L" surname="Yong">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>lucy.yong@huawei.com</email>
</address>
</author>
<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>
<author fullname="Qiandeng Liang" initials="Q" surname="Liang">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing</city>
<region></region>
<code>210012</code>
<country>China</country>
</postal>
<email>liangqiandeng@huawei.com </email>
</address>
</author>
<author fullname="Jianjie You" initials="J" surname="You">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing</city>
<region></region>
<code>210012</code>
<country>China</country>
</postal>
<email>youjianjie@huawei.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>
<keyword>MPLS Match</keyword>
<abstract>
<t>This draft proposes BGP flow specification rules that are
used to filter MPLS labeled packets.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> BGP Flow Specification (BGP-FS) <xref target="RFC5575"></xref>
is an extension to that allows for the dissemination of
traffic flow specification rules via BGP (<xref target="RFC4271"></xref>).
BGP-FS policies have a match condition that may
be n-tuple match in a policy, and an action that modifies the
packet and forwards/drops the packet. Via BGP, new filter rules
can be sent to all BGP peers simultaneously without
changing router configuration, and the BGP peer can install these
routes in the forwarding table. The typical application of BGP-FS
is to automate the distribution of traffic filter lists to routers for DDOS mitigation.
</t>
<t><xref target="RFC5575"></xref> defines a new BGP Network Layer
Reachability Information (NLRI) format
used to distribute traffic flow specification rules. NLRI (AFI=1, SAFI=133) is
for IPv4 unicast filtering. NLRI (AFI=1, SAFI=134)is for BGP/MPLS VPN filtering.
<xref target="I-D.ietf-idr-flow-spec-v6"></xref> defines flow-spec extension
for IPv6 data packets. <xref target="I-D.ietf-idr-flowspec-l2vpn"></xref>
extends the flow-spec rules for layer 2 Ethernet packets
(AFI=25, SAFI=133, SAFI=134). All these flow specifications
match parts only reflect single layer IP (source/destination IP prefix,
protocol type, ports, etc.) and Ethernet information
with matches for source/destination MAC
</t>
<t>MPLS technologies <xref target="RFC3031"></xref> have been widely
deployed in WAN networks. MPLS label stack <xref target="RFC3032"></xref>
is the foundation for label switched data plane. A label on a label
stack may represent a label switch path (LSP), application identification
such as Pseudo Wire (PW), a reserved label that triggers a specific data
plane action, or etc. The data plane label switching operations
includes pop, push, or swap label on the label stack.
</t>
<t>For value added services, it is valuable for a MPLS network to have
BGP-FS policy filter that matches on the MPLS portion of a packet and an
action to modify the MPLS packet header and/or monitor
the packets that match the policy. This document specifies an MPLS match filter.
<xref target="I-D.liang-idr-bgp-flowspec-label"></xref>
specifies a BGP action to modify the MPLS label.
</t>
<t><xref target="I-D.hares-idr-flowspec-combo"></xref> describes the following
two options for extending <xref target="RFC5575"></xref>:
<list style="symbols">
<t>Option 1: Extend <xref target="RFC5575"></xref> with new filters,
match filters and actions. Extend the match default order by type and require that
all matches be combined with an "AND". Extend the actions and define
a default order and the resolution of conflicts.
</t>
<t>Option 2: Create a version 2 of BGP flow Specification which
can run in parallel to Option 1 which supports explicit ordering of
match filters and actions. Option 2 will also refine the BGP-FS
security to optionally include ROAs between ASes, and other mechanisms
(<xref target="I-D.ietf-idr-bgp-flowspec-oid"></xref>)
</t>
</list>
</t>
</section>
<section title="The Flow Specification Encoding for MPLS Match ">
<t>This document proposes new flow specifications rules that is encoded in NLRI.
<list style="hanging">
<t hangText="Type TBD1- MPLS Match1">
<list>
<t>Function: The match1 applies to MPLS Label field on the label stack.
</t>
<t>Encoding:
<type(1 octet), length(1 octet), [operator,value]+>.
</t>
<t>It contains a set of {operator, value} pairs that are used for matching filter.
</t>
<t>The operator byte is encoded as:
<figure>
<artwork>
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | i | pos | Resv |
+---+---+---+---+---+---+---+---+
</artwork>
</figure>
</t>
<t>where:
<list style="hanging">
<t hangText="e - end of list bit: "> Set in the last {op, value} pair in the list.
</t>
<t hangText="a - AND bit: "> If unset, the previous term is logically ORed with
the current one. If set, the operation is a logical AND.
It should be unset in the first operator byte of a sequence.
The AND operator has higher priority than OR for the purposes of
evaluating logical expressions.
</t>
<t hangText="i – before bit: ">If unset, apply matching filter before
MPLS label data plane action; if set, apply matching filter after
MPLS label data plane action.
</t>
<t hangText="pos – the label position indication bits:"> where:
<list style="hanging">
<t hangText="00:any position on the label stack"> - the presented
label value is used to match any label on the label stack.
When apply it, at least one label on the stack match the value
</t>
<t hangText="01:top label indication- "> the presented
label value MUST be used to match the top label on the label stack.
</t>
<t hangText="10: bottom label indication- "> If it is set, the
presented label value MUST match the bottom label on the label stack.
When it is clear, the present label value can match to any label on the label stack
</t>
<t hangText="11: ">(for reserved labels)
</t>
</list>
</t>
</list>
</t>
<t>The value field is encoded as:
<figure>
<artwork>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
</list>
</t>
<t hangText="Type TBD2 - MPLS Match2">
<list>
<t>Function: MPLS Match2 applies to MPLS Label experiment bits (EXP) on
the top label in the label stack.
</t>
<t>Encoding: <type (1 octet), [op, value]+>
<list>
<t>[op,value] - Defines a list of {operation, value} pairs used to
match 3-bit exp field on the top label of packets <xref target="RFC3032"></xref>.
</t>
<t>Values are encoded using a single byte, where the five most significant
bits are zero and the three least significant bits contain the exp value.
</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Deployment Example: DDoS Traffic">
<t> In this example, 5 local policy rules in the
filter-based RIBs (FB-RB, aka Policy Routing) will match n-tuples
(destination IP address, Destination Port, source IP address, Source IP Address, protocols
(ICMP and STCP). These policy rules can be created by standard yang modules
for filter-based RIBS (configuration, and ephemeral configuration) or ACLs, or
vendor based policy. These policies will put the DDoS attack data onto one LSP (LSP1)
in order to send the DDoS traffic to the IDS/IPS processing attached to PE2.
</t>
<t>
The MPLS Filter allows the BGP Flow specification to match on the LSP label
rather than the IP address so that PE2 (with the FB-RIBs on PE2) can forward
the traffic to a set of IDS/IPS machines. The BGP Flow Specification (BGP-FS)
can forward this simple match policy along with an action policy that
constraints the traffic on this Flow to a certain rate (bytes/second).
</t>
<t>
<figure>
<artwork>
|<---------------- AS1 ----------------->|
+---------+ +-----+ +-----+ +-----+
===| PE1 |---|IBGP |----|IBGP |----| PE2 |--IDS-1/IPS
| Filters | | | | | | |--IDS-2/IPS
+---------+ +-----+ +-----+ +-----+
|-------------------------------|
MPLS travel on LSP-1 with label-1
BGP Flow Specification Filter 1
BGP Flow Specification
Match Policy
Destination IP address (0/0) [Required by RFC5575]
MPLS Label match (label-1)
Action Policy
Traffic-rate (n bytes)
</artwork>
</figure>
</t>
</section>
<section title="Security Considerations">
<t> The validation of BGP Flow Specification policy is
considered in <xref target="I-D.hares-idr-flowspec-combo"></xref> for option 1, and for
option 2. For Option 1, the MPLS Match can be one of the match filtes, and
and the final match is an “AND” of all the filters. Match filters are tested in
the order specified in <xref target="I-D.hares-idr-flowspec-combo"></xref> and/or
an RFC5575bis document.
</t>
<t>The traffic rate action described above is described in <xref target="RFC5575"></xref>.
<xref target="I-D.hares-idr-flowspec-combo"></xref> suggests a default order for filters
and for the BGP-FS action proposed after <xref target="RFC5575"></xref>,
and this document discusses how conflicts between action are handled.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section complies with <xref target="RFC7153"></xref>
</t>
<t>
IANA is requested to a new entry in “Flow Spec component types registry”
with the following values:
<figure>
<artwork>
Value Name: Value Reference
=========== ===== =========
MPLS-Match1 TBD1 [This Document]
MPLS-Match2 TBD2 [This Document]
</artwork>
</figure>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3031;
&RFC3032;
&RFC4271;
&RFC5575;
&RFC7153;
</references>
<references title="Informative References">
&I-D.ietf-idr-flow-spec-v6;
&I-D.ietf-idr-flowspec-l2vpn;
&I-D.liang-idr-bgp-flowspec-label;
&I-D.hares-idr-flowspec-combo;
&I-D.ietf-idr-bgp-flowspec-oid;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 05:09:17 |