idnits 2.17.1 draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6790, but the abstract doesn't seem to directly say this. It does mention RFC6790 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 17, 2014) is 3599 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Scudder 3 Internet-Draft K. Kompella 4 Updates: 6790 (if approved) Juniper Networks 5 Intended status: Standards Track June 17, 2014 6 Expires: December 19, 2014 8 Deprecation of BGP Entropy Label Capability Attribute 9 draft-scudder-mpls-deprecate-bgp-entropy-label-00 11 Abstract 13 RFC 6790 defines the BGP Entropy Label Capability attribute. 14 Regrettably, it has a bug: although RFC 6790 mandates that Entropy 15 Label-incapable routers must remove the attribute, in practice this 16 requirement can't be guaranteed to be fulfilled. This specification 17 deprecates the attribute. A forthcoming document will propose a 18 replacement. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 19, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 [RFC6790] defines the Entropy Label Capability attribute (ELCA), an 55 optional, transitive BGP path attribute. For correct operation, it 56 is necessary that an intermediate node modifying the next hop of a 57 route must remove the ELCA unless the node so doing is able to 58 process entropy labels. Sadly, this requirement cannot be fulfilled 59 with the ELCA as specified, because it is an optional, transitive 60 attribute: by definition, a node that does not support the ELCA will 61 propagate the attribute. (This is a general property of optional, 62 transitive attributes, see [RFC4271].) But such an ELCA-oblivious 63 node is likely to also be entropy label-incapable and is exactly the 64 one that we desire to remove the attribute! 66 This specification updates RFC 6790 by deprecating the version of 67 ELCA defined in Section 5.2 of that document. A forthcoming document 68 will propose a replacement. 70 1.1. Requirements Language 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 2. IANA Considerations 78 For the reasons given in Section 1, IANA is requested to mark 79 attribute 28 in the "BGP Path Attributes" registry as "deprecated", 80 reference this RFC. 82 3. Security Considerations 84 ELCA as defined in [RFC6790] S. 5.2, has in common with other 85 optional, transitive path attributes the property that it will be 86 "tunneled" through intervening routers that don't implement the 87 relevant specification. Unfortunately, as discussed elsewhere in 88 this document, implementations of [RFC6790] S. 5.2 receiving such 89 "tunneled" attributes could -- sometimes improperly -- rely on them. 90 The consequence of so doing could be a black hole in the forwarding 91 path for the affected routes. Whether this is a new security issue 92 or not is somewhat debatable, since to be exploited an attacker would 93 have to be part of the control plane path for the route in question, 94 and under those circumstances an attacker already has a panoply of 95 mischief-making tools available, as discussed in [RFC4272]. 97 In any case, this document renders any real or imagined security 98 issues with ELCA moot, by deprecating it. 100 4. Acknowledgements 102 Thanks to Alia Atlas, Bruno Decraene, Martin Djernaes, John Drake, 103 Adrian Farrell, Keyur Patel, Ravi Singh and Kevin Wang for their 104 discussion of this issue. 106 5. References 108 5.1. Normative References 110 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 111 Requirement Levels", BCP 14, RFC 2119, March 1997. 113 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 114 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 115 RFC 6790, November 2012. 117 5.2. Informative References 119 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 120 Protocol 4 (BGP-4)", RFC 4271, January 2006. 122 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 123 4272, January 2006. 125 Authors' Addresses 127 John G. Scudder 128 Juniper Networks 130 Email: jgs@juniper.net 132 Kireeti Kompella 133 Juniper Networks 135 Email: kireeti@juniper.net