Bitwise IP Filters for BGP FlowSpec Individual Contributor
pyxislx@gmail.com
Hickory Hill Consulting
7453 Hickory Hill Saline MI 48176 USA +1-734-604-0332 shares@ndzh.com
Routing Area IDR Working Group RFC Request for Comments I-D Internet-Draft Bitwise IP Filters, BGP FlowSpec This draft introduces the bitwise matching filters for source or destination IPv4/IPv6 address fields. These filters enhance the functionalities of the BGP Flow Specification framework and aid scenarios involving symmetric traffic load balancing.
Introduction Symmetric paths for both directions are required to allow session inspecting service instances (such as the deep packet inspection(DPI) or the firewall service instances) to process the traffic correctly. If a single instance cannot handle the traffic load, symmetric load balancing between multiple inspecting service instances is needed. Hash-based load balancing may not be suitable for this purpose since the order of fields for the hashing mechanism may not be configurable, and different vendors implement different proprietary hashing functions. In a multi-vendor environment, it is desirable to load-balance traffic between each instance using a standardized approach. The BGP Flow Specification(BGP-FS) Network Layer Reachability Information(NLRI) is a standardized approach to distributing traffic filters via BGP. The BGP Flow Specification version 2(FSv2) defined in enhances BGP-FS, allowing user-defined order of filters. The Extended IP Filters defined in further extend the filter types of FSv2. This draft defines the bitwise matching filters for source or destination IPv4/IPv6 address fields. We can achieve dynamic symmetric traffic load-balancing using these filters if the traffic is distributed almost uniformly among combinations of the least significant bits of the source or destination address fields.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
AFI:
Address Family Identifier
BGP-FS:
BGP Flow Specification
DPI:
Deep Packet Inspection
ECMP:
Equal-Cost Multipath
FSv2:
BGP Flow Specification Version 2
SAFI:
Subsequent Address Family Identifier
Service Instance:
A service instance is an instance of VNF or a physical device that instantiates a service function. It is spawned and terminated dynamically based on the traffic loads.
VNF:
Virtual Network Function
This section defines the bitwise address filter component Sub-TLVs for FSv2. These Sub-TLVs are classified as "IP Extended Filters" as defined in . Sub-TLVs for both source and destination address fields are defined.
Summary:
This section defines bitwise matches for the destination address field.
Component type:
TBD1
Description:
This component performs matching against designated bits in the destination address field.
The field that the filter targets in the IPv4 Packets:
Destination address field
The field that the filter targets in the IPv6 Packets:
Destination address field
Length:
This field indicates the length of the value field in octets. The length is 8 for AFI = 1(IPv4) and 32 for AFI = 2(IPv6). If the length is neither 8 nor 32, the NLRI is considered MALFORMED. If the length is inconsistent with the AFI definition, the NLRI is also considered MALFORMED.
Encoding of Component Value field:
The match is encoded as a 2-tuple of the form <Prefix, Mask> , where:
Prefix:
a 4-octet bit string for AFI = 1 and a 16-octet bit string for AFI = 2. It indicates the destination address value to match against.
Mask:
a 4-octet bit string for AFI = 1 and a 16-octet bit string for AFI = 2. It indicates the bit positions to match. In the matching process, we only consider bit positions designated with value 1 in the Mask field. An address is a match if and only if the value of the address matches the value in the Prefix field in every designated bit position.
Conflicts with other filters:
None
Summary:
This section defines bitwise matches for the source address field.
Component type:
TBD2
Description:
This component performs matching against designated bits in the source address field.
The field that the filter targets in the IPv4 Packets:
Source address field
The field that the filter targets in the IPv6 Packets:
Source address field
Length:
This field indicates the length of the value field in octets. The length is 8 for AFI = 1(IPv4) and 32 for AFI = 2(IPv6). If the length is neither 8 nor 32, the NLRI is considered MALFORMED. If the length is inconsistent with the AFI definition, the NLRI is also considered MALFORMED.
Encoding of Component Value field:
The match is encoded as a 2-tuple of the form <Prefix, Mask> , where:
Prefix:
a 4-octet bit string for AFI = 1 and a 16-octet bit string for AFI = 2. It indicates the source address value to match against.
Mask:
a 4-octet bit string for AFI = 1 and a 16-octet bit string for AFI = 2. It indicates the bit positions to match. In the matching process, we only consider bit positions designated with value 1 in the Mask field. An address is a match if and only if the value of the address matches the value in the Prefix field in every designated bit position.
Conflicts with other filters:
None
This section describes the procedures for sorting the Sub-TLVs defined in this draft of the same type.
Multiple Occurrences of the Sub-TLV of the same type in the same NLRI:
The Sub-TLV of the same type with different values MAY appear multiple times in the same NLRI. The address field matches if it matches any instances of the Sub-TLV that appear in the NLRI. When sending multiple instances of the Sub-TLV of the same type, the following rules apply:
  1. Duplicate values are not allowed. The Sub-TLVs with the same value MUST appear only once.
  2. Comparing the value field in each instance as a binary string using the memcmp() function as defined by determines the precedence of the instance. The lowest one (memcmp) has higher precedence.
  3. The Sub-TLV instance with the highest precedence MUST precede instances with lower precedence.
Filter Ordering Rules of the Sub-TLV of the same type between different NLRIs:
When comparing two NLRIs with the same type of Sub-TLV instances, the following rules apply:
  1. The Sub-TLV instances in the same NLRI received must be in strict value-ascending order, or the NLRI is considered MALFORMED.
  2. Compare the sequence of the Sub-TLV instances from each NLRI as binary strings using the memcmp() function defined by . If there are multiple instances of the Sub-TLV in the same NLRI, treat these instances as a single binary string. For strings of equal length, the lowest string has the highest precedence. For strings of different lengths, compare the common prefix of the string only. If the common prefix is unequal, the string with the lowest common prefix has higher precedence. If the common prefix is equal, the longest string has higher precedence than the shorter one.
This section describes various use cases for these filters.
Referring to , subscriber traffic is going through a set of inline service instances(e.g., DPIs, stateful firewalls) before entering the Internet. Inline service instances SVC0, SVC1, SVC2, and SVC3 need to process both directions of traffic in the same session. Any single service instance cannot handle the traffic volume alone. Assuming the traffic is distributed almost uniformly among combinations of the least significant 2 bits of the subscribers' addresses.
Hash-based load balancing may not be suitable for this case since the order of fields for the hashing mechanism may not be configurable, and different vendors implement different proprietary hashing functions. Deploying bitwise address filters is a viable multi-vendor solution in this case. For example, we can deploy: On X:
  • FSv2 rule X0 matches the least significant 2 bits as 00 in the source address field and directs traffic to SVC0.
  • FSv2 rule X1 matches the least significant 2 bits as 01 in the source address field and directs traffic to SVC1.
  • FSv2 rule X2 matches the least significant 2 bits as 10 in the source address field and directs traffic to SVC2.
  • FSv2 rule X3 matches the least significant 2 bits as 11 in the source address field and directs traffic to SVC3.
On Y:
  • FSv2 rule Y0 matches the least significant 2 bits as 00 in the destination address field and directs traffic to SVC0.
  • FSv2 rule Y1 matches the least significant 2 bits as 01 in the destination address field and directs traffic to SVC1.
  • FSv2 rule Y2 matches the least significant 2 bits as 10 in the destination address field and directs traffic to SVC2.
  • FSv2 rule Y3 matches the least significant 2 bits as 11 in the destination address field and directs traffic to SVC3.
The matched traffic is directed to a specific service instance by various mechanisms, such as(but not limited to) the following:
  • RT-redirect action defined in
  • Redirect-to-IP action as described in
  • Indirection-id redirection as described in
  • Redirect into an SR Policy as described in
We can load balance the traffic to N service instances while keeping the same session on the same instance using the rules matching the least significant log(N) bits of the address fields.
Consider the same example depicted in . If the traffic load drops and we want to scale down the service by shutting down SVC2 and SVC3 to reduce costs, we can deploy new rules: On X:
  • FSv2 rule X0 matches the least significant bit as 0 in the source address field and directs traffic to SVC0.
  • FSv2 rule X1 matches the least significant bit as 1 in the source address field and directs traffic to SVC1.
On Y:
  • FSv2 rule Y0 matches the least significant bit as 0 in the destination address field and directs traffic to SVC0.
  • FSv2 rule Y1 matches the least significant bit as 1 in the destination address field and directs traffic to SVC1.
We can remove the old rules and then shut down SVC2 and SVC3 after the new rules are activated.
Some capacity-limited devices, such as DPI equipment, may benefit from symmetric traffic sampling. Since these devices also require traffic from both directions, we can deploy bitwise filters to sample traffic flows by matching against a set of specific least significant bits from different subnets.
This section compares the proposed solution with other existing approaches.
IPv4 Source/Destination Prefix filters defined in and cannot match the least significant bits. IPv6 Source/Destination Prefix filters defined in  and  can either match the least significant bits or the IPv6 Prefix, but not both. These filters may not be suitable for use cases described in Section 3.1 without real-time traffic monitoring mechanisms for every possible source/destination prefix. The manageability and flexibility are not as good as the proposed solution either. If both the prefix and bitwise matching are needed, using the bitwise matching filter is recommended since it provides both functionalities in the same filter. If only prefix matching is required, using filters defined in , , or  is more efficient and recommended.
The content filter defined in also provides the bitwise matching capability. Although the filter supports bitwise matching against any position in the packet, address matching is not its primary design goal. Manual calculation of offsets is required to use this filter. Therefore, it may not be optimal for scenarios that match address fields only.
With the following conditions met, traditional hash-based ECMP may be used for the scenario described in .
  • Routers X and Y implement the same hashing algorithm for ECMP, which usually means both routers are of the same vendor.
  • The order of the fields for hashing must be reversible so that the hashing outcome will be on the same ECMP member for both directions.
  • A mechanism to signal the order of ECMP members is needed. The BGP MultiNexthop(MNH) attribute defined in can distribute such information.
Even with all conditions met, we cannot determine which member a specific packet passes through before putting it into the router unless the router provides an interface to query that. Therefore, the bitwise matching filter-based solution is more suitable for this scenario.
The filter defined in this document matches against arbitrary bits in the address fields. While syntactically this filter does not conflict with existing / prefix filters, using either the bitwise filter or the existing filter as described in is recommended. When deployed with redirection actions, these FS rules are actually PBR rules. Since these rules bypass the typical routing lookups just as typical PBR rules do, it is possible to form forwarding loops. User discretion is required. If deployed with redirection actions and there are ECMPs to the redirection destination, the matching packets are subject to hash-based load-balancing towards that destination. While some platforms are capable of processing bitwise filters at line-rate speeds, some aren't. Therefore, before deployments, it is recommended to determine the performance of bitwise matching.
IANA is requested to indicate [this draft] as a reference on the following assignments in the Flow Specification Component Types Registry:
Type Value IPv4 Name IPv6 Name Reference
TBD1 Bitwise Destination IPv4 Address Filter Bitwise Destination IPv6 Address Filter [this draft]
TBD2 Bitwise Source IPv4 Address Filter Bitwise Source IPv6 Address Filter [this draft]
No new security issues are introduced to the BGP protocol by this specification.
Information technology -- Programming languages -- C ISO
The authors would like to thank Robert Raszuk for comments and suggestions.