[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: =?us-ascii?q?A0CKAgAUD/ZY/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5lYYELB4NfihWRQpYCgg8sgkKDNhyDUz8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhTYJCkwSAQY6AQkCBDAnBA4FG4l+DoxUnV2CJiuKeAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHoZSgV0rCoJjhCkRAYMiLoIxBZY0hm4BgVWFLoMtgymFEIIAGTyEXIh?= =?us-ascii?q?dgTqIa4Z7hCcBHzh9CGMVRBEBhlIBdYZOBQoXgQqBDQEBAQ?=
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