| Internet-Draft | ISIS FlowSpec | April 2023 |
| Liang, et al. | Expires 26 October 2023 | [Page] |
Dissemination of the Traffic flow information was first introduced in the BGP protocol [RFC5575]. FlowSpec rules are used to distribute traffic filtering rules that are used to filter Denial-of-Service (DoS) attacks. For the networks that only deploy IS-IS or IS-IS variant, it is required that IS-IS is extended to distribute Flow Specification or FlowSpec rules.¶
This document discusses the use cases for distributing flow specification (FlowSpec) routes using IS-IS. Furthermore, this document defines a new IS-IS FlowSpec Reachability TLV encoding format that can be used to distribute FlowSpec rules, its validation procedures for imposing the filtering information on the routers, and a capability to indicate the support of FlowSpec functionality.¶
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 [RFC2119].¶
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."¶
This Internet-Draft will expire on 26 October 2023.¶
Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC5575] defines Border Gateway Protocol protocol extensions that can be used to distribute traffic flow specifications. One application of this encoding format is to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks.¶
For the networks deploying only IS-IS or IS-IS variant, it is expected to extend IS-IS to distribute FlowSpec rules. This document discusses use cases for distributing FlowSpec rules using IS-IS. Furthermore, this document also defines a new IS-IS FlowSpec Reachability TLV encoding format that can be used to distribute FlowSpec entries to specific routers in the campus network, its validation procedures for imposing the filtering information on the routers, and a capability to indicate the support of FlowSpec functionality.¶
The semantic content of the FlowSpec extensions defined in this document are identical to the corresponding extensions to BGP ([RFC5575] and [I-D.ietf-idr-flow-spec-v6]). In order to avoid repetition, this document only concentrates on those parts of specification where IS-IS is different from BGP. The IS-IS FlowSpec extensions defined in this document can be used to mitigate the impacts of DoS attacks.¶
This section contains definitions for terms used frequently throughout this document. However, many additional definitions can be found in [ISO-10589] and [RFC5575].¶
For the networks using IS-IS or IS-IS variant, for example, the campus network or DC network, it is expected to extend IS-IS to distribute FlowSpec rules as shown in Figure 1. In this network, the traffic analyzer could be deployed to inject the FlowSpec rules into Router A. Router A creates FlowSpec entries according to the FlowSpec rules, then the FlowSpec entries would be distributed to the other routers in this domain using IS-IS. Consequently, the attack traffic could be blocked or the suspicious traffic could be limited to a low rate as early as possible.¶
+--------+
|Traffic |
+---+Analyzer|
| +--------+
|
|FlowSpec
|
|
+--+-------+ +----------+ +--------+
| Router A +-----------+ Router B +--------+Attacker|
+----------+ +----------+ +--------+
| | |
| IS-IS FlowSpec | Attack Traffic |
| | |
This document defines a new IS-IS TLV, i.e. the FlowSpec reachability TLV (TLV type: TBD1), to describe the FlowSpec rules. An LSP (Link State Protocol) Data Unit [ISO-10589] can carry one or more FlowSpec reachability TLVs.¶
Each FlowSpec Reachability TLV carries a FlowSpec entry. The FlowSpec entry consists of a FlowSpec Filters sub-TLV and one or more corresponding FlowSpec Action sub-TLVs.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSpec Entry (variable) |
+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |L|
+-+-+-+-+-+-+-+-+
¶
IS-IS FlowSpec filters sub-TLV is one component of FlowSpec entry, carried in the FlowSpec reachability TLV. It is defined below in Figure 3.¶
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | |
+-+-+-+-+-+-+-+-+ +
~ Filters (variable) ~
+ +
| ... |
Type: the TLV type (Type Code: TBD2 for IPv4 FlowSpec filters, TBD3 for IPv6 FlowSpec filters)¶
Length: the size of the value field in octets, it cannot be greater than 253.¶
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |S|
+-+-+-+-+-+-+-+-+
¶
The least significant bit S is defined as a strict filter check bit. If set, strict validation rules outlined in the validation section Section 4.1.2 need to be enforced.¶
Filters: the same as "flow-spec filter components" defined in [RFC5575] and [I-D.ietf-idr-flow-spec-v6].¶
| Type | Description | RFC/ WG draft |
|---|---|---|
| 1 | Destination IPv4 Prefix Destination IPv6 Prefix | RFC5575 I-D.ietf-idr-flow-spec-v6 |
| 2 | Source IPv4 Prefix Source IPv6 Prefix | RFC5575 I-D.ietf-idr-flow-spec-v6 |
| 3 | IP Protocol Next Header | RFC5575 I-D.ietf-idr-flow-spec-v6 |
| 4 | Port | RFC5575 |
| 5 | Destination port | RFC5575 |
| 6 | Source port | RFC5575 |
| 7 | ICMP type | RFC5575 |
| 8 | ICMP code | RFC5575 |
| 9 | TCP flags | RFC5575 |
| 10 | Packet length | RFC5575 |
| 11 | DSCP | RFC5575 |
| 12 | Fragment | RFC5575 |
| 13 | Flow Label | I-D.ietf-idr-flow-spec-v6 |
With traffic filtering rules, more than one rule may match a particular traffic flow. The order of applying the traffic filter rules is the same as described in Section 5.1 of [RFC5575] and in Section 3.1 of [I-D.ietf-idr-flow-spec-v6].¶
[RFC5575] defines a validation procedure for BGP FlowSpec rules, and [I-D.ietf-idr-bgp-flowspec-oid] describes a modification to the validation procedure defined in [RFC5575] for the dissemination of BGP flow specifications. The IS-IS FlowSpec should support similar features to mitigate the unnecessary or invalid application of traffic filter rules. The IS-IS FlowSpec validation procedure is described as follows.¶
When a router receives a FlowSpec rule including a destination prefix filter from its neighbor router, it should consider the prefix filter as a valid filter unless the S bit in the flags field of Filter TLV is set. If the S bit is set, then the FlowSpec rule is considered valid if and only if:¶
The former rule allows any centralized controller to originate the prefix filter and advertise it within a given IS-IS network. The latter rule, also known as a Strict Validation rule, allows strict checking and enforces that the originator of the FlowSpec filter is also the originator of the destination prefix.¶
When multiple equal-cost paths exist in the routing table entry, each path could end up having a separate set of FlowSpec rules.¶
When a router receives a FlowSpec rule not including a destination prefix filter from its neighbor router, the validation procedure described above is not applicable.¶
The FlowSpec filter validation state is used by an IS-IS speaker when the filter is considered for an installation in its FIB. An IS-IS speaker MUST flood IS-IS LSP containing a FlowSpec Reachability TLV as per the entries defined in [ISO-10589] regardless of the validation state of the prefix filters.¶
There are one or more FlowSpec Action TLVs associated with a FlowSpec Filters TLV. Different FlowSpec Filters TLV could have the same FlowSpec Action TLVs. The following IS-IS FlowSpec action TLVs, except Redirect, are same as defined in [RFC5575].¶
Redirect: IPv4 or IPv6 address. This target IP address MUST correspond to a tunnel in the current IS-IS router, if not, the "redirect to IP" action is invalid, and if the flowspec entry has no other action, the flowspec entry is invalid and wouldn't be installed . If the IS-IS router doesn't have a valid route for the target IP, the "redirect to IP" action is also invalid.¶
| type | FlowSpec Action | RFC/WG draft |
|---|---|---|
| 0x8006 | traffic-rate | RFC5575 |
| 0x8007 | traffic-action | RFC5575 |
| 0x8108 | redirect-to-IPv4 | [I-D.ietf-idr-flowspec-redirect-rt-bis] |
| 0x800b | redirect-to-IPv6 | I-D.ietf-idr-flow-spec-v6 |
| 0x8009 | traffic-marking | RFC5575 |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD4 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic-rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic-rate: the same as defined in [RFC5575].
¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD5 | 2 | Reserved |S|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S flag and T flag: the same as defined in [RFC5575].
¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD6 | 2 | Reserved | DSCP Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DSCP value: the same as defined in [RFC5575].
¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD7 | 6 | Reserved |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect to IPv6 TLV is encoded as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD8 | 18 | Reserved |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4/6 Address: the redirection target IP address.
¶
'C' (or copy) bit: when the 'C' bit is set, the redirection applies to copies of the matching packets and not to the original traffic stream [I-D.ietf-idr-flowspec-redirect-ip].¶
An implementation MAY provide an option for an IS-IS speaker to announce a redistributed FlowSpec route within an IS-IS domain regardless of being installed in its local FIB. An implementation MAY impose an upper bound on number of FlowSpec entries that an IS-IS router MAY advertise.¶
This document defines the following new IS-IS TLV types, which need to be reflected in the IS-IS TLV codepoint registry.¶
| Type | Description | IIH | LSP | SNP |
|---|---|---|---|---|
| TBD1 | The FlowSpec Reachability TLV | n | y | n |
| Type | Description |
|---|---|
| TBD2 | IPv4 FlowSpec filters sub-TLV |
| TBD3 | IPv6 FlowSpec filters sub-TLV |
| Type | Description | RFC/ WG draft |
|---|---|---|
| 1 | Destination IPv4 Prefix Destination IPv6 Prefix | RFC5575 I-D.ietf-idr-flow-spec-v6 |
| 2 | Source IPv4 Prefix Source IPv6 Prefix | RFC5575 I-D.ietf-idr-flow-spec-v6 |
| 3 | IP Protocol Next Header | RFC5575 I-D.ietf-idr-flow-spec-v6 |
| 4 | Port | RFC5575 |
| 5 | Destination port | RFC5575 |
| 6 | Source port | RFC5575 |
| 7 | ICMP type | RFC5575 |
| 8 | ICMP code | RFC5575 |
| 9 | TCP flags | RFC5575 |
| 10 | Packet length | RFC5575 |
| 11 | DSCP | RFC5575 |
| 12 | Fragment | RFC5575 |
| 13 | Flow Label | I-D.ietf-idr-flow-spec-v6 |
This extension to IS-IS does not change the underlying security issues inherent in the existing IS-IS. Implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors which cause hard IS-IS failures.¶
The authors would like to thank Jiangjie You, Peng Fan, Jeff Haas for their contributions.¶