draft-ietf-idr-rfc5575bis-12.txt   draft-ietf-idr-rfc5575bis-13.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: August 31, 2019 R. Raszuk Expires: October 14, 2019 R. Raszuk
Bloomberg LP Bloomberg LP
D. McPherson D. McPherson
Verisign Verisign
M. Bacher M. Bacher
T-Mobile Austria T-Mobile Austria
February 27, 2019 April 12, 2019
Dissemination of Flow Specification Rules Dissemination of Flow Specification Rules
draft-ietf-idr-rfc5575bis-12 draft-ietf-idr-rfc5575bis-13
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
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 August 31, 2019. This Internet-Draft will expire on October 14, 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 25 skipping to change at page 3, line 25
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. Considerations on Traffic Action Interference . . . . . . 21 7.6. Considerations on Traffic Action Interference . . . . . . 21
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 . 23 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
Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24
11. Error-Handling and Future NLRI Extensions . . . . . . . . . . 24 11. Error-Handling and Future NLRI Extensions . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25 12.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25
12.2. Flow Component Definitions . . . . . . . . . . . . . . . 25 12.2. Flow Component Definitions . . . . . . . . . . . . . . . 25
12.3. Extended Community Flow Specification Actions . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . . 30 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
skipping to change at page 14, line 30 skipping to change at page 14, line 30
5. Traffic Filtering 5. Traffic Filtering
Traffic filtering policies have been traditionally considered to be Traffic filtering policies have been traditionally considered to be
relatively static. Limitations of the static mechanisms caused this relatively static. Limitations of the static mechanisms caused this
mechanism to be designed for the three new applications of traffic mechanism to be designed for the three new applications of traffic
filtering (prevention of traffic-based, denial-of-service (DOS) filtering (prevention of traffic-based, denial-of-service (DOS)
attacks, traffic filtering in the context of BGP/MPLS VPN service, attacks, traffic filtering in the context of BGP/MPLS VPN service,
and centralized traffic control for SDN/NFV networks) requires and centralized traffic control for SDN/NFV networks) requires
coordination among service providers and/or coordination among the AS coordination among service providers and/or coordination among the AS
within a service provider. Section 8 has details on the limitation within a service provider. Section 9 has details on the limitation
of previous mechanisms and why BGP Flow Specification provides a of previous mechanisms and why BGP Flow Specification provides a
solution for to prevent DOS and aid BGP/MPLS VPN filtering rules. solution for to prevent DOS and aid BGP/MPLS VPN filtering rules.
This Flow Specification NLRI defined above to convey information This Flow Specification NLRI defined above to convey 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 manner specified by a set of pre-defined actions (which handled in 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.
skipping to change at page 15, line 9 skipping to change at page 15, line 9
actions encoding in BGP Extended Communities. The two application actions encoding in BGP Extended Communities. The two application
specific NLRI identifiers are: 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.
Distribution of the IPv4 Flow Specification is described in section Distribution of the IPv4 Flow Specification is described in
6, and distibution of BGP/MPLS traffic Flow Specification is Section 6, and distibution of BGP/MPLS traffic Flow Specification is
described in section 8. The traffic filtering actions are described described in Section 8. The traffic filtering actions are described
in section 7. in Section 7.
5.1. Ordering of Traffic Filtering Rules 5.1. Ordering of Traffic Filtering Rules
With traffic filtering rules, more than one rule may match a With traffic filtering rules, more than one rule may match a
particular traffic flow. Thus, it is necessary to define the order particular traffic flow. Thus, it is necessary to define the order
at which rules get matched and applied to a particular traffic flow. at which rules get matched and applied to a particular traffic flow.
This ordering function must be such that it must not depend on the This ordering function must be such that it must not depend on the
arrival order of the Flow Specification's rules and must be arrival order of the Flow Specification's rules and must be
consistent in the network. consistent in the network.
skipping to change at page 24, line 7 skipping to change at page 24, line 7
filtering information is intermingled with routing information. filtering information is intermingled with routing information.
The mechanism defined in this document is designed to address these The mechanism defined in this document is designed to address these
limitations. We use the Flow Specification NLRI defined above to limitations. We use the Flow Specification NLRI defined above to
convey information about traffic filtering rules for traffic that is convey information about traffic filtering rules for traffic that is
subject to modified forwarding behavior (actions). The actions are subject to modified forwarding behavior (actions). The actions are
defined as extended communities and include (but are not limited to) defined as extended communities and include (but are not limited to)
rate-limiting (including discard), traffic redirection, packet rate-limiting (including discard), traffic redirection, packet
rewriting. rewriting.
9.2. Limitations in Previous BGP/MPLS Traffic Filtering 9.2. Limitations in Previous BGP/MPLS Traffic Filtering Efforts
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. filtering requirements than Internet service providers.
In these environments, the VPN customer network often has traffic In these environments, the VPN customer network often has traffic
filtering capabilities towards their external network connections filtering capabilities towards their external network connections
(e.g., firewall facing public network connection). Less common is (e.g., firewall facing public network connection). Less common is
the presence of traffic filtering capabilities between different VPN the presence of traffic filtering capabilities between different VPN
attachment sites. In an any-to-any connectivity model, which is the attachment sites. In an any-to-any connectivity model, which is the
skipping to change at page 30, line 39 skipping to change at page 30, line 39
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris
Morrow, Charlie Kaufman, and David Smith for their comments for the Morrow, Charlie Kaufman, and David Smith for their comments for the
comments on the original RFC5575. Chaitanya Kodeboyina helped design comments on the original RFC5575. Chaitanya Kodeboyina helped design
the flow validation procedure; and Steven Lin and Jim Washburn ironed the flow validation procedure; and Steven Lin and Jim Washburn ironed
out all the details necessary to produce a working implementation in out all the details necessary to produce a working implementation in
the original RFC5575. the original RFC5575.
Additional the authors would like to thank Alexander Mayrhofer, Additional the authors would like to thank Alexander Mayrhofer,
Nicolas Fevrier, Job Snijders and Jeffrey Haas for their comments and Nicolas Fevrier, Job Snijders, Jeffrey Haas and Adam Chappell for
review. their comments and review.
17. References 17. References
17.1. Normative References 17.1. Normative References
[IEEE.754.1985] [IEEE.754.1985]
IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE, "Standard for Binary Floating-Point Arithmetic",
IEEE 754-1985, August 1985. IEEE 754-1985, August 1985.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
 End of changes. 9 change blocks. 
13 lines changed or deleted 14 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/