BGP Dissemination of L2 Flow Specification Rules

Abstract

This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined.¶

1. Introduction

Border Gateway Protocol (BGP) Flow Specification [RFC8955] (flowspec) is an extension to BGP that supports the dissemination of traffic flow specifications and resulting actions to be taken on packets in a specified flow. It leverages the BGP Control Plane to simplify the distribution of ACLs (Access Control Lists). Using the Flow Specification extension new filter rules can be injected to all BGP peers simultaneously without changing router configuration. A typical application is to automate the distribution of traffic filter lists to routers for DDoS (Distributed Denial of Service) mitigation, access control, and similar applications.¶

BGP Flow Specification [RFC8955] defines a BGP Network Layer Reachability Information (NLRI) format used to distribute traffic flow specification rules. The NLRI for (AFI=1, SAFI=133) specifies IPv4 unicast filtering. The NLRI for (AFI=1, SAFI=134) specifies IPv4 BGP/MPLS VPN filtering [RFC7432]. The Flow Specification match part defined in [RFC8955] only includes L3/L4 information like IPv4 source/destination prefix, protocol, ports, and the like, so traffic flows can only be filtered based on L3/L4 information. This has been extended by [RFC8956] to cover IPv6 (AFI=2) L3/L4.¶

Layer 2 Virtual Private Networks (L2VPNs) have been deployed in an increasing number of networks. Such networks also have requirements to deploy BGP Flow Specification to mitigate DDoS attack traffic. Within an L2VPN network, both IP and non-IP Ethernet traffic may exist. For IP traffic filtering, the VPN Flow Specification rules defined in [RFC8955] and/or [RFC8956], which include match criteria and actions, can still be used. For non-IP Ethernet traffic filtering, Layer 2 related information like source/destination MAC and VLAN must be considered.¶

There are different kinds of L2VPN networks like EVPN [RFC7432], BGP VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP) auto discovery [RFC6074]. Because the Flow Specification feature relies on the BGP protocol to distribute traffic filtering rules, it can only be incrementally deployed in those L2VPN networks where BGP has already been used for auto discovery and/or signaling purposes such as BGP-based VPLS [RFC4761], EVPN, and LDP-based VPLS [RFC4762] with BGP auto-discovery [RFC6074].¶

This document defines new flowspec component types and two new extended communities to support L2 and L2VPN flowspec applications. The flowspec rules can be enforced on all border routers or on some interface sets of the border routers. SAFI=133 in [RFC8955] and [RFC8956] is extended for AFI=6 as specified in Section 2 to cover L2 traffic filtering information and in Section 3 SAFI=134 is extended for AFI=25 to cover the L2VPN environment.¶

2. Layer 2 Flow Specification Encoding

[RFC8955] defines SAFI 133 and SAFI 134, with AFI=1, for "dissemination of IPv4 flow specification rules" and "dissemination of VPNv4 flow specification rules", respectively. [RFC8956] extends [RFC8955] to also allow AFI=2 thus making it applicable to both IPv4 and IPv6 applications. This document further extends SAFI=133 for AFI=6 and SAFI=134 for AFI=25 to make them applicable to L2 and L2VPN applications. This document also provides for the optional combination of L3 flow specifications with these L2 flow specifications.¶

This section specifies the L2 flowspec for AFI=6/SAFI=133. To simplify assignments, a new registry is used for L2 flowspec. Since it is frequently desirable to also filter on L3/L4 fields, provision is made for their inclusion along with an indication of the L3 protocol involved (IPv4 or IPv6).¶

The NLRI part of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as a 1- or 2-octet total NLRI length field followed by several fields as described below.¶

+-------------------------------+
| total-length (0xnn or 0xfnnn) |  2 or 3 octets
+-------------------------------+
|             L3-AFI            |  2 octets
+-------------------------------+
|  L2-length (0xnn or 0xfnnn)   |  2 or 3 octets
+-------------------------------+
|           NLRI-value          |  variable
+-------------------------------+

The fields show in Figure 1 are further specified below:¶

total-length:

The length of the subsequent fields (L3 AFI, L2-length, and NRLI-value) encoded as provided in Section 4.1 of [RFC8955]. If this field is less than 4, which is the minimum valid value, then the NLRI is malformed in which case a NOTIFICATION message is sent and the BGP connection closed as provided in Section 6.3 of [RFC4271].¶

L3-AFI:

If no L3/L4 filtering is desired, this two octet field MUST be zero which is a reserved AFI value. Otherwise L3-AFI indicates the L3 protocol involved by giving its AFI (0x0001 for IPv4 or 0x0002 for IPv6). If the receiver does not understand the value of the L3-AFI field, the MP_REACH or MP_UNREACH attribute is ignored.¶

L2-length:

The length of the L2 components at the beginning of the NLRI-value field encoded as provided in Section 4.1 of [RFC8955]. If the value of this field indicates that the L2 components extend beyond the total-length, the NLRI is malformed in which case a NOTIFICATION message is sent and the BGP connection closed as provided in Section 6.3 of [RFC4271]. N2-length MAY be zero although, in that case, it would have been more efficient to encode the attribute as an L3 Flow spec unless it is desired to apply an L2 action (see Section 4). A null L2 flowspec always matches.¶

NLRI-value:

This consists of the L2 flowspec, of length L2-length, followed by an optionally present L3 flowspec. The result can be treated in most ways as a single flowspec, matching the intersection (AND) of all the components except that the components in the initial L2 region are interpreted as L2 components and the remainder as L3 components per the L3-AFI field. This is necessary because there are different registries for the L2, L3 IPv4, and L3 IPv6 component types. If the L3 flowspec is null (length zero), it always matches.¶

flow_rule_L2_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;
        }

        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
        }
    }
    return EQUAL;
}

3. L2VPN Flow Specification Encoding in BGP

The NLRI format for AFI=25/SAFI=134 (L2VPN), as with the other VPN flowspec AFI/SAFI pairs, is the same as the non-VPN Flow-Spec but with the addition of a Route Distinguisher to identify the VPN to which the flowspec is to be applied.¶

In addition, the IANA entry for SAFI 134 is slightly generalized as specified at the beginning of Section 6.¶

The L2VPN NLRI format is as follows:¶

+-------------------------------+
| total-length (0xnn or 0xfnnn) |  2 or 3 octets
+-------------------------------+
|      Route Distinguisher      |  8 octets
+-------------------------------+
|            L3-AFI             |  2 octets
+-------------------------------+
|  L2-length (0xnn or 0xfnnn)   |  2 or 3 octets
+-------------------------------+
|           NLRI-value          |  variable
+-------------------------------+

The fields in Figure 2, other than the Route Distinguisher, are encoded as specified in Section 2 except that the minimum value for total-length is 12.¶

Flow specification rules received via this NLRI apply only to traffic that belongs to the VPN instance(s) into which it is imported. Flow rules are accepted as specified in Section 5.¶

4. Ethernet Flow Specification Traffic Actions

The default action for an L2 traffic filtering flowspec is to accept traffic that matches that particular rule. The following extended community values per [RFC8955] can be used to specify particular actions in an L2 VPN network:¶

Redirect: The action should be redefined to allow the traffic to be redirected to a MAC or IP VRF routing instance that lists the specified route-target in its import policy.¶

Besides the above extended communities, this document also specifies the following BGP extended communities for Ethernet flows to extend [RFC8955]:¶

  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PO1|PU1|SW1|RI1|RO1| Resv      |PO2|PU2|SW2|RI2|RO2| Resv      |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| VLAN ID1                                      | PCP1      |DE1|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| VLAN ID2                                      | PCP2      |DE2|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 |1 |0 |0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 10                                |1 |0 |1 |0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 20                                |1 |1 |0 |0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TI|TO|                     Resv                |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    TP ID1                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    TP ID2                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

5. Flow Spec Validation

Flow Specifications received over AFI=25/SAFI=134 are validated against routing reachability received over AFI=25/SAFI=128 as modified to conform to [RFC9117].¶

6. IANA Considerations

IANA is requested to change the description for SAFI 134 [RFC8955] to read as follows and to change the reference for it to [this document]:¶

134  VPN dissemination of flow specification rules¶

IANA is requested to create an L2 Flow Specification Component Type registry on the Flow Spec Component Types registries web page as follows:¶

   Name:  L2 Flow Specification Component Types
   Reference: [this document]
   Registration Procedures:

            0  Reserved
        1-127  Specification Required
      128-255  First Come First Served

Initial contents:¶

IANA is requested to assign two values from the "BGP Extended Communities Type - extended, transitive" registry [suggested value provided in square brackets]:¶

7. Security Considerations

For General BGP Flow Specification Security Considerations, see [RFC8955].¶

VLAN tagging identifies Layer 2 communities which are commonly expected to be isolated except when higher layer connection is provided, such as Layer 3 routing. Thus, the ability of the flowspec VLAN action to change the VLAN ID in a frame might compromise security.¶

8. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4761]

Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.

[RFC4762]

Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.

[RFC6074]

Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8955]

Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.

[RFC8956]

Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, <https://www.rfc-editor.org/info/rfc8956>.

[RFC9117]

Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", RFC 9117, DOI 10.17487/RFC9117, August 2021, <https://www.rfc-editor.org/info/rfc9117>.

9. Informative References

[IEEE802.1Q]

IEEE 802, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks", IEE Std 802.1Q-2014, 3 November 2014.

[RFC7042bis]

Eastlake, D., Abley, J., and Y. Li, "OUI Registry Restructuring", work in Progress, 14 April 2023, <https://www.ietf.org/archive/id/draft-intarea-rfc7042bis-02.txt>.

[RFC7432]

Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.