draft-ietf-idr-rfc5575bis-20.txt   draft-ietf-idr-rfc5575bis-21.txt 
IDR Working Group C. Loibl IDR Working Group C. Loibl
Internet-Draft Next Layer Communications Internet-Draft next layer Telekom GmbH
Obsoletes: 5575,7674 (if approved) S. Hares Obsoletes: 5575,7674 (if approved) S. Hares
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: September 11, 2020 R. Raszuk Expires: October 18, 2020 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
March 10, 2020 April 16, 2020
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-20 draft-ietf-idr-rfc5575bis-21
Abstract Abstract
This document defines a Border Gateway Protocol Network Layer This document defines a Border Gateway Protocol Network Layer
Reachability Information (BGP NLRI) encoding format that can be used Reachability Information (BGP NLRI) encoding format that can be used
to distribute traffic Flow Specifications. This allows the routing to distribute traffic Flow Specifications. This allows the routing
system to propagate information regarding more specific components of system to propagate information regarding more specific components of
the traffic aggregate defined by an IP destination prefix. the traffic aggregate defined by an IP destination prefix.
It also specifies BGP Extended Community encoding formats, that can It also specifies BGP Extended Community encoding formats, that can
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2020. This Internet-Draft will expire on October 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5 2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5
3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 5 3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 5
4. Dissemination of IPv4 Flow Specification Information . . . . 6 4. Dissemination of IPv4 Flow Specification Information . . . . 6
4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 6 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7
4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7
4.2.1. Operators . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Operators . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 9
4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 13 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 14
5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 16 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Ordering of Flow Specifications . . . . . . . . . . . . . 17 5.1. Ordering of Flow Specifications . . . . . . . . . . . . . 17
6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 18 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 18
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 19 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 19
7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 20 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 20
7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type
TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 21 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 21
7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 22 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 22
7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 22 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 22
skipping to change at page 3, line 31 skipping to change at page 3, line 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . 33
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Python code: flow_rule_cmp . . . . . . . . . . . . . 34 Appendix A. Python code: flow_rule_cmp . . . . . . . . . . . . . 34
Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 35 Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document obsoletes both This document obsoletes "Dissemination of Flow Specification Rules"
"Dissemination of Flow Specification Rules" [RFC5575] and [RFC5575], the differences can be found in Appendix B. This document
"Clarification of the Flowspec Redirect Extended Community"[RFC7674]. also obsoletes
"Clarification of the Flowspec Redirect Extended Community" [RFC7674]
since it incorporates the encoding of the BGP Flow Specification
Redirect Extended Community in Section 7.4.
Modern IP routers contain both the capability to forward traffic Modern IP routers contain both the capability to forward traffic
according to IP prefixes as well as to classify, shape, rate limit, according to IP prefixes as well as to classify, shape, rate limit,
filter, or redirect packets based on administratively defined filter, or redirect packets based on administratively defined
policies. These traffic policy mechanisms allow the operator to policies. These traffic policy mechanisms allow the operator to
define match rules that operate on multiple fields of the packet define match rules that operate on multiple fields of the packet
header. Actions such as the ones described above can be associated header. Actions such as the ones described above can be associated
with each rule. with each rule.
The n-tuple consisting of the matching criteria defines an aggregate The n-tuple consisting of the matching criteria defines an aggregate
skipping to change at page 4, line 19 skipping to change at page 4, line 24
routing system can take advantage of the ACL (Access Control List) or routing system can take advantage of the ACL (Access Control List) or
firewall capabilities in the router's forwarding path. Flow firewall capabilities in the router's forwarding path. Flow
Specifications can be seen as more specific routing entries to a Specifications can be seen as more specific routing entries to a
unicast prefix and are expected to depend upon the existing unicast unicast prefix and are expected to depend upon the existing unicast
data information. data information.
A Flow Specification received from an external autonomous system will A Flow Specification received from an external autonomous system will
need to be validated against unicast routing before being accepted need to be validated against unicast routing before being accepted
(Section 6). The Flow Specification received from an internal BGP (Section 6). The Flow Specification received from an internal BGP
peer within the same autonomous system [RFC4271] is assumed to have peer within the same autonomous system [RFC4271] is assumed to have
been validated prior to transmission within the iBGP mesh of an been validated prior to transmission within the internal BGP (iBGP)
autonomous system. If the aggregate traffic flow defined by the mesh of an autonomous system. If the aggregate traffic flow defined
unicast destination prefix is forwarded to a given BGP peer, then the by the unicast destination prefix is forwarded to a given BGP peer,
local system can install more specific Flow Specifications that may then the local system can install more specific Flow Specifications
result in different forwarding behavior, as requested by this system. that may result in different forwarding behavior, as requested by
this system.
From an operational perspective, the utilization of BGP as the From an operational perspective, the utilization of BGP as the
carrier for this information allows a network service provider to carrier for this information allows a network service provider to
reuse both internal route distribution infrastructure (e.g., route reuse both internal route distribution infrastructure (e.g., route
reflector or confederation design) and existing external reflector or confederation design) and existing external
relationships (e.g., inter-domain BGP sessions to a customer relationships (e.g., inter-domain BGP sessions to a customer
network). network).
While it is certainly possible to address this problem using other While it is certainly possible to address this problem using other
mechanisms, this solution has been utilized in deployments because of mechanisms, this solution has been utilized in deployments because of
the substantial advantage of being an incremental addition to already the substantial advantage of being an incremental addition to already
deployed mechanisms. deployed mechanisms.
In current deployments, the information distributed by this extension In current deployments, the information distributed by this extension
is originated both manually as well as automatically. The latter by is originated both manually as well as automatically, the latter by
systems that are able to detect malicious traffic flows. When systems that are able to detect malicious traffic flows. When
automated systems are used, care should be taken to ensure their automated systems are used, care should be taken to ensure their
correctness as well as the limitations of the systems that receive correctness as well as the limitations of the systems that receive
and process the advertised Flow Specifications (see also Section 12). and process the advertised Flow Specifications (see also Section 12).
This specification defines required protocol extensions to address This specification defines required protocol extensions to address
most common applications of IPv4 unicast and VPNv4 unicast filtering. most common applications of IPv4 unicast and VPNv4 unicast filtering.
The same mechanism can be reused and new match criteria added to The same mechanism can be reused and new match criteria added to
address similar filtering needs for other BGP address families such address similar filtering needs for other BGP address families such
as IPv6 families [I-D.ietf-idr-flow-spec-v6]. as IPv6 families [I-D.ietf-idr-flow-spec-v6].
skipping to change at page 8, line 14 skipping to change at page 8, line 18
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq | | e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 2: Numeric Operator (numeric_op) Figure 2: Numeric Operator (numeric_op)
e - end-of-list bit: Set in the last {op, value} pair in the list. e - end-of-list bit: Set in the last {op, value} pair in the list.
a - AND bit: If unset, the previous term is logically ORed with the a - AND bit: If unset, the result of the previous {op, value} pair
current one. If set, the operation is a logical AND. In the is logically ORed with the current one. If set, the operation is
first operator octet of a sequence it SHOULD be encoded as unset a logical AND. In the first operator octet of a sequence it
and and MUST be treated as always unset on decoding. The AND SHOULD be encoded as unset and MUST be treated as always unset on
operator has higher priority than OR for the purposes of decoding. The AND operator has higher priority than OR for the
evaluating logical expressions. purposes of evaluating logical expressions.
len - length: The length of the value field for this operator given len - length: The length of the value field for this operator given
as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), 8 as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), 8
(len=11) octets. (len=11) octets.
0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during
decoding decoding
lt - less than comparison between data and value. lt - less than comparison between data and value.
skipping to change at page 16, line 46 skipping to change at page 16, line 46
or coordination among the AS within a service provider. or coordination among the AS within a service provider.
The Flow Specification NLRI defined in Section 4 conveys information The Flow Specification NLRI defined in Section 4 conveys information
about traffic filtering rules for traffic that should be discarded or about traffic filtering rules for traffic that should be discarded or
handled in a manner specified by a set of pre-defined actions (which handled in a manner specified by a set of pre-defined actions (which
are defined in BGP Extended Communities). This mechanism is are defined in BGP Extended Communities). This mechanism is
primarily designed to allow an upstream autonomous system to perform primarily designed to allow an upstream autonomous system to perform
inbound filtering in their ingress routers of traffic that a given inbound filtering in their ingress routers of traffic that a given
downstream AS wishes to drop. downstream AS wishes to drop.
In order to achieve this goal, this draft specifies two application In order to achieve this goal, this document specifies two
specific NLRI identifiers that provide traffic filters, and a set of application specific NLRI identifiers that provide traffic filters,
actions encoding in BGP Extended Communities. The two application and a set of actions encoding in BGP Extended Communities. The two
specific NLRI identifiers are: application specific NLRI identifiers are:
o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with
specific semantic rules for IPv4 routes, and specific semantic rules for IPv4 routes, and
o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which
can be used to propagate traffic filtering information in a BGP/ can be used to propagate traffic filtering information in a BGP/
MPLS VPN environment. MPLS VPN environment.
Encoding of the NLRI is described in Section 4 for IPv4 Flow Encoding of the NLRI is described in Section 4 for IPv4 Flow
Specification and in Section 8 for VPNv4 Flow Specification. The Specification and in Section 8 for VPNv4 Flow Specification. The
skipping to change at page 19, line 40 skipping to change at page 19, line 40
The neighboring AS is the immediate destination of the traffic The neighboring AS is the immediate destination of the traffic
described by the Flow Specification. If it requests these flows to described by the Flow Specification. If it requests these flows to
be dropped, that request can be honored without concern that it be dropped, that request can be honored without concern that it
represents a denial of service in itself. Supposedly, the traffic is represents a denial of service in itself. Supposedly, the traffic is
being dropped by the downstream autonomous system, and there is no being dropped by the downstream autonomous system, and there is no
added value in carrying the traffic to it. added value in carrying the traffic to it.
7. Traffic Filtering Actions 7. Traffic Filtering Actions
This document defines a minimum set of Traffic Filtering Actions that This document defines a minimum set of Traffic Filtering Actions that
it standardizes as BGP extended community values [RFC4360]. This is it standardizes as BGP extended community values [RFC7153]. This is
not meant to be an inclusive list of all the possible actions, but not meant to be an inclusive list of all the possible actions, but
only a subset that can be interpreted consistently across the only a subset that can be interpreted consistently across the
network. Additional actions can be defined as either requiring network. Additional actions can be defined as either requiring
standards or as vendor specific. standards or as vendor specific.
The default action for a matching Flow Specification is to accept the The default action for a matching Flow Specification is to accept the
packet (treat the packet according to the normal forwarding behaviour packet (treat the packet according to the normal forwarding behaviour
of the system). of the system).
This document defines the following extended communities values shown This document defines the following extended communities values shown
skipping to change at page 34, line 17 skipping to change at page 34, line 17
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
15.3. URIs 15.3. URIs
[1] https://github.com/stoffi92/flowspec-cmp [1] https://github.com/stoffi92/flowspec-cmp
Appendix A. Python code: flow_rule_cmp Appendix A. Python code: flow_rule_cmp
<CODE BEGINS> <CODE BEGINS>
""" """
Copyright (c) 2019 IETF Trust and the persons identified as authors of Copyright (c) 2020 IETF Trust and the persons identified as authors of
the code. All rights reserved. the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
""" """
import itertools import itertools
skipping to change at page 36, line 32 skipping to change at page 36, line 32
Section 7.7 contains general considerations on interfering traffic Section 7.7 contains general considerations on interfering traffic
actions. Section 7.3 also cross-references this section. actions. Section 7.3 also cross-references this section.
[RFC5575] did not mention this. [RFC5575] did not mention this.
Section 10 contains new error handling. Section 10 contains new error handling.
Authors' Addresses Authors' Addresses
Christoph Loibl Christoph Loibl
Next Layer Communications next layer Telekom GmbH
Mariahilfer Guertel 37/7 Mariahilfer Guertel 37/7
Vienna 1150 Vienna 1150
AT AT
Phone: +43 664 1176414 Phone: +43 664 1176414
Email: cl@tix.at Email: cl@tix.at
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
 End of changes. 15 change blocks. 
29 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/