idnits 2.17.1 draft-ietf-mpls-deprecate-bgp-entropy-label-02.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 date (December 12, 2014) is 3423 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 (~~), 1 warning (==), 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 December 12, 2014 6 Expires: June 15, 2015 8 Deprecation of BGP Entropy Label Capability Attribute 9 draft-ietf-mpls-deprecate-bgp-entropy-label-02 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 June 15, 2015. 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. All other sections of RFC 6790 are 69 unchanged. 71 1.1. Requirements Language 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 2. Deprecation of ELCA 79 This document deprecates the ELCA path attribute. This means that 80 any implementation MUST NOT generate the attribute. If received it 81 MUST be treated as any other unrecognized optional transitive 82 attribute as per [RFC4271], until and unless the code point is reused 83 by some new specification. (To the authors' best knowledge, there 84 are no implementations of ELCA at the time of writing.) 86 3. IANA Considerations 88 For the reasons given in Section 1, IANA is requested to mark 89 attribute 28 in the "BGP Path Attributes" registry as "deprecated" 90 and reference this RFC. 92 4. Security Considerations 94 ELCA as defined in [RFC6790] S. 5.2, has in common with other 95 optional, transitive path attributes the property that it will be 96 "tunneled" through intervening routers that don't implement the 97 relevant specification. Unfortunately, as discussed elsewhere in 98 this document, implementations of [RFC6790] S. 5.2 receiving such 99 "tunneled" attributes could -- sometimes improperly -- rely on them. 100 The consequence of so doing could be a black hole in the forwarding 101 path for the affected routes. Whether this is a new security issue 102 or not is somewhat debatable, since to be exploited an attacker would 103 have to be part of the control plane path for the route in question, 104 and under those circumstances an attacker already has a panoply of 105 mischief-making tools available, as discussed in [RFC4272]. 107 In any case, this document renders any real or imagined security 108 issues with ELCA moot, by deprecating it. 110 5. Acknowledgements 112 Thanks to Alia Atlas, Bruno Decraene, Martin Djernaes, John Drake, 113 Adrian Farrell, Keyur Patel, Ravi Singh and Kevin Wang for their 114 discussion of this issue. 116 6. References 118 6.1. Normative References 120 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 121 Requirement Levels", BCP 14, RFC 2119, March 1997. 123 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 124 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 125 RFC 6790, November 2012. 127 6.2. Informative References 129 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 130 Protocol 4 (BGP-4)", RFC 4271, January 2006. 132 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 133 4272, January 2006. 135 Authors' Addresses 137 John G. Scudder 138 Juniper Networks 140 Email: jgs@juniper.net 141 Kireeti Kompella 142 Juniper Networks 144 Email: kireeti@juniper.net