Inter-Domain Routing J. Haas
Internet-Draft Juniper Networks
Intended status: Standards Track S. Hares
Expires: 29 October 2021 Hickory Hill Consulting
S. Maduschke
Verizon
27 April 2021
BGP Flowspec Explicit Term Ordering
draft-haas-idr-flowspec-term-order-00
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Haas, et al. Expires 29 October 2021 [Page 1]
Internet-Draft flowspec-term-order April 2021
This Internet-Draft will expire on 29 October 2021.
Copyright Notice
Copyright (c) 2021 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Term Order Component Type . . . . . . . . . . . . . . . . . . 3
2.1. Type 0 - Term Order . . . . . . . . . . . . . . . . . . . 3
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Incremental Deployment . . . . . . . . . . . . . . . . . 4
4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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]).
Haas, et al. Expires 29 October 2021 [Page 2]
Internet-Draft flowspec-term-order April 2021
[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
2.1. Type 0 - Term Order
Encoding: <type (1 octet), length (1 octet), term order (variable)>
Defines the relative term order for this BGP Flowspec NLRI.
The value of the length MUST be 1, 2, or 4. The length SHOULD be
chosen to be the smallest possible value to properly encode the term
order value.
2.2. Discussion
The choice of Component Type 0, currently RESERVED by [RFC8955], is
intended to be minimally disruptive to the sorting function and
deployed code for BGP Flowspec. Consider the following text from
Section 5.1 of that RFC:
Haas, et al. Expires 29 October 2021 [Page 3]
Internet-Draft flowspec-term-order April 2021
"The relative order of two Flow Specifications is determined by
comparing their respective components. The algorithm starts by
comparing the left-most components (lowest component type value)
of the Flow Specifications. If the types differ, the Flow
Specification with lowest numeric type value has higher precedence
(and thus will match before) than the Flow Specification that
doesn't contain that component type. If the component types are
the same, then a type-specific comparison is performed (see
below). If the types are equal, the algorithm continues with the
next component."
By using Component Type 0, the ability to bias sort order is provided
without a change to the remaining sorting semantics used by [RFC8955]
and other proposals.
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.
3.1. Incremental Deployment
[I-D.haas-flowspec-capability-bits] is required to deploy this
feature for Flowspec v1. When a BGP Speaker wishes to use,
originate, or propagate BGP Flowspec NLRI with the term order
component, that BGP Speaker MUST advertise the BGP Flowspec
Capability Bits with bit 0 set to a value of 1.
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.
Haas, et al. Expires 29 October 2021 [Page 4]
Internet-Draft flowspec-term-order April 2021
5. Acknowledgements
TBD.
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
(https://www.iana.org/assignments/flow-spec/flow-spec.xhtml). The
IPv4 Name and IPv6 name for Type 0 will be "Term Order". The
Reference will be this document.
8. References
8.1. Normative References
[I-D.haas-flowspec-capability-bits]
Haas, J., "BGP Flowspec Capability Bits", Work in
Progress, Internet-Draft, draft-haas-flowspec-capability-
bits-02, 9 April 2021, <https://www.ietf.org/internet-
drafts/draft-haas-flowspec-capability-bits-02.txt>.
[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>.
Haas, et al. Expires 29 October 2021 [Page 5]
Internet-Draft flowspec-term-order April 2021
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[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>.
8.2. Informative References
[I-D.hares-idr-flowspec-v2]
Hares, S., "BGP Flow Specification Version 2", Work in
Progress, Internet-Draft, draft-hares-idr-flowspec-v2-00,
25 June 2016, <http://www.ietf.org/internet-drafts/draft-
hares-idr-flowspec-v2-00.txt>.
Appendix A. Open Issues
* After sufficient discussion has been given to this proposal,
update the python pseudocode example to include interaction with
this feature.
Authors' Addresses
Jeffrey Haas
Juniper Networks
Email: jhaas@juniper.net
Susan Hares
Hickory Hill Consulting
Email: shares@ndzh.com
Haas, et al. Expires 29 October 2021 [Page 6]
Internet-Draft flowspec-term-order April 2021
Sven Maduschke
Verizon
Email: sven.maduschke@de.verizon.com
Haas, et al. Expires 29 October 2021 [Page 7]