draft-ietf-idr-flowspec-nvo3-07.txt   draft-ietf-idr-flowspec-nvo3-08.txt 
INTERNET-DRAFT D. Eastlake INTERNET-DRAFT D. Eastlake
Intended Status: Proposed Standard Futurewei Technologies Intended Status: Proposed Standard Futurewei Technologies
W. Hao W. Hao
S. Zhuang S. Zhuang
Z. Li Z. Li
Huawei Technologies Huawei Technologies
R. Gu R. Gu
China Mobil China Mobil
Expires: May 3, 2020 November 4, 2019 Expires: July 15, 2020 January 16, 2020
BGP Dissemination of BGP Dissemination of
Flow Specification Rules for Tunneled Traffic Flow Specification Rules for Tunneled Traffic
draft-ietf-idr-flowspec-nvo3-07 draft-ietf-idr-flowspec-nvo3-08
Abstract Abstract
This draft specifies a Border Gateway Protocol Network Layer This draft specifies a Border Gateway Protocol Network Layer
Reachability Information (BGP NLRI) encoding format for flow Reachability Information (BGP NLRI) encoding format for flow
specifications (RFC 5575bis) that can match on a variety of tunneled specifications (RFC 5575bis) that can match on a variety of tunneled
traffic. In addition, flow specification components are specified for traffic. In addition, flow specification components are specified for
certain tunneling header fields. certain tunneling header fields.
Status of This Document Status of This Document
skipping to change at page 2, line 13 skipping to change at page 2, line 13
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
Table of Contents Table of Contents
1. Introduction............................................3 1. Introduction............................................3
1.1 Terminology............................................3 1.1 Terminology............................................3
2. Tunneled Traffic Flow Specification NLRI................5 2. Tunneled Traffic Flow Specification NLRI................5
2.1 SAFI Code Point........................................6 2.1 The SAFI Code Point....................................7
2.2 Component Code Points..................................6 2.2 Tunnel Header Component Code Points....................8
2.3 Specific Tunnel Types..................................8 2.3 Specific Tunnel Types..................................9
2.3.1 VXLAN................................................8 2.3.1 VXLAN................................................9
2.3.2 VXLAN-GPE............................................8 2.3.2 VXLAN-GPE...........................................10
2.3.3 NVGRE................................................9 2.3.3 NVGRE...............................................11
2.3.4 L2TPv3...............................................9 2.3.4 L2TPv3..............................................11
2.3.5 GRE.................................................10 2.3.5 GRE.................................................12
2.3.6 IP-in-IP............................................10 2.3.6 IP-in-IP............................................12
2.4 Tunneled Traffic Actions..............................11 2.4 Tunneled Traffic Actions..............................12
3. Order of Traffic Filtering Rules.......................12 3. Order of Traffic Filtering Rules.......................13
4. Flow Spec Validation...................................13 4. Flow Spec Validation...................................14
5. Security Considerations................................13 5. Security Considerations................................14
6. IANA Considerations....................................13 6. IANA Considerations....................................14
Normative References......................................14 Normative References......................................15
Informative References....................................15 Informative References....................................16
Acknowledgments...........................................16 Acknowledgments...........................................17
Authors' Addresses........................................16 Authors' Addresses........................................17
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
1. Introduction 1. Introduction
BGP Flow-spec [RFC5575bis] is an extension to BGP that supports the BGP Flow-spec [RFC5575bis] is an extension to BGP that supports the
dissemination of traffic flow specification rules. It uses the BGP dissemination of traffic flow specification rules. It uses the BGP
control plane to simplify the distribution of Access Control Lists control plane to simplify the distribution of Access Control Lists
(ACLs) and allows new filter rules to be injected to all BGP peers (ACLs) and allows new filter rules to be injected to all BGP peers
simultaneously without changing router configuration. A typical simultaneously without changing router configuration. A typical
application of BGP Flow-spec is to automate the distribution of application of BGP Flow-spec is to automate the distribution of
traffic filter lists to routers for Distributed Denial of Service traffic filter lists to routers for Distributed Denial of Service
(DDOS) mitigation. (DDOS) mitigation.
BGP Flow-spec defines a BGP Network Layer Reachability Information BGP Flow-spec defines a BGP Network Layer Reachability Information
(NLRI) format used to distribute traffic flow specification rules. (NLRI) format used to distribute traffic flow specification rules.
AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for
IPv4 BGP/MPLS VPN filtering. [FlowSpecV6] and [Layer2- FlowSpec] IPv4 BGP/MPLS VPN filtering. [FlowSpecV6] and [FlowSpecL2] extend the
extend the flow-spec rules for IPv6 and layer 2 Ethernet packets flow-spec rules for IPv6 and layer 2 Ethernet packets respectively.
respectively. All these previous flow specifications match only a None of these previous flow specifications are suitable for matching
single level of IP/Ethernet information fields such as in cases of tunneling or encapsulation where there might be
source/destination IP prefix, protocol type, source/destination MAC, duplicates of a layer of header such as two IPv6 headers in IP-in-IP
ports, EtherType and the like. or a nested header sequence such as the layer 2 and 3 headers
encapsulated in VXLAN [RFC7348].
In the cloud computing era, multi-tenancy has become a core In the cloud computing era, multi-tenancy has become a core
requirement for data centers. It is increasingly common to see requirement for data centers. It is increasingly common to see
tunneled traffic with a field to distinguish tenants. An example is tunneled traffic with a field to distinguish tenants. An example is
the Network Virtualization Over Layer 3 (NVO3 [RFC8014]) overlay the Network Virtualization Over Layer 3 (NVO3 [RFC8014]) overlay
technology that can satisfy multi-tenancy key requirements. VXLAN technology that can satisfy multi-tenancy key requirements. VXLAN
[RFC7348] and NVGRE [RFC7637] are two typical NVO3 encapsulations. [RFC7348] and NVGRE [RFC7637] are two typical NVO3 encapsulations.
Other encapsulations such as IP-in-IP or GRE may be encountered. Other encapsulations such as IP-in-IP or GRE may be encountered.
Because these tunnel / overlay technologies involving an additional Because these tunnel / overlay technologies involving an additional
level of encapsulation, flow specification that can match on the level of encapsulation, flow specification that can match on the
inner header as well as the outer header are needed. inner header as well as the outer header are needed.
In summary, the Flow specifications should be able to include inner In summary, Flow specifications should be able to include inner
nested header information as well as fields specific to the type of nested header information as well as fields specific to the type of
tunneling in use such as virtual network / tenant ID. This draft tunneling in use such as virtual network / tenant ID. This draft
specifies methods for accomplishing this using SAFI=TBD1 and a new specifies methods for accomplishing this using SAFI=TBD1 and a new
NLRI encoding. NLRI encoding.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 5, line 9 skipping to change at page 5, line 9
NVO3 - Network Virtual Overlay Layer 3 [RFC8014] NVO3 - Network Virtual Overlay Layer 3 [RFC8014]
VN - virtual network VN - virtual network
VXLAN - Virtual eXtensible Local Area Network [RFC7348] VXLAN - Virtual eXtensible Local Area Network [RFC7348]
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
2. Tunneled Traffic Flow Specification NLRI 2. Tunneled Traffic Flow Specification NLRI
The Flow-spec rules in [RFC5575bis], [FlowSpecV6], and [FlowSpecL2] The Flow-spec rules specified in [RFC5575bis], [FlowSpecV6], and
can only recognize flows based on one level of header in a data [FlowSpecL2] cannot match or filter tunneled traffic based on the
packet. To enable flow specification of tunneled traffic, a new SAFI tunnel type, any tunnel header fields, or headers past the tunnel
header. To enable flow specification of tunneled traffic, a new SAFI
(TBD1) and NLRI encoding are introduced. This encoding, shown in (TBD1) and NLRI encoding are introduced. This encoding, shown in
Figure 1, enables flow specification of more than one layer of header Figure 1, enables flow specification of more than one layer of header
when needed. when needed.
INTERNET-DRAFT BGP Tunnel Flow-Spec
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length 2 bytes | | Length 2 octets |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Tunnel Type 2 bytes | | Tunnel Type 2 octets |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Flags: Flags:
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| D| I| Reserved | 1 byte | D| I| Reserved | 1 octet
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
Optional Routing Discriminator: Optional Routing Discriminator:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | |
+ + + +
| | | |
+ Routing Discriminator 8 bytes + + Routing Discriminator 8 octets +
| | | |
+ + + +
| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Outer Flow-spec: Outer Flow-spec:
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| Outer Flowspec Length : 1 or 2 bytes | Outer Flowspec Length : 1 or 2 octets
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Outer Flowspec variable : | Outer Flow-spec variable :
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Tunnel Header Flow-Spec:
+--+--+--+--+--+--+--+--+
| Tunnel Flowspec Length: 1 or 2 octets
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Tunnel Header Flow-spec variable :
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Optional Inner Flow-spec: Optional Inner Flow-spec:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Inner AFI 2 bytes | | Inner AFI 2 octets |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Inner Flowspec Length : 1 or 2 bytes | Inner Flowspec Length : 1 or 2 octets
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Inner Flowspec variable : | Inner Flow-spec variable :
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1. Tunneled Traffic Flow-spec NLRI Figure 1. Tunneled Traffic Flow-spec NLRI
Length - The NLRI Length encoded as an unsigned integer including the Length - The NLRI Length including the Tunnel Type encoded as an
Tunnel Type. unsigned integer.
Tunnel Type - The type of tunnel using a value from the IANA BGP Tunnel Type - The type of tunnel using a value from the IANA BGP
Tunnel Encapsulation Attribute Tunnel Types registry. Tunnel Encapsulation Attribute Tunnel Types registry.
INTERNET-DRAFT BGP Tunnel Flow-Spec
Flags: D bit - Indicates the presence of the Routing Discriminator Flags: D bit - Indicates the presence of the Routing Discriminator
(see below). (see below).
Flags: I bit - Indicates the presence of an inner AFI and Flow-spec. INTERNET-DRAFT BGP Tunnel Flow-Spec
Flags: I bit - Indicates the presence of the Inner AFI and the Inner
Flow-spec.
Flags: Reserved - Six bits that MUST be sent as zero and ignored on Flags: Reserved - Six bits that MUST be sent as zero and ignored on
receipt. receipt.
Routing Discriminator - If the outer layer 3 address belongs to a Routing Discriminator - If the outer Layer 3 address belongs to a
BGP/MPLS VPN, the routing discriminator can be included to BGP/MPLS VPN, the routing discriminator can be included to
support traffic filtering within that VPN. Because NVO3 outer support traffic filtering within that VPN. Because NVO3 outer
layer addresses normally belong to a public network, a Route layer addresses normally belong to a public network, a Route
Distinguisher field is normally not needed for NVO3. Distinguisher field is normally not needed for NVO3.
Outer Flowspec / Length - The flow specification for the outer Outer Flow-spec / Length - The flow specification for the outer
header. The length is encoded as provided in Section 4.1 of header. The length is encoded as provided in Section 4.1 of
[RFC5575bis]. The AFI for the outer flowspec is that AFI at the [RFC5575bis]. The AFI for the outer Flow-spec is that AFI at
beginning of the BGP multiprotocol MP_REACH_NLRI or the beginning of the BGP multiprotocol MP_REACH_NLRI or
MP_UNREACH_NLRI containing the tunneled traffic flow MP_UNREACH_NLRI containing the tunneled traffic flow
specification NLRI. specification NLRI.
Inner AFI - Depending on the Tunnel Type, there may be an inner AFI Tunnel Header Flow-spec / Length - The flow specification for the
tunneling header. This can specify matching criterion on tunnel
header fields. The tunnel type itself is indicated by the
Tunnel Type field above. For some types of tunneling, such as
IP-in-IP, there may be no tunnel header fields. For other types
of tunneling, there may be several tunnel header fields on
which matching could be specified with this Flow-spec.
Inner AFI - Depending on the Tunnel Type, there may be an Inner AFI
that indicates the address family for the inner flow that indicates the address family for the inner flow
specification. There is no need for a SAFI as it is specification. There is no need for a SAFI as, in effect, it
automatically TBD1, the SAFI for a tunneled traffic flow is automatically TBD1, the SAFI for a tunneled traffic flow
specification. specification.
Inner Flowspec / Length - Depending on the Tunnel Type, there may be Inner Flow-spec / Length - Depending on the Tunnel Type, there may be
an inner flow specification for the header level encapsulated an inner flow specification for the header level encapsulated
within the outer header. The length is encoded as provided in within the outer header. The length is encoded as provided in
Section 4.1 of [RFC5575bis]. Section 4.1 of [RFC5575bis].
2.1 SAFI Code Point A Tunneled Traffic Flow-spec matches if the Outer Flow-spec, Tunnel
Header Flow-spec, and Inner Flow-spec all match and the Routing
Discriminator applies, if present. An omitted (as can be done for the
Inner Flow-spec) or null Flow-spec is considered to always match.
2.1 The SAFI Code Point
Use of the tunneled traffic flow specification NLRI format is Use of the tunneled traffic flow specification NLRI format is
indicated by SAFI=TBD1. This is used in conjunction with the AFI for indicated by SAFI=TBD1. This is used in conjunction with the AFI for
the outer layer 3 header, that is AFI=1 for IPv4 and AFI=2 for IPv6. the outer header, that is AFI=1 for IPv4, AFI=2 for IPv6, and AFI=6
2.2 Component Code Points INTERNET-DRAFT BGP Tunnel Flow-Spec
For flow specification based on certain tunnel header fields, the for Layer 2.
component types below are added. These are associated with the Tunnel
Type and MAY appear in the outer flow specification or, if it is
present, in the inner flow specification.
INTERNET-DRAFT BGP Tunnel Flow-Spec 2.2 Tunnel Header Component Code Points
Type TBD2 - VN ID For flow specification based on most tunneling headers, there are
additional tunnel header fields that can be tested by components that
appear in the Tunnel Header Flow-spec field. The types for these
components are specified in a Tunnel Header Flow-spec component
registry (see Section 6).
All Tunnel Header field components defined below and all such
components added in the future have a TLV structure as follows:
- one octet of type followed by
- one octet giving the length as an unsigned integer number of
octets followed by
- the specific matching operations/values as determined by the
type.
Type 1 - VN ID
Encoding: <type (1 octet), length (1 octet), [op, value]+>. Encoding: <type (1 octet), length (1 octet), [op, value]+>.
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
24-bit VN ID that is used as the tenant identification in some 24-bit VN ID that is used as the tenant identification in some
tunneling headers. For VXLAN encapsulation, the VN ID is the tunneling headers. For VXLAN encapsulation, the VN ID is the
VNI. For NVGRE encapsulation, the VN ID is the VSID. op is VNI. For NVGRE encapsulation, the VN ID is the VSID. op is
encoded as specified in Section 4.2.3 of [RFC5575bis]. Values encoded as specified in Section 4.2.3 of [RFC5575bis]. Values
are encoded as 1- to 3-byte quantities. are encoded as a 1, 2, or 4 octet quantity. If value is
24-bits, they are left-justified in the first 3 octets of the
value and the last value octet MUST be sent as zero and ignored
on receipt.
Type TBD3 - Flow ID Type 2 - Flow ID
Encoding: <type (1 octet), length (1 octet), [op, value]+> Encoding: <type (1 octet), length (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match 8-bit Defines a list of {operation, value} pairs used to match 8-bit
Flow ID fields which are currently only useful for NVGRE Flow ID fields which are currently only useful for NVGRE
encapsulation. op is encoded as specified in Section 4.2.3 of encapsulation. op is encoded as specified in Section 4.2.3 of
[RFC5575bis]. Values are encoded as 1-byte quantity. [RFC5575bis]. Values are encoded as a 1-octet quantity.
Type TBD4 - Session Type 3 - Session
Encoding: <type (1 octet), length (1 octet), [op, value]+> Encoding: <type (1 octet), length (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match a Defines a list of {operation, value} pairs used to match a
32-bit Session field. This field is called Key in GRE [RFC2890] 32-bit Session field. This field is called Key in GRE [RFC2890]
encapsulation and Session ID in L2TPv3 encapsulation. op is encapsulation and Session ID in L2TPv3 encapsulation. op is
encoded as specified in Section 4.2.3 of [RFC5575bis]. Values encoded as specified in Section 4.2.3 of [RFC5575bis]. Values
are encoded as a 1, 2, or 4 byte quantity. are encoded as a 1, 2, or 4 octet quantity.
Type TBD5 - Cookie INTERNET-DRAFT BGP Tunnel Flow-Spec
Type 4 - Cookie
Encoding: <type (1 octet), length (1 octet), [op, value]+> Encoding: <type (1 octet), length (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match a Defines a list of {operation, value} pairs used to match a
variable length Cookie field. This is only useful in L2TPv3 variable length Cookie field. This is only useful in L2TPv3
encapsulation. op is encoded as specified in Section 4.2.3 of encapsulation. op is encoded as specified in Section 4.2.3 of
[RFC5575bis]. Values are encoded as a 1, 2, 4, or 8 byte [RFC5575bis]. Values are encoded as a 1, 2, 4, or 8 octet
quantity. If the Cookie does not fit exactly into the value quantity. If the Cookie does not fit exactly into the value
length, it is left justified, that is, padded with following length, it is left justified, that is, padded with following
bytes the MUST be sent as zero and ignored on receipt. octets the MUST be sent as zero and ignored on receipt.
Type TBD6 - VXLAN-GPE Flags Type 5 - VXLAN-GPE Flags
Encoding: <type (1 octet), length (1 octet), [op, bitmask]+> Encoding: <type (1 octet), length (1 octet), [op, bitmask]+>
Defines a list of {operation, value} pairs used to match Defines a list of {operation, value} pairs used to match
against the VSLAN-GPE flags field. op is encoded as in Section against the VXLAN-GPE flags field. op is encoded as in Section
4.2.9 of [RFC5575bis]. bitmask is encoded as 1 byte. 4.2.9 of [RFC5575bis]. bitmask is encoded as 1 octet.
INTERNET-DRAFT BGP Tunnel Flow-Spec
2.3 Specific Tunnel Types 2.3 Specific Tunnel Types
The following subsections describe how to handle flow specification The following subsections describe how to handle flow specification
for several specific tunnel types. for several specific tunnel types.
2.3.1 VXLAN 2.3.1 VXLAN
The headers on a VXLAN [RFC7348] data packet are an outer Ethernet The headers on a VXLAN [RFC7348] data packet are an outer Ethernet
header, an outer IP header, a UDP header, the VXLAN header, and an header, an outer IP header, a UDP header, the VXLAN header, and an
inner Ethernet header. This inner Ethernet header is frequently, but inner Ethernet header. This inner Ethernet header is frequently, but
not always, followed by an inner IP header. If the tunnel type is not always, followed by an inner IP header. If the tunnel type is
VXLAN, the I flag MUST be set. VXLAN, the I flag MUST be set.
The version (IPv4 or IPv6) of the outer IP header is indicated by the If the outer Ethernet header is not being matched, the version (IPv4
AFI at the beginning of the multiprotocol MP_REACH_NLRI or or IPv6) of the outer IP header is indicated by the AFI at the
MP_UNREACH_NLRI containing the tunneled traffic flow specification beginning of the multiprotocol MP_REACH_NLRI or MP_UNREACH_NLRI
NLRI. The outer flowspec is used to filter the outer headers and the containing the tunneled traffic flow specification NLRI. The outer
UDP header. Flow-spec is used to filter the outer headers including, if desired,
the UDP header.
The inner flowspec is used on the Inner Ethernet header [FlowSpecL2]. If the outer Ethernet header is being matched, then the initial AFI
If the inner AFI is 25, then whether or not an IP header follows the is 6 [FlowSpecL2] and the Outer Flow-spec can match the outer
inner Ethernet header is ignored and the inner flowspec SHOULD NOT Ethernet header, specify the IP version of the outer IP header, and
contain and IPv4 or IPv6 flowspec components. If the inner AFI is 1 match that IP header including, if desired, the UDP header.
or 2, to match the flowspec the Inner Ethernet header must be
followed by an IPv4 or IPv6 header, respectively, and the inner
flowspec is also used to filter that inner IP header.
A component filtering on the VXLAN header VN ID (VNI) can appear in The Tunnel Header Flow-spec can be used to filter on the VXLAN header
either the outer or inner flowspec. The inner MAC/IP address is VN ID (VNI).
associated with a VN ID. In the NVO3 terminating into a VPN scenario,
if multiple access VN IDs map to one VPN instance, one shared VN ID INTERNET-DRAFT BGP Tunnel Flow-Spec
can be carried in the Flow-Spec rule to enforce the rule on the
entire VPN instance and the shared VN ID and VPN correspondence The inner Flow-spec can be used on the Inner Ethernet header
should be configured on each VPN PE beforehand. In this case, the [FlowSpecL2] and any following IP header. If the inner AFI is 6,
function of the layer 3 VN ID is the same as a Route Discriminator: then the inner Flow-spec provides filtering of the Layer 2 header,
it acts as the identification of the VPN instance. indicates whether filtering on a following IPv4 or IPv6 header is
desired, and if it is desired provides the Flow-spec components for
that filtering. If the Inner AFI is 1 or 2, the Inner Ethernet
header is not matched and to match the Flow-spec the Inner Ethernet
header must be followed by an IPv4 or IPv6 header, respectively, and
the inner Flow-spec is used to filter that inner IP header.
The inner MAC/IP address is associated with a VN ID. In the NVO3
terminating into a VPN scenario, if multiple access VN IDs map to one
VPN instance, one shared VN ID can be carried in the Flow-Spec rule
to enforce the rule on the entire VPN instance and the shared VN ID
and VPN correspondence should be configured on each VPN PE
beforehand. In this case, the function of the Layer 3 VN ID is the
same as a Route Discriminator: it acts as the identification of the
VPN instance.
2.3.2 VXLAN-GPE 2.3.2 VXLAN-GPE
VXLAN-GPE [GPE] is similar to VXLAN and the VXLAN-GPE header is the VXLAN-GPE [GPE] is similar to VXLAN and the VXLAN-GPE header is the
same size as the VXLAN header but has been extended from the VXLAN same size as the VXLAN header but has been extended from the VXLAN
header by specifying a number of bits that are reserved in the VXLAN header by specifying a number of bits that are reserved in the VXLAN
header. In particular, a number of additional flag bits are specified header. In particular, a number of additional flag bits are specified
and a Next Protocol field is added that is valid if the P flag bit is and a Next Protocol field is added that is valid if the P flag bit is
set. These flags bits can be tested using the VXLAN-GPE Flags set. These flags bits can be tested using the VXLAN-GPE Flags
component defined above. VXLAN and VXLAN-GPE are distinguished by the component defined above. VXLAN and VXLAN-GPE are distinguished by the
INTERNET-DRAFT BGP Tunnel Flow-Spec
port number in the UDP header the precedes the VXLAN or VXLAN-GPE port number in the UDP header the precedes the VXLAN or VXLAN-GPE
headers. headers.
If the VXLAN-GPE header P flag is zero, then the header is followed If the VXLAN-GPE header P flag is zero, then that header is followed
by the same sequence as for VXLAN and the same flow-spec choices by the same sequence as for VXLAN and the same Flow-spec choices
apply (see Section 2.3.1). apply (see Section 2.3.1).
If the VXLAN-GPE header P flag is one and that header's next protocol If the VXLAN-GPE header P flag is one and that header's next protocol
field is 1, then the VXLAN-GPE header is followed by an IPv4 header. field is 1, then the VXLAN-GPE header is followed by an IPv4 header.
The inner AFI/flowspec match only if the inner AFI is 1 and the inner The inner AFI/Flow-spec match only if the inner AFI is 1 and the
flowspec matches. inner Flow-spec matches.
If the VXLAN-GPE header P flag is one and that header's next protocol If the VXLAN-GPE header P flag is one and that header's next protocol
field is 2, then the VXLAN-GPE header is followed by an IPv6 header. field is 2, then the VXLAN-GPE header is followed by an IPv6 header.
The inner AFI/flowspec match only if the inner AFI is 2 and the inner The inner AFI/Flow-spec match only if the inner AFI is 2 and the
flowspec matches. inner Flow-spec matches.
INTERNET-DRAFT BGP Tunnel Flow-Spec
2.3.3 NVGRE 2.3.3 NVGRE
NVGRE [RFC7637] is very similar to VXLAN except that the UDP header NVGRE [RFC7637] is very similar to VXLAN except that the UDP header
and VXLAN header immediately after the outer IP header are replaced and VXLAN header immediately after the outer IP header are replaced
by a GRE (Generic Router Encapsulation) header. The GRE header as by a GRE (Generic Router Encapsulation) header. The GRE header as
used in NVGRE has no Checksum or Reserved1 field as shown in used in NVGRE has no Checksum or Reserved1 field as shown in
[RFC2890] but there are Virtual Subnet ID and FlowID fields in place [RFC2890] but there are Virtual Subnet ID and Flow ID fields in place
of what is labeled in [RFC2890] as the Key field. Processing and of what is labeled in [RFC2890] as the Key field. Processing and
restrictions for NVGRE are as in Section 2.3.1 eliminating references restrictions for NVGRE are as in Section 2.3.1 eliminating references
to a UDP header and replacing references to the VXLAN header and its to a UDP header and replacing references to the VXLAN header and its
VN ID with references to the GRE header and its VN ID (VSID) and Flow VN ID with references to the GRE header and its VN ID (VSID) and Flow
ID. ID.
2.3.4 L2TPv3 2.3.4 L2TPv3
The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet
header, an outer IP header, the L2TPv3 header, an inner Ethernet header, an outer IP header, the L2TPv3 header, an inner Ethernet
header, and possibly an inner IP header if indicated by the inner header, and possibly an inner IP header if indicated by the inner
Ethernet header EtherType. The outer flowspec operates on the outer Ethernet header EtherType. The outer Flow-spec operates on the outer
headers that precede the GRE header. The version of IP is specified headers that precede the GRE header. The version of IP is specified
by the outer AFI at the beginning of the MP_REACH_NLRI or by the outer AFI at the beginning of the MP_REACH_NLRI or
MP_UNREACH_NLRI. MP_UNREACH_NLRI.
The L2TPv3 header consists of a 32-bit Session ID followed by a The L2TPv3 header consists of a 32-bit Session ID followed by a
variable length Cookie (maximum length 8 bytes). The Session ID and variable length Cookie (maximum length 8 octets). The Session ID and
Cookie can be filtered for by using the Session and Cookie flowspec Cookie can be filtered for by using the Session and Cookie Flow-spec
components. To filter on Cookie or even be able to bypass Cookie and components in the Tunnel Header Flow-spec. To filter on Cookie or
parse the remainder of the L2TPv3 packet, the node implementing even be able to bypass Cookie and parse the remainder of the L2TPv3
flowspec needs to know the length and/or value of the Cookie fields packet, the node implementing Flow-spec needs to know the length
and/or value of the Cookie fields of interest. This is negotiated at
INTERNET-DRAFT BGP Tunnel Flow-Spec L2TPv3 session establishment and it is out of scope for this document
how the node would learn this information. Of course, if Flow-spec is
of interest. This is negotiated at L2TPv3 session establishment and being used for DDOS mitigation and the Cookie has a fixed length
it is out of scope for this document how the node would learn this and/or value in the DDOS traffic, this could be learned by inspecting
information. Of course, if flowspec is being used for DDOS mitigation that traffic.
and the Cookie has a fixed length and/or value in the DDOS traffic,
this could be learned by inspecting that traffic.
If the I flag bit is zero, then no filtering is done on data beyond If the I flag bit is zero, then no filtering is done on data beyond
the L2TPv3 header. If the I flag is one, indicating the presence of the L2TPv3 header. If the I flag is one, indicating the presence of
an inner flowspec, and the node implementing flowspec does not know an inner Flow-spec, and the node implementing Flow-spec does not know
the length of the L2TPv3 header Cookie, the match fails. If that node the length of the L2TPv3 header Cookie, the match fails. If that node
does know the length of that Cookie, the inner flowspec if matched does know the length of that Cookie, the inner Flow-spec if matched
against the headers at the beginning of that data using the inner against the headers at the beginning of that data using the inner
AFI. If the inner AFI is 1 or 2, then an inner IP header is required AFI. If the inner AFI is 1 or 2, then an inner IP header is required
and filtering can be done on the Ethernet header immediately after and filtering can be done on the Ethernet header immediately after
the L2TPv3 header and the following IPv4 or IPv6 headers the L2TPv3 header and the following IPv4 or IPv6 headers
respectively. If the inner AFI is 25, filtering SHOULD only be done respectively. If the inner AFI is 6, filtering SHOULD only be done on
on the inner Ethernet header [FlowSpecL2]. the inner Ethernet header [FlowSpecL2].
INTERNET-DRAFT BGP Tunnel Flow-Spec
2.3.5 GRE 2.3.5 GRE
Generic Router Encapsulation (GRE [RFC2890]) is a common type of Generic Router Encapsulation (GRE [RFC2890]) is another type of
encapsulation. The outer flowspec operates on the outer headers that encapsulation. The outer Flow-spec operates on the outer headers that
precede the GRE header. The version of IP is specified by the outer precede the GRE header. The version of IP is specified by the outer
AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI. AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI.
If the I flag bit is zero, no filtering is done on data after the GRE If the I flag bit is zero, no filtering is done on data after the GRE
header. If the I flag bit is one, then there is an inner AFI and header. If the I flag bit is one, then there is an inner AFI and
flowspec and the Protocol Type field of the GRE header must match the Flow-spec and the Protocol Type field of the GRE header must match
inner AFI as follows for the flowspec to match: the inner AFI as follows for the Flow-spec to match:
GRE Protocol Type Inner AFI GRE Protocol Type Inner AFI
------------------- ----------- ------------------- -----------
0x0800 (IPv4) 1 0x0800 (IPv4) 1
0x86DD (IPv6) 2 0x86DD (IPv6) 2
0x6558 25 0x6558 6
With the I flag a one and the inner AFI and GRE Protocol Type fields With the I flag a one and the inner AFI and GRE Protocol Type fields
match, the inner flowspec is used to filter the inner Ethernet header match, the inner Flow-spec is used to filter the inner Ethernet
(AFI=25) or the inner IP and Ethernet headers (AFI=1 or 2). header (AFI=6) or the inner IP and Ethernet headers (AFI=1 or 2).
2.3.6 IP-in-IP 2.3.6 IP-in-IP
IP-in-IP encapsulation is shown when the outer IP header indicates an IP-in-IP encapsulation is shown when the outer IP header indicates an
inner IP IPv4 or IPv6 header by the value of the outer IP header's inner IP IPv4 or IPv6 header by the value of the outer IP header's
Protocol (IPv4) or Next Protocol (IPv6) field. If the Tunnel Type is Protocol (IPv4) or Next Protocol (IPv6) field. If the Tunnel Type is
IP-in-IP, the I flag MUST be set. IP-in-IP, the I flag MUST be set.
INTERNET-DRAFT BGP Tunnel Flow-Spec
The version of the outer IP header (IPv4 or IPv6) matched is The version of the outer IP header (IPv4 or IPv6) matched is
indicated by the AFI at the beginning of the MP_REACH_NLRI or indicated by the AFI at the beginning of the MP_REACH_NLRI or
MP_UNREACH_NLRI. The version of the inner IP header is indicated by MP_UNREACH_NLRI. The version of the inner IP header is indicated by
the inner AFI. The outer flowspec applies to the outer IP header and the inner AFI. The outer Flow-spec applies to the outer IP header and
the inner flowspec applies to the inner IP header. the inner Flow-spec applies to the inner IP header.
There are no fields that can be matched by the Tunnel Header Flow-
spec in the case of IP-in-IP.
2.4 Tunneled Traffic Actions 2.4 Tunneled Traffic Actions
The previously specified traffic filtering actions are used for The traffic filtering actions previously specified in [RFC5575bis]
tunneled traffic [RFC5575bis] [FlowSpecL2]. For Traffic Marking in and [FlowSpecL2] are used for tunneled traffic. For Traffic Marking
NVO3, only the DSCP in the outer header can be modified. in NVO3, only the DSCP in the outer header can be modified.
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
3. Order of Traffic Filtering Rules 3. Order of Traffic Filtering Rules
In comparing an applicable tunneled traffic flow specification with a In comparing an applicable tunneled traffic flow specification with a
non-tunneled flow specification, the tunneled specification has non-tunneled flow specification, the tunneled specification has
precedence. precedence.
If comparing two tunneled traffic flow specifications, if both are If comparing two tunneled traffic flow specifications, if both are
applicable, the tunnel types will be the same. If only one has a applicable, the tunnel types will be the same. If only one has a
Routing Discriminator, it has precedence. If both have a Routing Routing Discriminator, it has precedence. If both have a Routing
Discriminator, those discriminators are compared as unsigned integers Discriminator, then either those Routing Discriminators will be equal
and the one with the smaller magnitude Routing Discriminator has or only one of the Flow-specs will be applicable to the packet.
precedence.
If neither has a Routing Discriminator or they have equal Routing If neither has a Routing Discriminator or they have equal Routing
Discriminators, the order of precedence is determined by comparing Discriminators, the order of precedence is determined by comparing
the outer flowspec. the outer Flow-spec.
If the outer flowspecs are equal and the tunnel type calls for an If the outer Flow-specs are equal, then the Tunnel Header Flow-specs
inner flowspec, then the precedence is determined by comparing inner are compared using the usual component comparison rules.
AFI as an unsigned integer with the inner AFI having the smaller
magnitude having precedence. If the Tunnel Header Flow-specs are equal and the tunnel type calls
for an inner Flow-spec, then the precedence is determined by
comparing inner AFI as an unsigned integer with the inner AFI having
the smaller magnitude having precedence.
If the inner AFIs are equal, precedence is determined by comparing If the inner AFIs are equal, precedence is determined by comparing
the inner flow specifications. the inner flow specifications.
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
4. Flow Spec Validation 4. Flow Spec Validation
Flow-specs received over AFI=1/SAFI=TBD1 or AFI=2/SFAI=TBD1 are Flow-specs received over AFI=1/SAFI=TBD1 or AFI=2/SFAI=TBD1 are
validated, using only the outer Flow-spec, against routing validated, using only the outer Flow-spec, against routing
reachability received over AFI=1/SAFI=133 and AFI=2/SAFI=133 reachability received over AFI=1/SAFI=133 and AFI=2/SAFI=133
respectively, as modified by [FlowSpecOID]. respectively, as modified by [FlowSpecOID].
5. Security Considerations 5. Security Considerations
No new security issues are introduced to the BGP protocol by this No new security issues are introduced to the BGP protocol by this
specification. specification.
For general Flow-spec security considerations, see [rfc5575bis].
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign a new SAFI as follows: IANA is requested to assign a new SAFI as follows:
Value Description Reference Value Description Reference
----- ------------------------------------------ --------------- ----- ------------------------------------------ ---------------
TBD1 Tunneled traffic flow specification rules [This document] TBD1 Tunneled traffic flow specification rules [This document]
IANA is requested to assign two new values in the "Flow Spec IANA is requested to create a Tunnel Header Flow Spec Component Type
Component Types" registry as follows: registry on the Flow Spec Component Types registries web page as
follows:
Type Name Reference Name: Tunnel Flow Spec Component Types
---- -------------- --------- Reference: [this document]
TBD2 VN ID [this document] Registration Procedures:
TBD3 Flow ID [this document] 0 Reserved
TBD4 Session [this document] 1-127 Specification Required
TBD5 Cookie [this document] 128-254 First Come First Served
TBD6 VXLAN-GPE Flags [this document] 255 Reserved
Initial contents:
Type Name Reference
----- -------------- -----------
0 reserved
1 VN ID [this document]
2 Flow ID [this document]
3 Session [this document]
4 Cookie [this document]
5 VXLAN-GPE Flags [this document]
6-254 unassigned [this document]
255 reserved [this document]
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
Normative References Normative References
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
March 1997, <https://www.rfc-editor.org/info/rfc2119>. March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE",
skipping to change at page 14, line 38 skipping to change at page 15, line 38
[RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network [RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", RFC 7637, Virtualization Using Generic Routing Encapsulation", RFC 7637,
DOI 10.17487/RFC7637, September 2015, <https://www.rfc- DOI 10.17487/RFC7637, September 2015, <https://www.rfc-
editor.org/info/rfc7637>. editor.org/info/rfc7637>.
[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>. 2017, <https://www.rfc-editor.org/info/rfc8174>.
[FlowSpecL2] - W. Hao, etc, "Dissemination of Flow Specification [FlowSpecL2] - W. Hao, et al, "Dissemination of Flow Specification
Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in
progress. progress.
[FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. [FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P.
Mohapatra, "Revised Validation Procedure for BGP Flow Mohapatra, "Revised Validation Procedure for BGP Flow
Specifications", draft-ietf-idr-bgp-flowspec-oid, work in Specifications", draft-ietf-idr-bgp-flowspec-oid, work in
progress. progress.
[FlowSpecV6] - R. Raszuk, etc, "Dissemination of Flow Specification [FlowSpecV6] - R. Raszuk, et al, "Dissemination of Flow Specification
Rules for IPv6", draft-ietf-idr-flow-spec-v6, work in progress. Rules for IPv6", draft-ietf-idr-flow-spec-v6, work in progress.
[RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D., [RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D.,
Bacher, M., "Dissemination of Flow Specification Rules", draft- Bacher, M., "Dissemination of Flow Specification Rules", draft-
ietf-idr-rfc5575bis-17, Work in progress, January 2019. ietf-idr-rfc5575bis, Work in progress.
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
Informative References Informative References
[RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
Narten, "An Architecture for Data-Center Network Virtualization Narten, "An Architecture for Data-Center Network Virtualization
over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December
2016, <https://www.rfc-editor.org/info/rfc8014>. 2016, <https://www.rfc-editor.org/info/rfc8014>.
[GPE] - P. Quinn, etc, "Generic Protocol Extension for VXLAN", draft- [GPE] - P. Quinn, et al, "Generic Protocol Extension for VXLAN",
ietf-nvo3-vxlan-gpe, work in progress. draft-ietf-nvo3-vxlan-gpe, work in progress.
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
Acknowledgments Acknowledgments
The authors wish to acknowledge the important contributions of Jeff The authors wish to acknowledge the important contributions of Jeff
Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Robert Raszuk, Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Robert Raszuk,
and Lucy Yong. and Lucy Yong.
Authors' Addresses Authors' Addresses
skipping to change at page 17, line 9 skipping to change at page 18, line 9
Rong Gu Rong Gu
China Mobile China Mobile
Email: gurong_cmcc@outlook.com Email: gurong_cmcc@outlook.com
INTERNET-DRAFT BGP Tunnel Flow-Spec INTERNET-DRAFT BGP Tunnel Flow-Spec
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
 End of changes. 76 change blocks. 
160 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/