--- 1/draft-ietf-idr-bgp-flowspec-oid-09.txt 2019-08-09 08:13:17.490740669 -0700 +++ 2/draft-ietf-idr-bgp-flowspec-oid-10.txt 2019-08-09 08:13:17.518741379 -0700 @@ -1,33 +1,33 @@ Network Working Group J. Uttaro Internet-Draft AT&T Updates: 5575bis (if approved) J. Alcaide Intended status: Standards Track C. Filsfils -Expires: January 9, 2020 D. Smith +Expires: February 9, 2020 D. Smith Cisco P. Mohapatra Sproute Networks - July 8, 2019 + August 8, 2019 Revised Validation Procedure for BGP Flow Specifications - draft-ietf-idr-bgp-flowspec-oid-09 + draft-ietf-idr-bgp-flowspec-oid-10 Abstract This document describes a modification to the validation procedure - defined in RFC 5575bis for the dissemination of BGP Flow - Specifications. RFC 5575bis requires that the originator of the Flow - Specification matches the originator of the best-match unicast route - for the destination prefix embedded in the Flow Specification. This - allows only BGP speakers within the data forwarding path (such as - autonomous system border routers) to originate BGP Flow + defined in [RFC5575bis] for the dissemination of BGP Flow + Specifications. [RFC5575bis] requires that the originator of the + Flow Specification matches the originator of the best-match unicast + route for the destination prefix embedded in the Flow Specification. + This allows only BGP speakers within the data forwarding path (such + as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -36,21 +36,21 @@ 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 January 9, 2020. + This Internet-Draft will expire on February 9, 2020. Copyright Notice Copyright (c) 2019 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 @@ -67,21 +67,21 @@ 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Revised Validation Procedure . . . . . . . . . . . . . . . . 5 4.1. Revision of Route Feasibility . . . . . . . . . . . . . . 5 4.2. Revision of AS_PATH Validation . . . . . . . . . . . . . 6 5. Other RFC5575bis Considerations . . . . . . . . . . . . . . . 7 6. Topology Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Introduction [RFC5575bis] defined a new BGP [RFC4271] capability that can be used @@ -292,23 +292,23 @@ Flow Specification NLRIs. Requiring a full AS_PATH match would limit origination of inter-domain Flow Specifications to the origin AS of the best-match unicast route for the destination prefix embedded in the Flow Specification only. As such, a full AS_PATH validity check may prevent transit ASes from originating inter-domain Flow Specifications, which is not desirable. Redefinition of this AS_PATH validation rule for a Flow Specification does not mean that the original rule in [RFC5575bis] cannot be enforced as well. Its enforcement remains optional per - [RFC4271]. That is, we can enforce the first AS in the AS_PATH to - be the same as the neighbor AS for any address-family route - (including a Flow Specification). + [RFC4271] section 6.3. That is, we can enforce the first AS in + the AS_PATH to be the same as the neighbor AS for any address- + family route (including a Flow Specification). Using the new rule to validate a Flow Specification received from an Internal Border Gateway Protocol (iBGP) peer is out of the scope of this document. Note that in most scenarios such validation would be redundant. Using the new rule to validate a Flow Specification route received from an External Border Gateway Protocol (eBGP) peer belonging to 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 @@ -410,31 +410,34 @@ exists). The validation procedure will fail because the topology is non-congruent across domains. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations 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 equivalent to the existing security properties of BGP unicast - routing. Traffic Flow Specifications learned from iBGP peers are - trusted, hence, it is not required to validate that the originator of - an intra-domain traffic Flow Specification matches the originator of - the best-match unicast route for the flow destination prefix. - Conversely, this proposal continues to enforce the validation - procedure for eBGP learned traffic Flow Specifications. In this way, + routing. + + BGP updates learned from iBGP peers are trusted so the Traffic Flow + Specifications contained in BGP updates are trusted. Therefore it is + not required to validate that the originator of an intra-domain + 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 - 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 not provide reachability information for. 9. Acknowledgements 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 and Shyam Sethuram for their review comments. 10. Normative References