draft-ietf-idr-bgp-flowspec-oid-09.txt   draft-ietf-idr-bgp-flowspec-oid-10.txt 
Network Working Group J. Uttaro Network Working Group J. Uttaro
Internet-Draft AT&T Internet-Draft AT&T
Updates: 5575bis (if approved) J. Alcaide Updates: 5575bis (if approved) J. Alcaide
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: January 9, 2020 D. Smith Expires: February 9, 2020 D. Smith
Cisco Cisco
P. Mohapatra P. Mohapatra
Sproute Networks Sproute Networks
July 8, 2019 August 8, 2019
Revised Validation Procedure for BGP Flow Specifications Revised Validation Procedure for BGP Flow Specifications
draft-ietf-idr-bgp-flowspec-oid-09 draft-ietf-idr-bgp-flowspec-oid-10
Abstract Abstract
This document describes a modification to the validation procedure This document describes a modification to the validation procedure
defined in RFC 5575bis for the dissemination of BGP Flow defined in [RFC5575bis] for the dissemination of BGP Flow
Specifications. RFC 5575bis requires that the originator of the Flow Specifications. [RFC5575bis] requires that the originator of the
Specification matches the originator of the best-match unicast route Flow Specification matches the originator of the best-match unicast
for the destination prefix embedded in the Flow Specification. This route for the destination prefix embedded in the Flow Specification.
allows only BGP speakers within the data forwarding path (such as This allows only BGP speakers within the data forwarding path (such
autonomous system border routers) to originate BGP Flow as autonomous system border routers) to originate BGP Flow
Specifications. Though it is possible to disseminate such Flow Specifications. Though it is possible to disseminate such Flow
Specifications directly from border routers, it may be operationally Specifications directly from border routers, it may be operationally
cumbersome in an autonomous system with a large number of border cumbersome in an autonomous system with a large number of border
routers having complex BGP policies. The modification proposed routers having complex BGP policies. The modification proposed
herein enables Flow Specifications to be originated from a herein enables Flow Specifications to be originated from a
centralized BGP route controller. centralized BGP route controller.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 January 9, 2020. This Internet-Draft will expire on February 9, 2020.
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 2, line 34 skipping to change at page 2, line 34
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Revised Validation Procedure . . . . . . . . . . . . . . . . 5 4. Revised Validation Procedure . . . . . . . . . . . . . . . . 5
4.1. Revision of Route Feasibility . . . . . . . . . . . . . . 5 4.1. Revision of Route Feasibility . . . . . . . . . . . . . . 5
4.2. Revision of AS_PATH Validation . . . . . . . . . . . . . 6 4.2. Revision of AS_PATH Validation . . . . . . . . . . . . . 6
5. Other RFC5575bis Considerations . . . . . . . . . . . . . . . 7 5. Other RFC5575bis Considerations . . . . . . . . . . . . . . . 7
6. Topology Considerations . . . . . . . . . . . . . . . . . . . 8 6. Topology Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
[RFC5575bis] defined a new BGP [RFC4271] capability that can be used [RFC5575bis] defined a new BGP [RFC4271] capability that can be used
skipping to change at page 7, line 18 skipping to change at page 7, line 18
Flow Specification NLRIs. Requiring a full AS_PATH match would Flow Specification NLRIs. Requiring a full AS_PATH match would
limit origination of inter-domain Flow Specifications to the limit origination of inter-domain Flow Specifications to the
origin AS of the best-match unicast route for the destination origin AS of the best-match unicast route for the destination
prefix embedded in the Flow Specification only. As such, a full prefix embedded in the Flow Specification only. As such, a full
AS_PATH validity check may prevent transit ASes from originating AS_PATH validity check may prevent transit ASes from originating
inter-domain Flow Specifications, which is not desirable. inter-domain Flow Specifications, which is not desirable.
Redefinition of this AS_PATH validation rule for a Flow Redefinition of this AS_PATH validation rule for a Flow
Specification does not mean that the original rule in [RFC5575bis] Specification does not mean that the original rule in [RFC5575bis]
cannot be enforced as well. Its enforcement remains optional per cannot be enforced as well. Its enforcement remains optional per
[RFC4271]. That is, we can enforce the first AS in the AS_PATH to [RFC4271] section 6.3. That is, we can enforce the first AS in
be the same as the neighbor AS for any address-family route the AS_PATH to be the same as the neighbor AS for any address-
(including a Flow Specification). family route (including a Flow Specification).
Using the new rule to validate a Flow Specification received from Using the new rule to validate a Flow Specification received from
an Internal Border Gateway Protocol (iBGP) peer is out of the an Internal Border Gateway Protocol (iBGP) peer is out of the
scope of this document. Note that in most scenarios such scope of this document. Note that in most scenarios such
validation would be redundant. validation would be redundant.
Using the new rule to validate a Flow Specification route received Using the new rule to validate a Flow Specification route received
from an External Border Gateway Protocol (eBGP) peer belonging to from an External Border Gateway Protocol (eBGP) peer belonging to
the same local domain (in the case that the local AS belongs to a the same local domain (in the case that the local AS belongs to a
confederation of ASes) is out of the scope of this document. Note confederation of ASes) is out of the scope of this document. Note
skipping to change at page 9, line 42 skipping to change at page 9, line 42
exists). The validation procedure will fail because the exists). The validation procedure will fail because the
topology is non-congruent across domains. topology is non-congruent across domains.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
No new security issues are introduced by relaxing the validation No new security issues are introduced by relaxing the validation
procedure for iBGP learned Flow Specifications. With this proposal, procedure for IBGP learned Flow Specifications. With this proposal,
the security characteristics of BGP Flow Specifications remain the security characteristics of BGP Flow Specifications remain
equivalent to the existing security properties of BGP unicast equivalent to the existing security properties of BGP unicast
routing. Traffic Flow Specifications learned from iBGP peers are routing.
trusted, hence, it is not required to validate that the originator of
an intra-domain traffic Flow Specification matches the originator of BGP updates learned from iBGP peers are trusted so the Traffic Flow
the best-match unicast route for the flow destination prefix. Specifications contained in BGP updates are trusted. Therefore it is
Conversely, this proposal continues to enforce the validation not required to validate that the originator of an intra-domain
procedure for eBGP learned traffic Flow Specifications. In this way, Traffic Flow Specification matches the originator of the best-match
unicast route for the flow destination prefix. This proposal
continues to enforce the validation Procedure for eBGP learned
Traffic Flow Specifications, as per [RFC5575bis] rules. In this way,
the security properties of [RFC5575bis] are maintained such that an the security properties of [RFC5575bis] are maintained such that an
eBGP peer cannot cause a denial-of-service attack by advertising an EBGP peer cannot cause a denial-of-service attack by advertising an
inter-domain Flow Specification for a destination prefix that it does inter-domain Flow Specification for a destination prefix that it does
not provide reachability information for. not provide reachability information for.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Han Nguyen for his direction on this The authors would like to thank Han Nguyen for his direction on this
work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen
and Shyam Sethuram for their review comments. and Shyam Sethuram for their review comments.
10. Normative References 10. Normative References
 End of changes. 10 change blocks. 
22 lines changed or deleted 25 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/