[Idr] Review of draft-ietf-grow-bgp-reject-05
"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 18 April 2017 13:08 UTC
Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D34129B73; Tue, 18 Apr 2017 06:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5y-eTtJBXAg; Tue, 18 Apr 2017 06:08:48 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605361274D0; Tue, 18 Apr 2017 06:08:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=90426; q=dns/txt; s=iport; t=1492520928; x=1493730528; h=from:to:cc:subject:date:message-id:mime-version; bh=2WvTI+1JCzeVr44o5VrUI2tzis7HnBquxDT3H4hyngM=; b=laPn7n/VCkIqps7zmdhX+KjZxs63PrJIbkehFgbW07kb1T0dxxP3d6Ud KEVChyuDql73EeuQ3TB14gING+bKRsum2Aqt1EvONerO/fboYXDXML8g8 g/k78eCLonCq71XDDZm5DxWF03kPMiT/4295Lv6BOdhNdV81cenIeLBgn 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CKAgAUD/ZY/5ldJa1cGQEBAQEBAQEBAQEBBwEBAQEBgm5lYYELB4NfihWRQpYCgg8sgkKDNhyDUz8YAQIBAQEBAQEBax0LhTYJCkwSAQY6AQkCBDAnBA4FG4l+DoxUnV2CJiuKeAEBAQEBAQEBAQEBAQEBAQEBAQEBHoZSgV0rCoJjhCkRAYMiLoIxBZY0hm4BgVWFLoMtgymFEIIAGTyEXIhdgTqIa4Z7hCcBHzh9CGMVRBEBhlIBdYZOBQoXgQqBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208,217";a="413846158"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 13:08:47 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3ID8lt2003076 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Apr 2017 13:08:47 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 08:08:46 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 18 Apr 2017 08:08:46 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-grow-bgp-reject@ietf.org" <draft-ietf-grow-bgp-reject@ietf.org>
CC: "grow@ietf.org" <grow@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, Warren Kumari <warren@kumari.net>
Thread-Topic: Review of draft-ietf-grow-bgp-reject-05
Thread-Index: AQHSuETpEi5RDG0LC02mWBjlM+E8lA==
Date: Tue, 18 Apr 2017 13:08:46 +0000
Message-ID: <27BC3D10-48EA-4751-A70A-0753B0437F8F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.6]
Content-Type: multipart/alternative; boundary="_000_27BC3D1048EA4751A70A0753B0437F8Fciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/gU6sk8yrC3uF7aLERwnDh2cuFP4>
Subject: [Idr] Review of draft-ietf-grow-bgp-reject-05
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2017 13:08:52 -0000
[Speaking as a grow WG participant.] Hi! I support this document and its publication. However, if this document “defines the default behavior of a BGP speaker…”, then it should explicitly Update rfc4271 and be a little stricter in the language it uses. Please see detailed comments below along with suggested text. Thanks! Alvaro. 2 Global Routing Operations J. Mauch 3 Internet-Draft Akamai 4 Intended status: Standards Track J. Snijders 5 Expires: October 12, 2017 NTT 6 G. Hankins 7 Nokia 8 April 10, 2017 The header should indicate that this document “Updates: 4271”. 10 Default EBGP Route Propagation Behavior Without Policies 11 draft-ietf-grow-bgp-reject-05 13 Abstract 15 This document defines the default behavior of a BGP speaker when 16 there is no import or export policy associated with an External BGP 17 session. NEW> This document updates RFC4271 by defining the default behavior… 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 12, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 64 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 7.2. Informative References . . . . . . . . . . . . . . . . . 4 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 70 1. Introduction 72 There are BGP routing security issues that need to be addressed to 73 make the Internet more stable. Route leaks [RFC7908] are part of the 74 problem, but software defects or operator misconfigurations can 75 contribute too. This document provides guidance to BGP [RFC4271] 76 implementers to improve the default level of Internet routing 77 security. s/This document…/This document updates RFC4271 in order to improve the default level… 79 Many deployed BGP speakers send and accept any and all route 80 announcements between their BGP neighbors by default. This practice 81 dates back to the early days of the Internet, where operators were 82 permissive in sending routing information to allow all networks to 83 reach each other. As the Internet has become more densely 84 interconnected, the risk of a misbehaving BGP speaker poses 85 significant risks to Internet routing. 87 This specification intends to improve this situation by requiring the 88 explicit configuration of a BGP import and export policy for any 89 External BGP (EBGP) session such as customers, peers, or 90 confederation boundaries for all enabled address families. When this 91 solution is implemented, BGP speakers do not accept or send routes 92 without policies configured on EBGP sessions. s/accept/use (or maybe “considered”) The text in Section 2 talks about the received eBGP routes being ineligible, which implies that they were received, just not used/considered. There is probably no real practical way to not receive the routes, unless the document also specifies the use of route refresh to get the updates again once the policy is configured. But I think that would just add complexity. NEW Section> Terminology [RFC4271] describes a Policy Information Base (PIB) which contains local policies that can be applied to the information in the Routing Information Base (RIB). This document distinguishes the type of policy based on its application. Import Policy: Local policy to be applied to the information contained in the Adj-RIBs-In. As described in [Section 3.2 of RFC4271], the Adj-RIBs-In contain information learned from other BGP speakers, and the application of the Import Policy results in the routes that will be used by the local BGP speaker. Export Policy: Local policy to be applied in selecting the information contained in the Adj-RIBs-Out. As described in [Section 3.2 of RFC4271], the Adj-RIBs-Out contain information that has been selected to advertisement to other BGP speakers. 94 2. Solution NEW> Changes to RFC4271 96 The following requirements apply to all BGP speakers: NEW> This section describes the Updates to [RFC4271] that define the default behavior of a BGP speaker when there are no Import or Export Policies associated with a particular EBGP session. 98 o A BGP speaker MUST consider any routes advertised by an EBGP peer 99 ineligible for route selection (section 9.1.1 [RFC4271]), if no 100 import policy was configured for the peer. Note that 9.1.1. says that if “the route is ineligible, the route MAY NOT serve as an input to the next phase of route selection”. IOW, even if routes are “ineligible” they can still be used (because of the MAY), which is not what is wanted. 102 o A BGP speaker MUST NOT advertise any routes to an EBGP peer, if no 103 export policy was configured for the peer. 105 o A BGP speaker SHOULD fall back to an "import nothing" and "export 106 nothing" mode following failure of internal components, such as a 107 policy engine. 109 o A BGP speaker MAY provide a configuration option to disable the 110 preceding behaviors, but it MUST implement them by default. NEW> The following paragraph is added to Section 9.1 (Decision Process) after the fifth paragraph: Routes contained in an Adj-RIB-In associated with an EBGP peer SHALL NOT be considered in the Decision Process if no explicit Import Policy has been defined. The following paragraph is added to Section 9.1.3 (Phase 3: Route Dissemination) after the third paragraph: Routes SHALL NOT be added to an Adj-RIB-Out associated with an EBGP peer if no explicit Export Policy has been defined. A failure of the PIB SHOULD be considered as if no Import or Export Policy is associated with the affected EBGP sessions. The behavior described above MAY be disabled by explicit configuration. === FWIW, I think that the “SHOULD” above would be better as a “MUST”. 112 3. Acknowledgments 114 The authors would like to thank the following people for their 115 comments, support and review: Shane Amante, Christopher Morrow, 116 Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, 117 Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald 118 Smith, and Dale Worley. 120 4. Security Considerations 122 This document addresses a basic routing security issue caused by 123 permissive default routing policy configurations. Operators need 124 implementers to address this problem with more secure defaults to 125 mitigate collateral damage on Internet routing. Inadvertent or 126 adversarial advertisements cause business impact that can be 127 mitigated by a secure default behavior. NEW> Permissive default routing policies can result in inadvertent effects such as route leaks [RFC7908], in general resulting in rerouting of traffic through an unexpected path. While it is possible for an operator to use monitoring to detect unexpected flows, there is no general framework that can be applied. These policies also have the potential of exposing software defects or misconfigurations that could have unforeseen technical and business impacting effects. The update to RFC4271 specified in this document is aimed at eliminating those inadvertent effects. Operators must explicitly configure Import and Export Policies to achieve their expected goals. There is of course no protection against a malicious or incorrect explicit configuration. The security considerations described in [RFC4271] and the vulnerability analysis discussed in [RFC4272] also apply to this document. 129 5. IANA Considerations 131 This document has no actions for IANA. 133 6. Contributors 135 The following people contributed to successful deployment of solution 136 described in this document: 138 Jakob Heitz 139 Cisco 141 Email: jheitz@cisco.com 142 Ondrej Filip 143 CZ.NIC 145 Email: ondrej.filip@nic.cz 147 7. References 149 7.1. Normative References 151 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 152 Requirement Levels", BCP 14, RFC 2119, 153 DOI 10.17487/RFC2119, March 1997, 154 <http://www.rfc-editor.org/info/rfc2119>. 156 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 157 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 158 DOI 10.17487/RFC4271, January 2006, 159 <http://www.rfc-editor.org/info/rfc4271>. 161 7.2. Informative References 163 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 164 and B. Dickson, "Problem Definition and Classification of 165 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 166 2016, <http://www.rfc-editor.org/info/rfc7908>. Add an Informative reference to RFC4272. 168 Authors' Addresses 170 Jared Mauch 171 Akamai Technologies 172 8285 Reese Lane 173 Ann Arbor Michigan 48103 174 US 176 Email: jared@akamai.com 178 Job Snijders 179 NTT Communications 180 Theodorus Majofskistraat 100 181 Amsterdam 1065 SZ 182 NL 184 Email: job@ntt.net 185 Greg Hankins 186 Nokia 187 777 E. Middlefield Road 188 Mountain View, CA 94043 189 USA 191 Email: greg.hankins@nokia.com
- [Idr] Review of draft-ietf-grow-bgp-reject-05 Alvaro Retana (aretana)
- Re: [Idr] Review of draft-ietf-grow-bgp-reject-05 Job Snijders
- Re: [Idr] Review of draft-ietf-grow-bgp-reject-05 John G. Scudder
- Re: [Idr] Review of draft-ietf-grow-bgp-reject-05 Alvaro Retana (aretana)
- Re: [Idr] [GROW] Review of draft-ietf-grow-bgp-re… Jared Mauch
- Re: [Idr] [GROW] Review of draft-ietf-grow-bgp-re… Job Snijders
- Re: [Idr] [GROW] Review of draft-ietf-grow-bgp-re… Alvaro Retana (aretana)