RFC 5575

Dissemination of Flow Specification Rules

📅 published August 2009, from ietf

Dissemination of Flow Specification Rules 🎀

Okay bestie, let's talk about RFC 5575! 💖 It was published in August 2009 as a Standards Track document in the Network Working Group, so it's an actual internet standard, not a vibe. It was written by P. Marques (Cisco Systems), N. Sheth (Juniper Networks), R. Raszuk (Cisco Systems), B. Greene (Juniper Networks), J. Mauch (NTT America), and D. McPherson (Arbor Networks). Its title block doesn't list anything it obsoletes or updates, so it's standing on its own. 🦋

Abstract ✨

Okay so this doc defines a brand new BGP Network Layer Reachability Information (BGP NLRI) encoding format 💅 that can be used to distribute traffic flow specifications. This lets the routing system pass along info about more specific pieces of a traffic aggregate, the kind you'd normally pin to one IP destination prefix. Iconic. 👑

It also defines two applications of that encoding. The first automates inter-domain coordination of traffic filtering, which is what you need when you're trying to mitigate (distributed) denial-of-service attacks. The second provides traffic filtering inside a BGP/MPLS VPN service. 🔥

The info rides along on BGP, so it reuses protocol algorithms, operational experience, and admin processes like inter-provider peering agreements. No reinventing the wheel, periodt. 🌈

Status of This Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 💜

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🧚

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication. Read these carefully, bestie, because they describe your rights and restrictions for this document. The info is at http://trustee.ietf.org/license-info. 💅

Table of Contents 🍓

   1. Introduction ....................................................3
   2. Definitions of Terms Used in This Memo ..........................5
   3. Flow Specifications .............................................5
   4. Dissemination of Information ....................................6
   5. Traffic Filtering ..............................................12
      5.1. Order of Traffic Filtering Rules ..........................13
   6. Validation Procedure ...........................................14
   7. Traffic Filtering Actions ......................................15
   8. Traffic Filtering in BGP/MPLS VPN Networks .....................17
   9. Monitoring .....................................................18
   10. Security Considerations .......................................18
   11. IANA Considerations ...........................................19
   12. Acknowledgments ...............................................20
   13. Normative References ..........................................21

1. Introduction 💖

Modern IP routers can forward traffic based on IP prefixes, and they can also classify, shape, rate limit, filter, or redirect packets based on administratively defined policies. Main character energy. 👑

These traffic policy mechanisms let the router define match rules that look at multiple fields of the packet header. Each rule can be paired with actions like the ones above. ✨

The n-tuple made of those matching criteria is what defines an aggregate traffic flow specification. The criteria can include things like source and destination address prefixes, the IP protocol, and transport protocol port numbers. 🦋

This document defines a general way to encode flow specification rules for aggregated traffic flows, so they can be distributed as a BGP [RFC4271] NLRI. 🌈 It also defines the mechanisms needed to apply all this to the problem the authors were most worried about: distributing traffic filtering rules across intra- and inter-provider boundaries so they can filter (distributed) denial-of-service (DoS) attacks. 🔥

By adding flow specifications to routing info, the routing system can take advantage of the ACL (Access Control List) or firewall capabilities in the router's forwarding path. Flow specs can be seen as more specific routing entries to a unicast prefix, and they're expected to depend on the existing unicast data information. 💅

A flow specification received from an external autonomous system will need to be validated against unicast routing before being accepted. 🙈 If the aggregate traffic flow defined by the unicast destination prefix is forwarded to a given BGP peer, then the local system can safely install more specific flow rules. Those rules may result in different forwarding behavior, as requested by that system. 🫶

The key technology components needed for the class of problems this document targets are:

  1. Efficient point-to-multipoint distribution of control plane information.
  2. Inter-domain capabilities and routing policy support.
  3. Tight integration with unicast routing, for verification purposes.

Items 1 and 2 are already handled by BGP for other types of control plane information. ✨ Close integration with BGP also makes it feasible to specify a mechanism that automatically verifies flow information against unicast routing. That's why BGP was picked to carry flow specification info. 💜

Like previous BGP extensions, this specification makes it possible to add more information to Internet routers. Those routers have limits on how many data elements they can hold and how many events they can process in a given unit of time. The authors believe that, like before, service providers will be careful to keep information levels below the maximum capacity of their devices. 🌸

It's also expected that, in many early deployments, flow specification info will replace existing host length route advertisements rather than add to them. 🍓

Experience with previous BGP extensions has also shown that the maximum capacity of BGP speakers has gradually increased according to expected loads. Taking into account Internet unicast routing as well as additional applications as they gain popularity. 📈

From an operations point of view, using BGP as the carrier lets a network service provider reuse both internal route distribution infrastructure (e.g., route reflector or confederation design) and existing external relationships (e.g., inter-domain BGP sessions to a customer network). Bestie, that's a lot of reuse. 🧚

It's totally possible to solve this with other mechanisms, but the authors think this solution has a big advantage: it's an incremental addition to mechanisms that are already deployed. 💅

In current deployments, the info distributed by the flow-spec extension is originated both manually and automatically. The automatic part comes from systems that are able to detect malicious flows. When automated systems are used, care should be taken to ensure their correctness, as well as to limit the number and advertisement rate of flow routes. 🚨

This specification defines the required protocol extensions to address most common applications of IPv4 unicast and VPNv4 unicast filtering. The same mechanism can be reused, with new match criteria added, to address similar filtering needs for other BGP address families (for example, IPv6 unicast). The authors believe those would be best addressed in a separate document. 🦋

2. Definitions of Terms Used in This Memo 📚

  • NLRI - Network Layer Reachability Information
  • RIB - Routing Information Base
  • Loc-RIB - Local RIB
  • AS - Autonomous System number
  • VRF - Virtual Routing and Forwarding instance
  • PE - Provider Edge router

Okay so when this doc says "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", or "OPTIONAL", those words mean exactly what RFC 2119 [RFC2119] says they mean. 🫶 Yes, these are the official key words, so they're capital-letter serious. 💀

3. Flow Specifications 🌈

A flow specification is an n-tuple made of several matching criteria that can be applied to IP traffic. 💖 A given IP packet is considered to match the defined flow only if it matches all of the specified criteria. Every single one, bestie. ✨

A given flow may come with a set of attributes, depending on the application. Those attributes may or may not include reachability info, such as NEXT_HOP. Well-known or AS-specific community attributes can be used to encode a set of predetermined actions. 💅

A particular application is identified by a specific (Address Family Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair [RFC4760], and each one corresponds to a distinct set of RIBs. Those RIBs should be treated independently of each other, so the applications don't interfere with one another. 🧚

BGP itself treats the NLRI as an opaque key to an entry in its databases. Entries that land in the Loc-RIB then get a set of semantics, and those semantics depend on the application. This is consistent with existing BGP applications. For example, IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse-path information (AFI=1, SAFI=2) are handled by BGP without any particular semantics attached until they're installed in the Loc-RIB. 🌸

Standard BGP policy mechanisms, like UPDATE filtering by NLRI prefix and community matching, SHOULD apply to the newly defined NLRI type. 👑 Network operators can also control propagation of these routing updates by enabling or disabling the exchange of a particular (AFI, SAFI) pair on a given BGP peering session. Total control, iconic. 🔥

Part 1 of 4 is done, bestie! 🌈💖

4. Dissemination of Information 📡

okay so this is where the Flow Specification NLRI gets its glow-up 💅 We define a "Flow Specification" NLRI type that can hold a bunch of components, like destination prefix, source prefix, protocol, ports, and more ✨ BGP doesn't peek inside it. It treats the whole thing as an opaque bit string prefix 🙈 Each bit string is basically a key into a database entry, and that entry is where a set of attributes gets attached 🔑 iconic, honestly.

This NLRI info gets carried in MP_REACH_NLRI and MP_UNREACH_NLRI attributes, the ones defined in RFC 4760 [RFC4760] 🎀 If the application doesn't need Next-Hop information, it shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI attribute, and it gets ignored on receipt. Not complicated, just vibes 🌸

The NLRI field of MP_REACH_NLRI and MP_UNREACH_NLRI is a 1- or 2-octet NLRI length field, followed by a variable-length NLRI value. The NLRI length is counted in octets 🧚

                  +------------------------------+
                  |    length (0xnn or 0xfn nn)  |
                  +------------------------------+
                  |    NLRI value  (variable)    |
                  +------------------------------+

                          flow-spec NLRI

If the NLRI length is smaller than 240 (0xf0 hex), the length fits in a single octet. Otherwise, it's an extended-length 2-octet value where the most significant nibble of the first byte is all ones. Very dramatic, very effective 💖

Quick breakdown: values less than 240 are written with two hex digits, 0xnn. Values above 240 use three hex digits, 0xfnnn. The highest value you can represent this way is 4095. So 241 becomes 0xf0f1. Math is never the enemy 🫶

The Flow specification NLRI-type has several optional subcomponents. A specific packet counts as matching the flow specification when it matches the intersection (AND) of every component present in the spec. So every single component has to be true at the same time, no exceptions 👑

Here are the component types that are defined 👇

Type 1 - Destination Prefix 🎯

Encoding: <type (1 octet), prefix length (1 octet), prefix>

This defines the destination prefix to match. Prefixes are encoded the same way they are in BGP UPDATE messages: a length in bits, followed by enough octets to hold the prefix info. 🌈

Type 2 - Source Prefix 🎯

Encoding: <type (1 octet), prefix-length (1 octet), prefix>

This defines the source prefix to match. Same energy as Type 1, just flipped to the other end 🦋

Type 3 - IP Protocol 🧩

Encoding: <type (1 octet), [op, value]+>

This holds a set of {operator, value} pairs that get used to match the IP protocol value byte in IP packets. The operator byte is laid out like this:

              0   1   2   3   4   5   6   7
            +---+---+---+---+---+---+---+---+
            | e | a |  len  | 0 |lt |gt |eq |
            +---+---+---+---+---+---+---+---+

                       Numeric operator
  • e: end-of-list bit. It's set in the last {op, value} pair in the list. Last one out, flip the light 💡
  • a: AND bit. If it's unset, the previous term gets logically ORed with the current one. If it's set, the operation is a logical AND. It should be unset in the first operator byte of a sequence. Also, AND outranks OR when evaluating logical expressions, so AND gets to go first 👑
  • len: the length of the value field for this operand is given as (1 << len). Bit-shift energy 💅
  • lt: less than comparison between data and value.
  • gt: greater than comparison between data and value.
  • eq: equality between data and value.

The lt, gt, and eq bits can be mixed to make "less or equal", "greater or equal", and inequality. It's like a little Lego set for comparisons 🧱

Type 4 - Port 🚪

Encoding: <type (1 octet), [op, value]+>

This defines a list of {operation, value} pairs that matches source OR destination TCP/UDP ports. The list uses the numeric operand format from above, and the values are 1- or 2-byte quantities 🍓

Port, source port, and destination port components all evaluate to FALSE if the IP protocol field has a value other than TCP or UDP, if the packet is fragmented and this isn't the first fragment, or if the system is unable to locate the transport header. Also, different implementations may or may not be able to decode the transport header when there are IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. Not every implementation is going to be able to read through that, and that's okay 🙈

Type 5 - Destination port 🚪

Encoding: <type (1 octet), [op, value]+>

This defines a list of {operation, value} pairs used to match the destination port of a TCP or UDP packet. Values are 1- or 2-byte quantities 💜

Type 6 - Source port 🚪

Encoding: <type (1 octet), [op, value]+>

This defines a list of {operation, value} pairs used to match the source port of a TCP or UDP packet. Values are 1- or 2-byte quantities too 🌸

Type 7 - ICMP type 🏓

Encoding: <type (1 octet), [op, value]+>

This defines a list of {operation, value} pairs used to match the type field of an ICMP packet. Values are encoded using a single byte. The ICMP type and code specifiers evaluate to FALSE whenever the protocol value is not ICMP, so they only work for ICMP packets 🧚

Type 8 - ICMP code 🏓

Encoding: <type (1 octet), [op, value]+>

This defines a list of {operation, value} pairs used to match the code field of an ICMP packet. Values are encoded using a single byte. Type 7's sibling, basically 👯‍♀️

Type 9 - TCP flags 🚩

Encoding: <type (1 octet), [op, bitmask]+>

Bitmask values can be encoded as a 1- or 2-byte bitmask. When a single byte is specified, it matches byte 13 of the TCP header [RFC0793], which holds bits 8 though 15 of the 4th 32-bit word. When a 2-byte encoding is used, it matches bytes 12 and 13 of the TCP header, with the data offset field treated as a "don't care" value.

Just like the port specifiers, this component evaluates to FALSE for packets that aren't TCP packets 🙅‍♀️

This type uses the bitmask operand format, which is different from the numeric operator format in the lower nibble:

              0   1   2   3   4   5   6   7
            +---+---+---+---+---+---+---+---+
            | e | a |  len  | 0 | 0 |not| m |
            +---+---+---+---+---+---+---+---+
  • e, a, len: the most significant nibble (end-of-list bit, AND bit, and length field), as defined in the numeric operator format.
  • not: NOT bit. If it's set, it's a logical negation of the operation. Opposite day 🙃
  • m: match bit. If it's set, this is a bitwise match operation defined as (data & value) == value. If it's unset, (data & value) evaluates to TRUE if any of the bits in the value mask are set in the data.

Type 10 - Packet length 📦

Encoding: <type (1 octet), [op, value]+>

This matches on the total IP packet length, which excludes Layer 2 but includes the IP header. Values are 1- or 2-byte quantities 📏

Type 11 - DSCP (Diffserv Code Point) 💁‍♀️

Encoding: <type (1 octet), [op, value]+>

This defines a list of {operation, value} pairs used to match the 6-bit DSCP field [RFC2474]. Values are encoded using a single byte, where the two most significant bits are zero and the six least significant bits hold the DSCP value. ✨

Type 12 - Fragment 🧩

Encoding: <type (1 octet), [op, bitmask]+>

This uses the bitmask operand format we just went over:

              0   1   2   3   4   5   6   7
            +---+---+---+---+---+---+---+---+
            |   Reserved    |LF |FF |IsF|DF |
            +---+---+---+---+---+---+---+---+

The bitmask values are:

  • Bit 7 - Don't fragment (DF)
  • Bit 6 - Is a fragment (IsF)
  • Bit 5 - First fragment (FF)
  • Bit 4 - Last fragment (LF)

Okay, the ordering rule is a big one, so listen up 👂 Flow specification components must follow strict type ordering. A given component type may or may not be present in the specification, but if it is present, it MUST precede any component of a higher numeric type value. No shuffling allowed 🙅‍♀️

If a given component type within a prefix is unknown, the prefix in question cannot be used for traffic filtering by the receiver. And since a flow specification has the semantics of a logical AND of all its components, if one component is FALSE, by definition the whole thing can't be applied. However, for BGP route propagation, this prefix should still be transmitted, because BGP route distribution doesn't depend on NLRI semantics. So it still gets passed along, even if nobody can filter with it 🦋

The <type, value> encoding is picked so it can handle future extensibility. Future-proof, bestie 🔮

Now for an example. Here's a flow specification encoding for: "all packets to 10.0.1/24 and TCP port 25" 💌

+------------------+----------+----------+
| destination      | proto    | port     |
+------------------+----------+----------+
| 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 |
+------------------+----------+----------+

Decode for protocol:

+-------+----------+------------------------------+
| Value |          |                              |
+-------+----------+------------------------------+
|  0x03 | type     |                              |
|  0x81 | operator | end-of-list, value size=1, = |
|  0x06 | value    |                              |
+-------+----------+------------------------------+

Another one, and this one's a whole production 🎬 Here's a flow specification encoding for: "all packets to 10.0.1/24 from 192/8 and port {range [137, 139] or 8080}" 🌟

+------------------+----------+-------------------------+
| destination      | source   | port                    |
+------------------+----------+-------------------------+
| 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 |
+------------------+----------+-------------------------+

Decode for port:

+--------+----------+------------------------------+
|  Value |          |                              |
+--------+----------+------------------------------+
|   0x04 | type     |                              |
|   0x03 | operator | size=1, >=                   |
|   0x89 | value    | 137                          |
|   0x45 | operator | &, value size=1, <=          |
|   0x8b | value    | 139                          |
|   0x91 | operator | end-of-list, value-size=2, = |
| 0x1f90 | value    | 8080                         |
+--------+----------+------------------------------+

This constitutes an NLRI with an NLRI length of 16 octets. Main character energy, literally 👑

Last but not least, the capability stuff 🤝 Implementations that want to exchange flow specification rules MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1), as defined in RFC 4760 [RFC4760]. The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability MUST be the same as the one used to identify a particular application that uses this NLRI-type. So everyone's on the same page, and the handshake is perfectly matched 🌈✨

5. Traffic Filtering ✨

okay so traffic filtering has traditionally been kinda static, like set-it-and-forget-it 💅

DoS attacks are everywhere right now, and they usually need the network operator to use traffic filters to detect and mitigate them. That brings requirements that existing tools don't fully cover 😭

Stopping DoS also increasingly needs several service providers to work together, so they can figure out where the traffic is coming from. The volumes can be so huge that they'd otherwise seriously hurt network performance 🫠

There are a few techniques people use right now to filter DoS traffic, and one of the most common is injecting unicast route advertisements for the destination prefix being attacked 🎀 One version tags those advertisements with a community that the receiving router turns into a discard Next-Hop. Other versions attract the traffic to one specific node that acts as a predictable drop point 🦋

Using unicast routing advertisements to spread filtering info is a big win because it reuses the infrastructure you already have and the inter-AS communication channels too ✨ For example, a service provider can accept filtering requests from customers for address space those customers own. iconic behavior 👑

BUT there are drawbacks 💀 The biggest one is granularity: you can only specify destination prefixes. The other problem is that filtering info gets mixed up with routing info, which is messy 🙈

This mechanism is designed to fix those limitations 💖 It uses the flow specification NLRI defined above to carry info about traffic filtering rules for traffic that should be discarded.

This mechanism is mainly built so an upstream autonomous system can do inbound filtering on its ingress routers, for traffic that a given downstream AS wants to drop 🌸

To make that happen, we define an application-specific NLRI identifier (AFI=1, SAFI=133) along with specific semantic rules 🧚

BGP routing updates with this identifier use the flow specification NLRI encoding to carry particular aggregated flows that need special treatment ⭐

Flow routing info received through this (AFI, SAFI) pair goes through the validation procedure described below 🫶

5.1. Order of Traffic Filtering Rules

Okay, so here's the thing: more than one rule can match the same traffic flow 🌈 That means we need to define the order in which rules get matched and applied to a flow. This ordering has to be consistent across the network, and it can't depend on the order the flow specification rules arrived in 💜

To compare two flow specification rules, you compare their components. The algorithm starts with the left-most components of each rule. If the types are different, the rule with the lowest numeric type value gets higher precedence, which means it matches first, over the rule that doesn't have that component type at all ✨ If the component types match, a type-specific comparison happens instead 🎀

For IP prefix values (IP destination and source prefix), precedence goes to the lowest IP value of the common prefix length. If the common prefix is equal, then the most specific prefix wins 👑

For all other component types, unless specified otherwise, the data gets compared as a binary string using the memcmp() function from the ISO C standard 🍓 For strings of different lengths, the common prefix gets compared first. If those are equal, the longer string has higher precedence than the shorter one 💅

Pseudocode:

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

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

6. Validation Procedure 🔍

Flow specifications received from a BGP peer that get accepted into the respective Adj-RIB-In are used as input to the route selection process 💖 Even when two routes for the same flow specification prefix have the same forwarding attributes, BGP still has to run its path selection algorithm to pick the right set of attributes to advertise 🫶

The first step of the BGP Route Selection procedure (Section 9.1.2 of [RFC4271]) is to kick non-feasible routes out of the selection process 🙅‍♀️ For normal IP routing info, this step checks that a route's NEXT_HOP attribute is resolvable.

This concept can be extended for flow specification NLRI so other validation procedures can be used too ✨

A flow specification NLRI must be validated so that it is considered feasible if and only if:

a) The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification.

b) There are no more specific unicast routes, compared with the flow destination prefix, that were received from a different neighboring AS than the best-match unicast route determined in step a).

By originator of a BGP route, we mean either the BGP originator path attribute (the one used by route reflection), or the transport address of the BGP peer, if that path attribute isn't present 🧚

The underlying idea is that the neighboring AS advertising the best unicast route for a destination is allowed to advertise flow-spec info with a more or equally specific destination prefix 🌸 So as long as there are no more specific unicast routes from a different neighboring AS that would be affected by that filtering rule, it's all good 👑

The neighboring AS is the immediate destination of the traffic described by the flow specification 💅 If it asks for these flows to be dropped, that request can be honored without worrying that it's a denial of service in itself. Supposedly, the traffic is getting dropped by the downstream autonomous system, so there's no added value in carrying it all the way there 🦋

BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, enforcing it becomes necessary for security reasons 🔥

⚠️ security bestie alert: the eBGP AS_PATH rule above is optional in the BGP spec, but for security reasons it becomes necessary to enforce it 😭

7. Traffic Filtering Actions 🎀

This specification defines a minimum set of filtering actions that it standardizes as BGP extended community values [RFC4360] 💜 This isn't meant to be a complete list of every possible action, just a subset that can be interpreted consistently across the network ✨

Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to filtering actions that need different mappings in different systems across the network 🌈 For example, giving packets a worse-than-best-effort, per-hop behavior is something likely to be implemented differently in different systems, and no standard behavior for it is currently known 🙈 Instead of trying to define that here, you can map a user-defined community value to platform-/network-specific behavior through user configuration 🫶

The default action for a traffic filtering flow specification is to accept IP traffic that matches that particular rule 💖

The following extended community values can be used to specify particular actions.

+--------+--------------------+--------------------------+
| type   | extended community | encoding                 |
+--------+--------------------+--------------------------+
| 0x8006 | traffic-rate       | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action     | bitmask                  |
| 0x8008 | redirect           | 6-byte Route Target      |
| 0x8009 | traffic-marking    | DSCP value               |
+--------+--------------------+--------------------------+

Traffic-rate: The traffic-rate extended community is a non-transitive extended community across the autonomous-system boundary, and it uses the following extended community encoding 🍓

The first two octets carry the 2-octet id, which can be assigned from a 2-byte AS number. When a 4-byte AS number is locally present, the 2 least significant bytes of that AS number can be used. This value is purely informational and should not be interpreted by the implementation 🧚

The remaining 4 octets carry the rate information in IEEE floating point [IEEE.754.1985] format, with units in bytes per second. A traffic-rate of 0 should result in all traffic for the particular flow being discarded 💀

Traffic-action: The traffic-action extended community consists of 6 bytes, and only the 2 least significant bits of the 6th byte (from left to right) are currently defined 🌸

               40  41  42  43  44  45  46  47
             +---+---+---+---+---+---+---+---+
             |        reserved       | S | T |
             +---+---+---+---+---+---+---+---+
  • Terminal Action (bit 47): When this bit is set, the traffic filtering engine applies any subsequent filtering rules (as defined by the ordering procedure). If it isn't set, evaluation of the traffic filter stops once this rule is applied 🛑
  • Sample (bit 46): Enables traffic sampling and logging for this flow specification 📸

Redirect: The redirect extended community allows traffic to be redirected to a VRF routing instance that lists the specified route-target in its import policy 🦋 If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the Route Target extended community [RFC4360] 💅

Traffic Marking: The traffic marking extended community tells a system to modify the DSCP bits of a transiting IP packet to the corresponding value 🎀 It's encoded as a sequence of 5 zero bytes, followed by the DSCP value encoded in the 6 least significant bits of the 6th byte 💖

8. Traffic Filtering in BGP/MPLS VPN Networks ✨

Okay bestie, provider-based Layer 3 VPNs like the ones using the BGP/MPLS IP VPN [RFC4364] control plane 🎀 have different traffic filtering needs than Internet service providers do. Totally different vibe.

The VPN customer network usually has filtering set up toward its external connections, like the firewall-facing public network connection 🧱. Filtering between VPN attachment sites is way less common 🙈. In an any-to-any connectivity model, which is the default, that means site-to-site traffic is basically unfiltered. Not ideal, honestly.

And if a security threat gets propagated inside the VPN customer network, there may not be easy mitigation tools available through a traffic filter. Scary stuff 😭.

This document proposes an additional BGP NLRI type (AFI=1, SAFI=134) value 💜, which can be used to spread traffic filtering information around a BGP/MPLS VPN environment. Main character energy 👑.

The NLRI format for this address family is a fixed-length Route Distinguisher field (8 bytes) followed by a flow specification, encoded the way this document defines. The NLRI length field shall include both the 8 bytes of the Route Distinguisher and the flow specification that follows 📏.

Whether this NLRI gets propagated is controlled by matching the Route Target extended communities attached to the BGP path advertisement against the VRF import policy. It's the same mechanism described in "BGP/MPLS IP VPNs" [RFC4364] ✨.

Flow specification rules received via this NLRI only apply to traffic that belongs to the VRF(s) they're imported into 🦋. By default, traffic coming from a remote PE gets switched via an MPLS forwarding decision and is NOT subject to filtering. Okay, so it's chill by default 🌸.

Here's the plot twist 😳: unlike the non-VPN NLRI, flow rules are accepted by default when they come from remote PE routers. Totally opposite energy, and I'm obsessed 💅.

9. Monitoring 📊

Traffic filtering applications need monitoring and traffic statistics facilities. It's an implementation-specific choice, but implementations SHOULD provide:

  • A mechanism to log the packet header of filtered traffic. 🧾
  • A mechanism to count the number of matches for a given flow specification rule. 🔢

10. Security Considerations 🚨

Okay, this section is serious, so no cap, read it carefully 🫶.

Inter-provider routing runs on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If that trust model gets violated, a neighboring autonomous system can cause a denial-of-service attack by advertising reachability information for a prefix it doesn't actually serve 💀.

As long as traffic filtering rules stay restricted to match the corresponding unicast routing paths for the relevant prefixes, the security characteristics of this proposal are equivalent to the existing security properties of BGP unicast routing 🔐.

If they don't match, though, that opens the door to even more denial-of-service attacks. Not it 😤.

Also, enabling firewall-like capabilities in routers without centralized management could make certain failures way harder to diagnose 🕵️‍♀️. For example, it's possible to let TCP packets pass between a pair of addresses while blocking ICMP packets. It's also possible to let packets smaller than 900 or greater than 1000 bytes pass between a pair of addresses while blocking packets whose length is in the range 900-1000. Confusing behavior, periodt 🙃. These capabilities should be used with care, whether they're configured manually or coordinated through the protocol extensions described in this document 🫠.

11. IANA Considerations 🗂️

A flow specification is made of a sequence of flow components, each identified by an 8-bit component type. Types must be assigned and interpreted uniquely. The current specification defines types 1 through 12, and the value 0 is reserved 🔒.

For this work, IANA allocated two SAFIs: SAFI 133 for IPv4 dissemination of flow specification rules, and SAFI 134 for VPNv4 dissemination of flow specification rules 🎉.

The following traffic filtering flow specification rules were allocated by IANA from the "BGP Extended Communities Type - Experimental Use" registry:

0x8006 - Flow spec traffic-rate
0x8007 - Flow spec traffic-action
0x8008 - Flow spec redirect
0x8009 - Flow spec traffic-remarking

IANA also created and maintains a brand new registry called "Flow Spec Component Types" 📒. These component types have been registered:

Type 1 - Destination Prefix
Type 2 - Source Prefix
Type 3 - IP Protocol
Type 4 - Port
Type 5 - Destination port
Type 6 - Source port
Type 7 - ICMP type
Type 8 - ICMP code
Type 9 - TCP flags
Type 10 - Packet length
Type 11 - DSCP
Type 12 - Fragment

Since the number space is limited and has to serve several usages, the following policies from RFC 5226 [RFC5226] are used 🧮:

+--------------+-------------------------------+
| Range        | Policy                        |
+--------------+-------------------------------+
| 0            | Invalid value                 |
| [1 .. 12]    | Defined by this specification |
| [13 .. 127]  | Specification Required        |
| [128 .. 255] | First Come First Served       |
+--------------+-------------------------------+

A specific "flow component type" needs to clearly say what criteria are used to match packets forwarded by the router. Those criteria should be meaningful across router hops and shouldn't depend on values that change hop-by-hop, like TTL or Layer 2 encapsulation 🧠.

The "traffic-action" extended community defined in this document has 46 unused bits that can carry extra meaning 🌈. IANA created and maintains a new registry called "Traffic Action Fields". These values should be assigned via IETF Review rules only. The following traffic-action fields have been allocated:

47 Terminal Action
46 Sample
0-45 Unassigned

12. Acknowledgments 🫶

The authors want to thank Yakov Rekhter, Dennis Ferguson, Chris Morrow, Charlie Kaufman, and David Smith for their comments 💖.

Chaitanya Kodeboyina helped design the flow validation procedure 🧩.

Steven Lin and Jim Washburn ironed out all the details needed to produce a working implementation 🛠️. Literal legends 👑.

13. Normative References 📚

[IEEE.754.1985]  Institute of Electrical and Electronics Engineers,
                 "Standard for Binary Floating-Point Arithmetic",
                 IEEE Standard 754, August 1985.

[RFC0793]        Postel, J., "Transmission Control Protocol", STD 7,
                 RFC 793, September 1981.

[RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2474]        Nichols, K., Blake, S., Baker, F., and D. Black,
                 "Definition of the Differentiated Services Field (DS
                 Field) in the IPv4 and IPv6 Headers", RFC 2474,
                 December 1998.

[RFC4271]        Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
                 Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4303]        Kent, S., "IP Encapsulating Security Payload (ESP)",
                 RFC 4303, December 2005.

[RFC4360]        Sangli, S., Tappan, D., and Y. Rekhter, "BGP
                 Extended Communities Attribute", RFC 4360,
                 February 2006.

[RFC4364]        Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
                 Private Networks (VPNs)", RFC 4364, February 2006.

[RFC4760]        Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
                 "Multiprotocol Extensions for BGP-4", RFC 4760,
                 January 2007.

[RFC5226]        Narten, T. and H. Alvestrand, "Guidelines for
                 Writing an IANA Considerations Section in RFCs",
                 BCP 26, RFC 5226, May 2008.

Authors' Addresses 🧑‍💻🧑‍💻

Pedro Marques
Cisco Systems
170 West Tasman Drive
San Jose, CA  95134
US
EMail: roque@cisco.com


Nischal Sheth
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
US
EMail: nsheth@juniper.net


Robert Raszuk
Cisco Systems
170 West Tasman Drive
San Jose, CA  95134
US
EMail: raszuk@cisco.com


Barry Greene
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
US
EMail: bgreene@juniper.net


Jared Mauch
NTT America
101 Park Ave
41st Floor
New York, NY  10178
US
EMail: jmauch@us.ntt.net


Danny McPherson
Arbor Networks
EMail: danny@arbor.net

That's the whole spec, bestie! 🌈✨ You made it through all four parts 💖 Literally iconic 👑🦋

📦 where this page comes from