Re: [Idr] Review of draft-ietf-grow-bgp-reject-05

[Job Snijders <[e-mail]>]

Dear all,

Alvaro's proposal presents a significant change to the document. As
document authors, we've requested the responsible AD (Warren Kumari) to
extend the IETF Last Call to be able to process the suggestions. Thanks!

Kind regards,

Job

On Tue, Apr 18, 2017 at 01:08:46PM +0000, Alvaro Retana (aretana) wrote:
> [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: [e-mail]
> 142        Ondrej Filip
> 143        CZ.NIC
> 
> 145        Email: [e-mail]
> 
> 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: [e-mail]
> 
> 178        Job Snijders
> 179        NTT Communications
> 180        Theodorus Majofskistraat 100
> 181        Amsterdam  1065 SZ
> 182        NL
> 
> 184        Email: [e-mail]
> 185        Greg Hankins
> 186        Nokia
> 187        777 E. Middlefield Road
> 188        Mountain View, CA  94043
> 189        USA
> 
> 191        Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr