RFC 7447

RFC 7447: Deprecation of BGP Entropy Label Capability Attribute 🦋

okay bestie, let's get into it 💖 This one is by John G. Scudder and Kireeti Kompella, both at Juniper Networks. It's a Standards Track document from February 2015 🌸 with ISSN 2070-1721. It updates RFC 6790 (the title block says Updates: 6790), and it doesn't list anything it obsoletes. The whole vibe is "we need to retire a feature that doesn't work the way it was supposed to" 💅

Abstract ✨

The BGP Entropy Label Capability attribute is defined in RFC 6790. Sadly, it has a bug 😭 RFC 6790 says that routers that can't process Entropy Labels must remove the attribute, but in practice nobody can guarantee that actually happens. So this spec deprecates the attribute 🫶 A future document will propose a replacement.

Status of This Memo 🌈

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 💜

For info on the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7447.

Copyright Notice 💜

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
2.  Deprecation of ELCA . . . . . . . . . . . . . . . . . . . . .   2
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   3
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .   3
  5.2.  Informative References  . . . . . . . . . . . . . . . . .   3
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   4
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

1. Introduction ✨

okay so [RFC6790] defines the Entropy Label Capability attribute (ELCA), which is an optional, transitive BGP path attribute 🦋 For things to work right, an intermediate node that changes the next hop of a route must remove the ELCA, unless that node can process entropy labels. The problem is this requirement can't be met with the ELCA as it's specified, because it's optional and transitive. By definition, a node that doesn't support the ELCA will just pass the attribute along (that's a general property of optional, transitive attributes; see [RFC4271]). But that ELCA-oblivious node is probably not able to process entropy labels, and it's exactly the node we want to strip the attribute! 😭💀

This specification updates RFC 6790 by deprecating the version of ELCA defined in Section 5.2 of that document. A future document will propose a replacement. Every other section of RFC 6790 is unchanged 🌸

1.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Deprecation of ELCA 💅

This document deprecates the ELCA path attribute, which means implementations MUST NOT generate the attribute. If one is received, the attribute MUST be treated as any other unrecognized optional, transitive attribute as per [RFC4271], until and unless the code point gets reused by some new specification. (To the authors' best knowledge, there are no implementations of ELCA at the time of writing 🙈)

3. IANA Considerations 🍓

For the reasons given in Section 1, IANA has marked attribute 28 "BGP Entropy Label Capability Attribute" in the "BGP Path Attributes" registry as "deprecated" and has added a reference to this RFC ✨

4. Security Considerations 💀

Okay, this section is serious, so buckle up 😭 ELCA, as defined in Section 5.2 of [RFC6790], shares a property with other optional, transitive path attributes: it will be "tunneled" through intervening routers that don't implement the relevant specification. Unfortunately, as discussed elsewhere in this document, implementations of ELCA that receive these "tunneled" attributes could -- sometimes improperly -- rely on them. The consequence could be a black hole in the forwarding path for the affected routes. Whether or not this counts as a new security issue is kind of debatable, because an attacker would have to be part of the control-plane path for the route in question to exploit it. In that situation, the attacker already has a whole panoply of mischief-making tools available, as discussed in [RFC4272] 🙈

In any case, this document makes any real or imagined security issues with ELCA moot by deprecating it 🔥👑

5. References 🌸

5.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
           L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
           RFC 6790, November 2012,
           <http://www.rfc-editor.org/info/rfc6790>.

5.2. Informative References

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
           2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
           4272, January 2006,
           <http://www.rfc-editor.org/info/rfc4272>.

Acknowledgements 🫶

Thanks to Alia Atlas, Bruno Decraene, Martin Djernaes, John Drake, Adrian Farrel, Keyur Patel, Ravi Singh, and Kevin Wang for their discussion of this issue 💜

Authors' Addresses 🧚

John G. Scudder
Juniper Networks

EMail: jgs@juniper.net


Kireeti Kompella
Juniper Networks

EMail: kireeti@juniper.net