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
Zhongguancun Laboratory
Beijing 100094 China +86-185-1028-7458 gaoyj@zgclab.edu.cn
Routing Area IDR Working Group RFC Request for Comments I-D Internet-Draft Bitwise IP Filters, BGP FlowSpec This document introduces the bitwise match filter component for source and destination IPv4/IPv6 address fields. These components enhance the BGP Flow Specification framework and provide a solution for dynamic symmetric traffic load-balancing.
Introduction Symmetric paths for traffic in both directions are required to allow session inspection service instances (such as deep packet inspection(DPI) or firewall service instances) to process traffic correctly. If a single instance cannot handle the traffic load, symmetric load-balancing across multiple inspecting service instances is required. Hash-based load-balancing may not be suitable for this purpose. Since the order of the packet header fields for the hashing mechanism is not always configurable, and different vendors implement various proprietary hashing functions. In a multi-vendor environment, it is desirable to load-balance traffic 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) is an enhancement to BGP-FS. It allows a user-defined order of filters. This document defines the bitwise match filter component Sub-TLVs for source and destination IPv4/IPv6 address fields. Using these Sub-TLVs allows operators to match arbitrary bit positions against the corresponding address fields. We can symmetrically load-balance traffic using this property if the traffic is distributed almost uniformly across 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 traffic usage.
VNF:
Virtual Network Function
This section defines the bitwise address filter component Sub-TLVs for FSv2. 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 matches against designated bits in the destination address field. It contains a list of <Pattern, Mask> pairs. If the destination address matches any pair in the list, this component is considered a match. A destination address D is a match for a pair <Pattern, Mask> if and only if: (D & Mask) = (Pattern & Mask) where & is the bitwise AND operator.
The field that the component targets in the IPv4 Packets:
Destination address field
The field that the component targets in the IPv6 Packets:
Destination address field
Length:
This field indicates the length of the value field in octets. The length is a nonzero multiple of 8 for AFI = 1 (IPv4) or a nonzero multiple of 32 for AFI = 2 (IPv6).
Encoding of Component Value field:
The value field is encoded as a sorted list with no repetition of pairs: [ <Pattern, Mask>, <Pattern, Mask>, ..., <Pattern, Mask> ]
Pattern:
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. Only bit positions set to 1 in the Mask field are considered for matching; other bit positions are ignored. Ignored bit positions MUST be set to zero on transmission and MUST be treated as zero on receipt.
Mask:
a 4-octet bit mask for AFI = 1 and a 16-octet bit mask for AFI = 2. It indicates the bit positions to match with the Pattern field. Only bit positions set to 1 in the Mask field are considered for matching. These bit positions can be discontiguous.
Construction of the list:
The following procedures guarantee the same result for the same list of <Pattern, Mask> pairs. Note that two pairs are identical if they are encoded exactly the same using the encoding described above.
  • Each <Pattern, Mask> pair is treated as a binary string.
  • Each pair MUST be present no more than once in a single component Sub-TLV.
  • Each pair is compared using the memcmp() function as defined in .
  • Each pair MUST follow strict ascending order by the memcmp() results. That is, the lower pair MUST precede the higher pairs.
Conflicts with other filters:
None. However, it is recommended to use either the bitwise filter or the "Destination Prefix filter" defined in , not both. See also in .
Summary:
This section defines bitwise matches for the source address field.
Component Type:
TBD2
Description:
This component matches against designated bits in the source address field. It contains a list of <Pattern, Mask> pairs. If the source address matches any pair in the list, this component is considered a match. A source address S is a match for a pair <Pattern, Mask> if and only if: (S & Mask) = (Pattern & Mask) where & is the bitwise AND operator.
The field that the component targets in the IPv4 Packets:
Source address field
The field that the component targets in the IPv6 Packets:
Source address field
Length:
This field indicates the length of the value field in octets. The length is a nonzero multiple of 8 for AFI = 1 (IPv4) or a nonzero multiple of 32 for AFI = 2 (IPv6).
Encoding of Component Value field:
The value field is encoded as a sorted list with no repetition of pairs: [ <Pattern, Mask>, <Pattern, Mask>, ..., <Pattern, Mask> ]
Pattern:
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. Only bit positions set to 1 in the Mask field are considered for matching; other bit positions are ignored. Ignored bit positions MUST be set to zero on transmission and MUST be treated as zero on receipt.
Mask:
a 4-octet bit mask for AFI = 1 and a 16-octet bit mask for AFI = 2. It indicates the bit positions to match with the Pattern field. Only bit positions set to 1 in the Mask field are considered for matching. These bit positions can be discontiguous.
Construction of the list:
The following procedures guarantee the same result for the same list of <Pattern, Mask> pairs. Note that two pairs are identical if they are encoded exactly the same using the encoding described above.
  • Each <Pattern, Mask> pair is treated as a binary string.
  • Each pair MUST be present no more than once in a single component Sub-TLV.
  • Each pair is compared using the memcmp() function as defined in .
  • Each pair MUST follow strict ascending order by the memcmp() results. That is, the lower pair MUST precede the higher pairs.
Conflicts with other filters:
None. However, it is recommended to use either the bitwise filter or the "Source Prefix filter" defined in , not both. See also in .
This section describes the procedures for comparing two Sub-TLVs of the same type in two different FSv2 NLRIs. Note that inside every individual Sub-TLV, each <Pattern, Mask> pair has already been sorted by the procedures defined in and . When comparing two NLRIs with the same type of bitwise matching filter component Sub-TLV, the following procedures apply:
  1. Every bitwise filter component Sub-TLV, regardless of its length, is treated as a binary string.
  2. Compare the bitwise filter component Sub-TLVs of the same type from each NLRI as binary strings using the memcmp() function defined by .
  3. For strings of equal length, the lowest string has the highest precedence.
  4. 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.
When receiving a Bitwise Filter Component Sub-TLV, the following error handling procedures apply:
  • If the length is not a nonzero multiple of 8 for AFI = 1, the component Sub-TLV is considered MALFORMED. Similarly, if the length is not a nonzero multiple of 32 for AFI = 2, the component Sub-TLV is also considered MALFORMED.
  • If there is more than one identical <Pattern, Mask> pair, the component Sub-TLV is considered MALFORMED.
  • If the <Pattern, Mask> pairs are not in a strict ascending order as described in and , the component Sub-TLV is considered MALFORMED.
The error handling procedures for NLRIs with MALFORMED Sub-TLVs are defined in .
This section describes the interactions with the existing IPv4/IPv6 Source/Destination Prefix filter components defined in . When a filter component defined in this document resides in an NLRI containing other existing prefix filter components, typical logical AND semantics between components should be honored. For example, if there are a source address bitwise filter component and a source prefix filter component in the same NLRI, a source address is considered a match if it matches both components. However, it is recommended to use only one filter component for a packet header field. See also in .
This section describes various use cases for these filter components.
Referring to , subscriber traffic passes 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 the same session in both directions. 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.
The order of fields for hashing functions is not always configurable, and different vendors implement various proprietary hashing functions. Therefore, hash-based load-balancing may not be suitable. Deploying bitwise address filters is a viable multi-vendor solution in this case. For example, we can deploy: On X:
  • FSv2 rule X0 matches pattern 00 against the least significant 2 bits in the source address field and directs traffic to SVC0.
  • FSv2 rule X1 matches pattern 01 against the least significant 2 bits in the source address field and directs traffic to SVC1.
  • FSv2 rule X2 matches pattern 10 against the least significant 2 bits in the source address field and directs traffic to SVC2.
  • FSv2 rule X3 matches pattern 11 against the least significant 2 bits in the source address field and directs traffic to SVC3.
On Y:
  • FSv2 rule Y0 matches pattern 00 against the least significant 2 bits in the destination address field and directs traffic to SVC0.
  • FSv2 rule Y1 matches pattern 01 against the least significant 2 bits in the destination address field and directs traffic to SVC1.
  • FSv2 rule Y2 matches pattern 10 against the least significant 2 bits in the destination address field and directs traffic to SVC2.
  • FSv2 rule Y3 matches pattern 11 against the least significant 2 bits in the destination address field and directs traffic to SVC3.
If, instead, we want to load-balance a subset of subscribers from subnet P1/M1 only, the bitwise components also support that. For example, FSv2 rule X0 can be modified to match both the most significant M1 bits as P1 and the least significant 2 bits as 00 in a single <Pattern, Mask> pair since the matching positions indicated by the Mask can be discontiguous as mentioned in . FSv2 rule Y0 can be modified to match both the most significant M1 bits as P1 and the least significant 2 bits as 00 in a single <Pattern, Mask> pair since the matching positions indicated by the Mask can be discontiguous as mentioned in . 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
  • Redirect into an SR Policy as described in
  • Indirection-id redirection as described in
Using this approach, the bitwise filter components load-balance traffic into N service instances while keeping the same session on the same instance.
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 pattern 0 against the least significant bit in the source address field and directs traffic to SVC0.
  • FSv2 rule X1 matches pattern 1 against the least significant bit in the source address field and directs traffic to SVC1.
On Y:
  • FSv2 rule Y0 matches pattern 0 against the least significant bit in the destination address field and directs traffic to SVC0.
  • FSv2 rule Y1 matches pattern 1 against the least significant bit 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 traffic sampling. Since these devices may require traffic from both directions, we can deploy bitwise filters to sample traffic flows by matching against specific least significant bits from different subnets.
This section compares the proposed solution with other existing approaches.
IPv4 Source/Destination Prefix filter components defined in and cannot match the least significant bits. IPv6 Source/Destination Prefix filter components defined in and  can either match the least significant bits or the IPv6 Prefix, but not both. These components may not be suitable for the use cases described in without intensive real-time traffic monitoring mechanisms for every possible source/destination prefix. The manageability and flexibility are not as good as the proposed solution, either. Since the bitwise filter component provides both prefix and bitwise matching capabilities(as briefly described in Section 3.1), it is the recommended component for matching both. If only prefix matching is required, using filters defined in , , or is more efficient and recommended.
The content filter component defined in also provides the bitwise matching capability. Although the component supports bitwise matching against any position in the packet, address matching is not its primary design goal. Manual offset calculation is required to use this filter component. Therefore, the bitwise matching-based solution is more optimal for this scenario.
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 they are from the same vendor.
  • The order of the fields for hashing must be reversible. Therefore, the hashing outcome for the same session 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, as defined in , can distribute such information.
Even with all conditions met, before the packet enters the router, we cannot determine which ECMP member it passes through unless the router provides an interface to query that beforehand. Therefore, the bitwise matching filter-based solution is more suitable for this scenario.
The filter component defined in this document matches against arbitrary bit positions in the address fields. Syntactically, this component does not conflict with the existing / prefix filter component; however, using either the bitwise filter or the existing filter as described in is recommended. The general guideline is:
  • If only single prefix-matching is needed, use the existing filter components. It is more encoding-wise efficient.
  • Use the bitwise filter components otherwise. Since it provides a union of the listed <Pattern, Mask> pairs.
When deployed with redirection actions, these rules actually become PBR rules. Since these rules bypass the typical routing lookups, just like typical PBR rules, it is possible to form forwarding loops. User discretion is required. If deployed with redirection actions and there are ECMPs to the redirection destination, matched packets are subject to hash-based load-balancing towards that destination. While some platforms process bitwise filter components at line-rate speeds, some don't. Therefore, it is recommended to determine the performance of the bitwise match filter components beforehand.
IANA is requested to indicate [this document] as a reference on the following assignments in the "BGP FSv2 IP Basic Component Types" registry:
Type Value IPv4 Name IPv6 Name Reference
TBD1 Bitwise Destination IPv4 Address Filter Bitwise Destination IPv6 Address Filter [this document]
TBD2 Bitwise Source IPv4 Address Filter Bitwise Source IPv6 Address Filter [this document]
The security considerations discussed in , , and also apply to this document. If deployed with redirection actions, the security considerations discussed in should also be evaluated.
Information technology -- Programming languages -- C ISO
The authors would like to thank Robert Raszuk for comments and suggestions.