draft-ietf-idr-rfc5575bis-11.txt   draft-ietf-idr-rfc5575bis-12.txt 
IDR Working Group S. Hares IDR Working Group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Obsoletes: 5575,7674 (if approved) C. Loibl Obsoletes: 5575,7674 (if approved) C. Loibl
Intended status: Standards Track Next Layer Communications Intended status: Standards Track Next Layer Communications
Expires: July 20, 2019 R. Raszuk Expires: August 31, 2019 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
January 16, 2019 February 27, 2019
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-11 draft-ietf-idr-rfc5575bis-12
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 specifies IPv4 traffic Flow Specifications via a BGP NLRI which It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
carries traffic Flow Specification filter, and an Extended community carries traffic Flow Specification filter, and an Extended community
value which encodes actions a routing system can take if the packet value which encodes actions a routing system can take if the packet
matches the traffic flow filters. The flow filters and the actions matches the traffic flow filters. The flow filters and the actions
are processed in a fixed order. Other drafts specify IPv6, MPLS are processed in a fixed order. Other drafts specify IPv6, MPLS
addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. addresses, L2VPN addresses, and NV03 encapsulation of IP addresses.
This document obsoletes RFC5575 and RFC7674 to correct unclear This document obsoletes RFC5575 and RFC7674 to correct unclear
specifications in the flow filters and to provide rules for actions specifications in the flow filters.
which interfere (e.g. redirection of traffic and flow filtering).
Applications which use the bgp Flow Specification are: 1) application Applications which use the bgp Flow Specification are: 1) application
which automate inter-domain coordination of traffic filtering, such which automate inter-domain coordination of traffic filtering, such
as what is required in order to mitigate (distributed) denial-of- as what is required in order to mitigate (distributed) denial-of-
service attacks; 2) applications which control traffic filtering in service attacks; 2) applications which control traffic filtering in
the context of a BGP/MPLS VPN service, and 3) applications with the context of a BGP/MPLS VPN service, and 3) applications with
centralized control of traffic in a SDN or NFV context. Some centralized control of traffic in a SDN or NFV context. Some
deployments of these three applications can be handled by the strict deployments of these three applications can be handled by the strict
ordering of the BGP NLRI traffic flow filters, and the strict actions ordering of the BGP NLRI traffic flow filters, and the strict actions
encoded in the extended community Flow Specification actions. encoded in the extended community Flow Specification actions.
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 July 20, 2019. This Internet-Draft will expire on August 31, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 3, line 19 skipping to change at page 3, line 19
5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 14 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 15 5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 15
6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 17 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 17
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 18 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 18
7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 19 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 19
7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type
TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 20 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 20
7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 21 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 21
7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 21 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 21
7.6. Rules on Traffic Action Interference . . . . . . . . . . 21 7.6. Considerations on Traffic Action Interference . . . . . . 21
7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 22
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 22 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 22
8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 23 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 23
8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 23 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 23
9. Limitations of Previous Traffic Filtering Efforts . . . . . . 23 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 23
9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 24 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 23
9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 24 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 24
10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24
11. Error-Handling and Future NLRI Extensions . . . . . . . . . . 25 11. Error-Handling and Future NLRI Extensions . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 26 12.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25
12.2. Flow Component Definitions . . . . . . . . . . . . . . . 26 12.2. Flow Component Definitions . . . . . . . . . . . . . . . 25
12.3. Extended Community Flow Specification Actions . . . . . 27 12.3. Extended Community Flow Specification Actions . . . . . 26
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. Operational Security Considerations . . . . . . . . . . . . . 30 14. Operational Security Considerations . . . . . . . . . . . . . 30
15. Original authors . . . . . . . . . . . . . . . . . . . . . . 30 15. Original authors . . . . . . . . . . . . . . . . . . . . . . 30
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
17.1. Normative References . . . . . . . . . . . . . . . . . . 31 17.1. Normative References . . . . . . . . . . . . . . . . . . 30
17.2. Informative References . . . . . . . . . . . . . . . . . 32 17.2. Informative References . . . . . . . . . . . . . . . . . 32
17.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 17.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 33 Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
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. policies.
These traffic policy mechanisms allow the router to define match These traffic policy mechanisms allow the router to define match
skipping to change at page 10, line 8 skipping to change at page 10, line 8
eq - equality between data and value. eq - equality between data and value.
The bits lt, gt, and eq can be combined to produce common relational The bits lt, gt, and eq can be combined to produce common relational
operators such as "less or equal", "greater or equal", and "not equal operators such as "less or equal", "greater or equal", and "not equal
to". to".
+----+----+----+----------------------------------+ +----+----+----+----------------------------------+
| lt | gt | eq | Resulting operation | | lt | gt | eq | Resulting operation |
+----+----+----+----------------------------------+ +----+----+----+----------------------------------+
| 0 | 0 | 0 | true (independent of the value) | | 0 | 0 | 0 | false (independent of the value) |
| 0 | 0 | 1 | == (equal) | | 0 | 0 | 1 | == (equal) |
| 0 | 1 | 0 | > (greater than) | | 0 | 1 | 0 | > (greater than) |
| 0 | 1 | 1 | >= (greater than or equal) | | 0 | 1 | 1 | >= (greater than or equal) |
| 1 | 0 | 0 | < (less than) | | 1 | 0 | 0 | < (less than) |
| 1 | 0 | 1 | <= (less than or equal) | | 1 | 0 | 1 | <= (less than or equal) |
| 1 | 1 | 0 | != (not equal value) | | 1 | 1 | 0 | != (not equal value) |
| 1 | 1 | 1 | false (independent of the value) | | 1 | 1 | 1 | true (independent of the value) |
+----+----+----+----------------------------------+ +----+----+----+----------------------------------+
Table 1: Comparison operation combinations Table 1: Comparison operation combinations
4.2.4. Type 4 - Port 4.2.4. Type 4 - Port
Encoding:<type (1 octet), [op, value]+> Encoding:<type (1 octet), [op, value]+>
Defines a list of {operator, value} pairs that matches source OR Defines a list of {operator, value} pairs that matches source OR
destination TCP/UDP ports. This list is encoded using the numeric destination TCP/UDP ports. This list is encoded using the numeric
skipping to change at page 19, line 21 skipping to change at page 19, line 21
| 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value | | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value |
| 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet | | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet |
| | | value | | | | value |
| 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value | | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value |
| 0x8009 | traffic-marking | DSCP value | | 0x8009 | traffic-marking | DSCP value |
+-----------+----------------------+--------------------------------+ +-----------+----------------------+--------------------------------+
Table 2: Traffic Action Extended Communities Table 2: Traffic Action Extended Communities
Some traffic action communities may interfere with each other. Some traffic action communities may interfere with each other.
Section 7.6 of this specification provides rules for handling Section 7.6 of this specification provides general considerations on
interference between specific types of traffic actions, and error such traffic action interference. Any additional definition of a
handling based on [RFC7606]. Any additional definition of a traffic traffic actions specified by additional standards documents or vendor
actions specified by additional standards documents or vendor
documents MUST specify if the traffic action interacts with an documents MUST specify if the traffic action interacts with an
existing traffic actions, and provide error handling per [RFC7606]. existing traffic actions, and provide error handling per [RFC7606].
Multiple traffic actions may be present for a single NLRI. The Multiple traffic actions may be present for a single NLRI. The
traffic actions are processed in ascending order of the sub-type traffic actions are processed in ascending order of the sub-type
found in the BGP Extended Communities. If not all of them can be found in the BGP Extended Communities. If not all of them can be
processed the filter SHALL NOT be applied at all (for example: if for processed the filter SHALL NOT be applied at all (for example: if for
a given flow there are the action communities rate-limit-bytes and a given flow there are the action communities rate-limit-bytes and
traffic-marking attached, and the plattform does not support one of traffic-marking attached, and the plattform does not support one of
them also the other shall not be applied for that flow). them also the other shall not be applied for that flow).
skipping to change at page 20, line 50 skipping to change at page 20, line 49
the traffic filter stops when this rule is applied. the traffic filter stops when this rule is applied.
o S: Sample (bit 46): Enables traffic sampling and logging for this o S: Sample (bit 46): Enables traffic sampling and logging for this
Flow Specification. Flow Specification.
o reserved: should always be set to 0 by the originator and not be o reserved: should always be set to 0 by the originator and not be
evaluated by the receiving BGP speaker. evaluated by the receiving BGP speaker.
The use of the Terminal Action (bit 47) may result in more than one The use of the Terminal Action (bit 47) may result in more than one
filter-rule matching a particular flow. All the flow actions from filter-rule matching a particular flow. All the flow actions from
these rules shall be collected and applied. If interfering actions these rules shall be collected and applied. In case of interfering
have been collected only the first occurence SHALL be applied. traffic actions it is an implementation decision which actions are
selected. See also Section 7.6.
However, if a single rule contains interfering actions this rule
SHALL still be handled as described in Section 7.6.
Interferes with: No other BGP Flow Specification traffic action in Interferes with: No other BGP Flow Specification traffic action in
this document. this document.
7.4. RT Redirect (rt-redirect) sub-type 0x08 7.4. RT Redirect (rt-redirect) sub-type 0x08
The redirect extended community allows the traffic to be redirected The redirect extended community allows the traffic to be redirected
to a VRF routing instance that lists the specified route-target in to a VRF routing instance that lists the specified route-target in
its import policy. If several local instances match this criteria, its import policy. If several local instances match this criteria,
the choice between them is a local matter (for example, the instance the choice between them is a local matter (for example, the instance
skipping to change at page 21, line 29 skipping to change at page 21, line 26
route-target (type 0x80, 0x81, 0x82). Is uses the same encoding as route-target (type 0x80, 0x81, 0x82). Is uses the same encoding as
the Route Target extended community [RFC4360]. the Route Target extended community [RFC4360].
It should be noted that the low-order nibble of the Redirect's Type It should be noted that the low-order nibble of the Redirect's Type
field corresponds to the Route Target Extended Community format field field corresponds to the Route Target Extended Community format field
(Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of (Type). (See Sections 3.1, 3.2, and 4 of [RFC4360] plus Section 2 of
[RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended [RFC5668].) The low-order octet (Sub-Type) of the Redirect Extended
Community remains 0x08 for all three encodings of the BGP Extended Community remains 0x08 for all three encodings of the BGP Extended
Communities (AS 2-byte, AS 4-byte, and IPv4 address). Communities (AS 2-byte, AS 4-byte, and IPv4 address).
Interferes with: All other redirect functions. All redirect Interferes with: All other redirect functions.
functions are mutually exclusive. If this redirect function exists,
then no other redirect functions can be processed.
7.5. Traffic Marking (traffic-marking) sub-type 0x09 7.5. Traffic Marking (traffic-marking) sub-type 0x09
The traffic marking extended community instructs a system to modify The traffic marking extended community instructs a system to modify
the DSCP bits of a transiting IP packet to the corresponding value. the DSCP bits of a transiting IP packet to the corresponding value.
This extended community is encoded as a sequence of 5 zero bytes This extended community is encoded as a sequence of 5 zero bytes
followed by the DSCP value encoded in the 6 least significant bits of followed by the DSCP value encoded in the 6 least significant bits of
6th byte. 6th byte.
Interferes with: No other BGP Flow Specification traffic action in Interferes with: No other BGP Flow Specification traffic action in
this document. this document.
7.6. Rules on Traffic Action Interference 7.6. Considerations on Traffic Action Interference
Traffic actions may interfere with each other. If interfering
traffic actions are present for a single Flow Specification NLRI the
entire Flow Specification (irrespective if there are any other non
conflicting actions associated with the same Flow Specification)
SHALL be treated as BGP WITHDRAW.
This document defines 7 traffic actions which are interfering in the
following way:
1. Redirect-action-communities (0x8008, 0x8108, 0x8208):
The three redirect-communities are mutually exclusive. Only a
single redirect community may be associated with a Flow
Specification otherwise they are interfering.
2. All traffic-action communities (including redirect-actions):
Multiple occurences of the same (sub-type and type) traffic-
action associated with a Flow Specification are always
interfering.
When a traffic action is defined in a standards document the handling
of interaction with other/same traffic actions MUST be defined as
well. Invalid interactions between actions SHOULD NOT trigger a BGP
NOTIFICATION. All error handling for error conditions based on
[RFC7606].
7.6.1. Examples
(rt-redirect vrf-a, rt-redirect vrf-b, traffic-rate-bytes 1Mbit/s)
RT-redirect vrf-a and rt-redirect vrf-b are interfering: The BGP
UPDATE is treated as WITHDRAW.
(rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate-bytes
2Mbit/s)
Duplicate traffic-rate-bytes are interfering: The BGP UPDATE is Since traffic actions are represented as BGP extended community
treated as WITHDRAW. values, traffic actions may interfere with each other (ie. there may
be more than one conflicting traffic-rate action associated with a
single flow-filter). Traffic action interference has no impact on
BGP propagation of flow filters (all communities are propagated
according to policies).
(rt-redirect vrf-a, traffic-rate-bytes 1Mbit/s, traffic-rate- If a flow filter associated with interfering flow actions is selected
packets 1000) for packet forwarding, it is a implementation decision which of the
interfering traffic actions are selected. Implementors of this
specification SHOULD document the behaviour of their implementation
in such cases.
No interfering action communities: The BGP UPDATE is subject to If required, operators are encouraged to make use of the BGP policy
further processing. framework supported by their implementation in order to achieve a
predictable behaviour (ie. match - replace - delete communities on
administrative boundaries).
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks
Provider-based Layer 3 VPN networks, such as the ones using a BGP/ Provider-based Layer 3 VPN networks, such as the ones using a BGP/
MPLS IP VPN [RFC4364] control plane, may have different traffic MPLS IP VPN [RFC4364] control plane, may have different traffic
filtering requirements than Internet service providers. But also filtering requirements than Internet service providers. But also
Internet service providers may use those VPNs for scenarios like Internet service providers may use those VPNs for scenarios like
having the Internet routing table in a VRF, resulting in the same having the Internet routing table in a VRF, resulting in the same
traffic filtering requirements as defined for the global routing traffic filtering requirements as defined for the global routing
table environment within this document. This document proposes an table environment within this document. This document proposes an
skipping to change at page 33, line 38 skipping to change at page 33, line 9
action to be non-transitive and did not define the transitivity of action to be non-transitive and did not define the transitivity of
the other action communities at all. the other action communities at all.
Section 7.2 introduces a new traffic filtering action (traffic- Section 7.2 introduces a new traffic filtering action (traffic-
rate-packets). This action did not exist in RFC5575. rate-packets). This action did not exist in RFC5575.
Section 7.4 contains the same redirect actions already defined in Section 7.4 contains the same redirect actions already defined in
RFC5575 however, these actions have been renamed to "rt-redirect" RFC5575 however, these actions have been renamed to "rt-redirect"
to make it clearer that the redirection is based on route-target. to make it clearer that the redirection is based on route-target.
Section 7.6 introduces rules how updates of Flow Specifications Section 7.6 contains general considerations on interfering traffic
shall be handled in case they contain interfering actions. actions. Section 7.3 also cross-references this section. RFC5575
Section 7.3 also cross-references this section. RFC5575 did not did not mention this.
define this.
Section 11 contains a modified error handling to gracefully allow
future extensions of flow specification.
Authors' Addresses Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA USA
Email: shares@ndzh.com Email: shares@ndzh.com
 End of changes. 20 change blocks. 
81 lines changed or deleted 48 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/