BGP Flowspec Explicit Term Ordering

Abstract

BGP Flowspec (RFC 8955) provides a mechanism for matching traffic flows. The ordering of the Flow Specifications defined by that RFC is provided by a sorting function that uses the contents of the received BGP NLRI; that NLRI does not contain an explicit ordering component. The RFC's sorting function permits for origination of Flowspec NLRI from multiple BGP Speakers and is generally appropriate for mitigating distributed denial-of-service (DDoS) attacks.¶

There are circumstances where the implicit RFC 8955 sorting order is not appropriate. This document defines a mechanism that permits individual Flowspec NLRI to influence their sort order.¶

1. Introduction

BGP Flowspec [RFC8955] creates a mechanism for matching traffic flows and taking action upon them. The BGP Flowspec NLRI format defines multiple components that may be used to match such traffic. Traffic may be matched by more than one BGP Flowpec NLRI, either before or after the application of Traffic Filtering Actions (Section 7, [RFC8955]).¶

[RFC8955] does not provide for a mechanism where the originator of a BGP Flowspec NLRI can influence its processing order. Section 5.1 of [RFC8955] provides for a sorting function on a BGP Speaker defining the processing order of received BGP Flowspec NLRI. That sorting mechanism permits multiple BGP Speakers in a Flowspec domain to originate Flowspec NLRI without coordinating the processing order at a given BGP Speaker.¶

That sorting order is generally appropriate for mitigating distributed denial-of-service attacks (DDoS). Flow specification rules first match on related destinations, followed by sources, and then later a well-defined set of components. Longer sets of components are considered a better match, and thus "more specific" in many cases.¶

While this sort order has generally worked well for DDoS mitigation, sometimes the implicit ordering is problematic. Some of these problems are implementation specific: Long rule sets might be better sorted into higher impact filters near the top of the list. Mixtures of rules that are otherwise independent are sorted in such a way that firewall optimizations are not efficiently run.¶

Some initial discussion has begun for a version 2 of Flowspec in [I-D.hares-idr-flowspec-v2]. Part of that proposal is a mechanism to provide for explicit rule ordering as part of the Flowspec v2 NLRI.¶

This document proposes an alternative mechanism to provide for such explicit rule ordering with a minor extension to Flowspec v1.¶

2. Term Order Component Type

3. Operation

The term order value, when present in a BGP Flowspec NLRI, is intended to provide a logical order to that NLRI vs. other NLRI with that component. A lower term order value has a higher precedence than a higher term order value.¶

A BGP Flowspec NLRI with no term order component is considered to be lower precedence versus a BGP Flowspec NLRI with a term order component. This is consistent with existing BGP Flowspec sorting rules.¶

The same term order value MAY occur more than once in a set of BGP Flowspec NLRI.¶

The term order value is not intended to supplant the ordering mechanism for a firewall implementation. Its only purpose is to provide for biasing the sorting of received BGP Flowspec NLRI.¶

4. Error Handling

A BGP Flowpsec Term Order Component with a length that is not 1, 2, or 4 is considered syntactically incorrect per Section 5.3 of [RFC7606]. Upon receiving such syntactically incorrect NLRI, the BGP session SHALL be reset by sending a NOTIFICATION message.¶

6. Security Considerations

All of the Security Considerations for [RFC8955] and [RFC8956] still apply.¶

This feature provides for the ability to bias the installed filter order of BGP Flow Specification NLRI. The default sort order provided by [RFC8955] serves to cluster rules targeting traffic for a given destination and/or source. By providing an ability to alternatively order such rules, more general rules impacting more traffic may have precedence.¶

Operators must take sufficient care to ensure that such more general rules are considered systematically in the deployment. This may include the ability to prohibit rules with a term order outside of a specific value range from being accepted.¶

Operators may wish to prohibit other ASes from originating or propagating BGP Flowspec NLRI with the term order component, even while exercising the Validation Procedures of Section 6 of [RFC8955].¶

7. IANA Considerations

Upon approval of this document as an RFC, IANA is requested to assign Type Value 0 from the IANA Flow Spec Component Types registry. The IPv4 Name and IPv6 name for Type 0 will be "Term Order". The Reference will be this document.¶

8. References

Appendix A. Open Issues

• After sufficient discussion has been given to this proposal, update the python pseudocode example to include interaction with this feature.¶