[要約] RFC 7447は、BGPエントロピー・ラベル・キャパビリティ属性の廃止に関するものであり、その目的は、この属性の使用を停止し、BGPプロトコルの簡素化と効率化を図ることです。

Internet Engineering Task Force (IETF)                        J. Scudder
Request for Comments: 7447                                   K. Kompella
Updates: 6790                                           Juniper Networks
Category: Standards Track                                  February 2015
ISSN: 2070-1721
        

Deprecation of BGP Entropy Label Capability Attribute

BGPエントロピーラベル機能属性の廃止

Abstract

概要

The BGP Entropy Label Capability attribute is defined in RFC 6790. Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice. This specification deprecates the attribute. A forthcoming document will propose a replacement.

BGPエントロピーラベル機能属性はRFC 6790で定義されています。残念ながら、これにはバグがあります。RFC6790では、エントロピーラベルを処理できないルーターは属性を削除する必要があると規定されていますが、この要件の実現は実際には保証されません。この仕様は属性を廃止します。近々発行される文書で代替品を提案します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7447.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、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.

Copyright(c)2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
1. はじめに

[RFC6790] defines the Entropy Label Capability attribute (ELCA), an optional, transitive BGP path attribute. For correct operation, an intermediate node modifying the next hop of a route must remove the ELCA unless the node doing so is able to process entropy labels. Sadly, this requirement cannot be fulfilled with the ELCA as specified, because it is an optional, transitive attribute. By definition, a node that does not support the ELCA will propagate the attribute (this is a general property of optional, transitive attributes; see [RFC4271]). But such an ELCA-oblivious node is likely to be incapable of processing entropy labels and is exactly the node that we desire to remove the attribute!

[RFC6790]は、オプションの推移的なBGPパス属性であるエントロピーラベル機能属性(ELCA)を定義します。正しい動作のために、ルートのネクストホップを変更する中間ノードは、ノードがエントロピーラベルを処理できる場合を除き、ELCAを削除する必要があります。残念ながら、この要件はELCAで指定されたとおりに満たすことができません。これは、オプションの推移的な属性であるためです。定義により、ELCAをサポートしないノードは属性を伝播します(これはオプションの推移的な属性の一般的なプロパティです。[RFC4271]を参照してください)。しかし、そのようなELCAに気付かないノードは、エントロピーラベルを処理できない可能性が高く、まさに属性を削除したいノードです!

This specification updates RFC 6790 by deprecating the version of ELCA defined in Section 5.2 of that document. A forthcoming document will propose a replacement. All other sections of RFC 6790 are unchanged.

この仕様は、そのドキュメントのセクション5.2で定義されているELCAのバージョンを廃止することにより、RFC 6790を更新します。近々発行される文書で代替品を提案します。 RFC 6790の他のすべてのセクションは変更されていません。

1.1. Requirements Language
1.1. 要件言語

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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. Deprecation of ELCA
2. ELCAの廃止

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

このドキュメントでは、ELCAパス属性を廃止します。これは、実装が属性を生成してはならないことを意味します。受け取った場合、コードポイントが新しい仕様で再利用されるまで、[RFC4271]に従って、属性は他の認識されないオプションの推移的な属性として扱われなければなりません(MUST)。 (執筆者の知る限り、執筆時点ではELCAの実装はありません。)

3. IANA Considerations
3. IANAに関する考慮事項

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.

セクション1の理由により、IANAは「BGPパス属性」レジストリの属性28「​​BGPエントロピーラベル機能属性」を「非推奨」としてマークし、このRFCへの参照を追加しました。

4. Security Considerations
4. セキュリティに関する考慮事項

ELCA, as defined in Section 5.2 of [RFC6790], has in common with other optional, transitive path attributes the property that 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 such "tunneled" attributes could -- sometimes improperly -- rely on them. The consequence of doing so could be a black hole in the forwarding path for the affected routes. Whether or not this is a new security issue is somewhat debatable, since an attacker would have to be part of the control-plane path for the route in question in order for the attacker to exploit the issue. Under those circumstances, an attacker already has a panoply of mischief-making tools available, as discussed in [RFC4272].

[RFC6790]のセクション5.2で定義されているELCAは、他のオプションの推移的なパス属性と共通して、関連する仕様を実装していないルーターを介して「トンネリング」されるプロパティを持っています。残念ながら、このドキュメントの他の場所で説明されているように、そのような「トンネリングされた」属性を受け取るELCAの実装は、時には不適切に、それらに依存する可能性があります。これを行うと、影響を受けるルートの転送パスにブラックホールが生じる可能性があります。攻撃者が問題を悪用するには、問題のルートのコントロールプレーンパスに攻撃者が参加する必要があるため、これが新しいセキュリティ問題であるかどうかはある程度議論の余地があります。これらの状況下では、[RFC4272]で説明されているように、攻撃者はすでにいたずら作成ツールを利用できます。

In any case, this document renders any real or imagined security issues with ELCA moot, by deprecating it.

いずれにせよ、このドキュメントでは、ELCAの非推奨事項を非推奨にすることで、実際または想定されるセキュリティの問題を提示しています。

5. References
5. 参考文献
5.1. Normative References
5.1. 引用文献

[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>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<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>.

[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
5.2. 参考引用

[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>.

[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4(BGP-4)」、RFC 4271、2006年1月、<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>.

[RFC4272] Murphy、S。、「BGP Security Vulnerabilities Analysis」、RFC 4272、2006年1月、<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.

この問題について話し合ったAlia Atlas、Bruno Decraene、Martin Djernaes、John Drake、Adrian Farrel、Keyur Patel、Ravi Singh、Kevin Wangに感謝します。

Authors' Addresses

著者のアドレス

John G. Scudder Juniper Networks

John G. Scudder Juniper Networks

   EMail: jgs@juniper.net
        

Kireeti Kompella Juniper Networks

キリーティコンペラジュニパーネットワークス

   EMail: kireeti@juniper.net