Dear Dale, I'd be happy to incorporate these changes. I appreciate that you clarified the text. Attached is an easy-to-read html rfcdiff which contains Dale Worley's proposed changes verbatim. Unless someone speaks up against this proposal, I'll upload this as a new -05 revision somewhere in the next few days. Kind regards, Job On Mon, Apr 10, 2017 at 06:26:16PM -0700, Dale Worley wrote: > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-grow-bgp-reject-04 > Reviewer: Dale R. Worley > Review Date: 2017-04-10 > IETF LC End Date: 2017-04-18 > IESG Telechat date: not scheduled > > Summary: This draft is basically ready for publication, but has nits > that should be fixed before publication. > > This is the shortest draft I've ever reviewed. There are only 41 > lines of text that contain technical content. > > My knowledge of BGP is quite limited, so I cannot review the > desirability of this solution. I assume that the routing and > operations community has fully considered that question. > > I find the wording of section 2 to be poor: > > 2. Solution Requirements > > The following requirements apply to the solution described in this > document: > > o Software MUST consider any routes ineligible for route selection > (section 9.1.1 [RFC4271]), if no import policy was configured > for the EBGP peer. > > o Software MUST NOT advertise any routes to an EBGP peer, if no > export policy was configured. > > o Software SHOULD fall back to an "import nothing" and "export > nothing" mode following failure of internal components, such as > a policy engine. > > o Software MUST operate in this mode by default. > > o Software MAY provide a configuration option to disable this > security capability. > > First, section 2 isn't the requirements for the solution, but the > requirements *on BGP speakers* constitute the solution itself. > Second, "software" seems to be a misnomer for "BGP speaker". (Compare > with RFC 4271.) Third, the interaction of the final item with the > 2119 words in the preceding items is awkward. Fourth, it seems that > "routes" in the first item should be qualified by "advertised by an > EBGP peer". In all cases, what is intended is clear, but the words > don't seem to say it well. > > Revising the phrasing, I get: > > 2. Solution > > The following requirements apply to all BGP speakers: > > o A BGP speaker MUST consider any routes advertised by an EBGP peer > ineligible for route selection (section 9.1.1 [RFC4271]), if no > import policy was configured for the peer. > > o A BGP speaker MUST NOT advertise any routes to an EBGP peer, if > no export policy was configured. > > o A BGP speaker SHOULD fall back to an "import nothing" and > "export nothing" mode following failure of internal components, > such as a policy engine. > > o A BGP speaker MAY provide a configuration option to disable the > preceding behaviors, but it MUST implement them by default.Title: Diff: draft-ietf-grow-bgp-reject-04.txt - draft-ietf-grow-bgp-reject-05.txt
| draft-ietf-grow-bgp-reject-04.txt | draft-ietf-grow-bgp-reject-05.txt | |||
|---|---|---|---|---|
| Global Routing Operations J. Mauch | Global Routing Operations J. Mauch | |||
| Internet-Draft Akamai | Internet-Draft Akamai | |||
| Intended status: Standards Track J. Snijders | Intended status: Standards Track J. Snijders | |||
| Expires: September 28, 2017 NTT | Expires: October 13, 2017 NTT | |||
| G. Hankins | G. Hankins | |||
| Nokia | Nokia | |||
| March 27, 2017 | April 11, 2017 | |||
| Default EBGP Route Propagation Behavior Without Policies | Default EBGP Route Propagation Behavior Without Policies | |||
| draft-ietf-grow-bgp-reject-04 | draft-ietf-grow-bgp-reject-05 | |||
| Abstract | Abstract | |||
| This document defines the default behavior of a BGP speaker when | This document defines the default behavior of a BGP speaker when | |||
| there is no import or export policy associated with an External BGP | there is no import or export policy associated with an External BGP | |||
| session. | session. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| skipping to change at page 1, line 41 | skipping to change at page 1, line 41 | |||
| 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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 September 28, 2017. | This Internet-Draft will expire on October 13, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://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 | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 | 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 | 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . 4 | 7.2. Informative References . . . . . . . . . . . . . . . . . 4 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1. Introduction | 1. Introduction | |||
| skipping to change at page 3, line 5 | skipping to change at page 3, line 5 | |||
| interconnected, the risk of a misbehaving BGP speaker poses | interconnected, the risk of a misbehaving BGP speaker poses | |||
| significant risks to Internet routing. | significant risks to Internet routing. | |||
| This specification intends to improve this situation by requiring the | This specification intends to improve this situation by requiring the | |||
| explicit configuration of a BGP import and export policy for any | explicit configuration of a BGP import and export policy for any | |||
| External BGP (EBGP) session such as customers, peers, or | External BGP (EBGP) session such as customers, peers, or | |||
| confederation boundaries for all enabled address families. When this | confederation boundaries for all enabled address families. When this | |||
| solution is implemented, BGP speakers do not accept or send routes | solution is implemented, BGP speakers do not accept or send routes | |||
| without policies configured on EBGP sessions. | without policies configured on EBGP sessions. | |||
| 2. Solution Requirements | 2. Solution | |||
| The following requirements apply to the solution described in this | The following requirements apply to all BGP speakers: | |||
| document: | ||||
| o Software MUST consider any routes ineligible for route selection | o A BGP speaker MUST consider any routes advertised by an EBGP peer | |||
| (section 9.1.1 [RFC4271]), if no import policy was configured for | (section 9.1.1 [RFC4271]), if no import policy was configured for | |||
| the EBGP peer. | the peer. | |||
| o Software MUST NOT advertise any routes to an EBGP peer, if no | o A BGP speaker MUST NOT advertise any routes to an EBGP peer, if no | |||
| export policy was configured. | export policy was configured. | |||
| o Software SHOULD fall back to an "import nothing" and "export | o A BGP speaker SHOULD fall back to an "import nothing" and "export | |||
| nothing" mode following failure of internal components, such as a | nothing" mode following failure of internal components, such as a | |||
| policy engine. | policy engine. | |||
| o Software MUST operate in this mode by default. | o A BGP speaker MAY provide a configuration option to disable the | |||
| preceding behaviors, but it MUST implement them by default. | ||||
| o Software MAY provide a configuration option to disable this | ||||
| security capability. | ||||
| 3. Acknowledgments | 3. Acknowledgments | |||
| The authors would like to thank the following people for their | The authors would like to thank the following people for their | |||
| comments, support and review: Shane Amante, Christopher Morrow, | comments, support and review: Shane Amante, Christopher Morrow, | |||
| Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, | Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, | |||
| Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas and Donald | Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald | |||
| Smith. | Smith, and Dale Worley. | |||
| 4. Security Considerations | 4. Security Considerations | |||
| This document addresses a basic routing security issue caused by | This document addresses a basic routing security issue caused by | |||
| permissive default routing policy configurations. Operators need | permissive default routing policy configurations. Operators need | |||
| implementers to address this problem with more secure defaults to | implementers to address this problem with more secure defaults to | |||
| mitigate collateral damage on Internet routing. Inadvertent or | mitigate collateral damage on Internet routing. Inadvertent or | |||
| adversarial advertisements cause business impact that can be | adversarial advertisements cause business impact that can be | |||
| mitigated by a secure default behavior. | mitigated by a secure default behavior. | |||
| End of changes. 13 change blocks. | ||||
| 18 lines changed or deleted | 15 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||