Subject: [GROW] Review of draft-ietf-grow-bgp-reject-05

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 18 Apr 2017 13:08:46 +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: [email-masked]
142        Ondrej Filip
143        CZ.NIC

145        Email: [email-masked]

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: [email-masked]

178        Job Snijders
179        NTT Communications
180        Theodorus Majofskistraat 100
181        Amsterdam  1065 SZ
182        NL

184        Email: [email-masked]
185        Greg Hankins
186        Nokia
187        777 E. Middlefield Road
188        Mountain View, CA  94043
189        USA

191        Email: [email-masked]

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Apr 2017 22:11:29 +0200

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

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

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 19 Apr 2017 09:26:40 -0400

> 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 (beca…

Oh cool, MAY NOT is actually not a special term defined in RFC 2119. It doesn't have any special meaning despite the ALL CAPS. I think the plain English of it is clear in context -- the authors meant MUST NOT in 2119-speak. 

I think this is actually an erratum against 4271. To make matters worse, there is one other occurrence of MAY NOT in 4271, and in that case the intent is clearly the other way around -- in 4271, section 5, we have "Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message".

I'll plan to open errata against 4271 for these.

IMO the language in draft-ietf-grow-bgp-reject-05 is OK.

--John

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 19 Apr 2017 13:53:45 +0000

John:

Hi!

My bigger issue with 9.1.1 is that it is the first step of the decision process – the intent, as I understand it, is for the routes not to even reach that point.

If the text in 9.1.1. is interpreted as “MUST NOT” (which is not what it says!), then there is probably more work to be done (in the conceptual model), but it would be ok.  However, I really have a hard time changing Normative language…

Thanks for chiming in.

Alvaro.

On 4/19/17, 9:26 AM, "John G. Scudder" <[email-masked]> wrote:

---

From: Jared Mauch <[email-masked]>
Date: Wed, 19 Apr 2017 10:03:35 -0400

> On Apr 19, 2017, at 9:53 AM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 

I’m not in agreement here as it’s well within the power of an implementation to provide a knob to circumvent these safety knobs.  We can’t have people pretending it’s the early 90s anymore.  We must have safe implementations and defaults.

Are you saying that IOS-XR is non-compliant with 9.1.1 because it does not have “bgp unsafe-ebgp-policy” as the default?  At what point does the Cisco implementation make that decision?

We seem to be triangulating on where in the exact decision process people are considering a route feasible or ineligible, can you speak to your implementation?  That may provide guidance in documenting the IOS-XR practice.

- Jared

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 19 Apr 2017 18:45:21 +0000

On 4/19/17, 10:03 AM, "Jared Mauch" <[email-masked]> wrote:

Jared:

> Are you saying that IOS-XR is non-compliant with 9.1.1 because it does not have “bgp 
> unsafe-ebgp-policy” as the default?  

No.  I wasn’t talking about any specific implementation.

One of the reasons I like your document is the fact that rfc4271 is not specific about what should be done if there is no policy – it just says that policy may be applied.  From that point of view, the XR implementation is neither compliant nor non-compliant.

> At what point does the Cisco implementation make that decision?
>
> We seem to be triangulating on where in the exact decision process people are 
> considering a route feasible or ineligible, can you speak to your implementation?  That 
> may provide guidance in documenting the IOS-XR practice.

The XR implementation makes the decision while processing the Update messages.  Specifically, it drops all the routes from a peer without an incoming policy configured.  IOW, it acts as if a deny-all filter existed.

In the conceptual model in rfc4271, the routes are not even put in the Adj-RIB-In.  

Compared to the current text (in -05), there would be no routes to mark as ineligible in 9.1.1.   The text I proposed also assumed that the routes would at least be received/stored.

If you want the same behavior as XR then you would have to make the change in Section 9. (UPDATE Message Handling).

Alvaro.

---

From: Job Snijders <[email-masked]>
Date: Wed, 19 Apr 2017 18:46:18 +0000

We got it.

On Wed, 19 Apr 2017 at 20:45, Alvaro Retana (aretana) <[email-masked]>
wrote:

> One of the reasons I like your document is the fact that rfc4271 is not
> specific about what should be done if there is no policy – it just says
> that policy may be applied.  From that point of view, the XR implementation
> is neither compliant nor non-compliant.
>
>
> The XR implementation makes the decision while processing the Update
> messages.  Specifically, it drops all the routes from a peer without an
> incoming policy configured.  IOW, it acts as if a deny-all filter existed.
>
> Compared to the current text (in -05), there would be no routes to mark as
> ineligible in 9.1.1.   The text I proposed also assumed that the routes
> would at least be received/stored.
>
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>