Network Working Group S. Bellovin
Request for Comments: 4278 AT&T Labs Research
Category: Informational A. Zinin
Alcatel
January 2006
Standards Maturity Variance Regarding the TCP MD5 Signature Option () and the BGP-4 Specification
TCP MD5署名オプション（）及びBGP-4仕様に関して標準成熟差異
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level.
IETF標準化プロセスには、ドキュメントのすべての引用規格は、標準化の同じまたはより高いレベルであることが必要です。 RFC 2026のセクション9.1は、IESGは、IETFの標準慣行に変化を付与することができます。 IESGは、RFC 2385、「TCP MD5署名オプションを使用してBGPセッションの保護」を規範的に参照するBGP-4規格の改訂版のためにそうすることを検討している理由はこの文書では説明しています。 RFC 2385は、提案された標準的なレベルにとどまります。
The IETF Standards Process [RFC2026] requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. Pursuant to that, it is considering publishing the updated BGP-4 specification [RFC4271] as Draft Standard, despite the normative reference to [RFC2385], "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain a Proposed Standard. (Note that although the title of [RFC2385] includes the word "signature", the technology described in it is commonly known as a Message Authentication Code or MAC, and should not be confused with digital signature technologies.)
IETF標準化過程[RFC2026]はドキュメントのすべての引用規格は、標準化の同じまたはより高いレベルであることを必要とします。 RFC 2026のセクション9.1は、IESGは、IETFの標準慣行に変化を付与することができます。それによれば、それは「TCP MD5署名オプションを使用してBGPセッションの保護」[RFC2385]に規定の基準にもかかわらず、標準案として更新BGP-4仕様[RFC4271]を公開検討しています。 RFC 2385は、提案された標準のままになります。 （[RFC2385]のタイトルは、単語「署名」を含むが、それに記載された技術は、一般にメッセージ認証コードまたはMACとして知られており、デジタル署名技術と混同すべきではないこと。注意してください）
[RFC2385], which is widely implemented, is the only transmission security mechanism defined for BGP-4. Other possible mechanisms, such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used
広く実装されている[RFC2385]は、BGP-4について定義された唯一の送信のセキュリティメカニズムです。こうしたこれまで、使用している場合、稀にではないのIPsec [RFC2401]およびTLS [RFC2246]、などの他の可能なメカニズム、
for this purpose. Given the long-standing requirement for security features in protocols, it is not possible to advance BGP-4 without a mandated security mechanism.
この目的のために。プロトコルのセキュリティ機能のための長年の要件を考えると、義務付けセキュリティメカニズムなしでBGP-4を前進させることはできません。
The conflict of maturity levels between specifications would normally be resolved by advancing the specification being referred to along the standards track, to the level of maturity that the referring specification needs to achieve. However, in the particular case considered here, the IESG believes that [RFC2385], though adequate for BGP deployments at this moment, is not strong enough for general use, and thus should not be progressed along the standards track. In this situation, the IESG believes that variance procedure should be used to allow the updated BGP-4 specification to be published as Draft Standard.
仕様の成熟度レベルの競合が通常参照仕様を達成する必要があること成熟のレベルに、標準化トラックに沿って参照される仕様を前進させることによって解決されるであろう。しかし、ここで考え特定のケースでは、IESGは、[RFC2385]と考えて、この時点でのBGPの導入に適していますが、一般的な使用のために十分な強さではないので、標準化トラックに沿って進行するべきではありません。このような状況では、IESGは、分散手順が更新さBGP-4仕様がドラフト規格として公開できるようにするために使用されるべきであると考えています。
The following sections of the document give detailed explanations of the statements above.
文書の次のセクションでは、上記の文の詳細な説明を与えます。
The requirements for Proposed Standards and Draft Standards are given in [RFC2026]. For Proposed Standards, [RFC2026] warns that:
提案された標準とドラフト規格の要件は、[RFC2026]に記載されています。提案された標準の場合は、[RFC2026]はその警告しています：
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to
gain experience and to validate, test, and clarify the
specification. However, since the content of Proposed Standards
may be changed if problems are found or better solutions are
identified, deploying implementations of such standards into a
disruption-sensitive environment is not recommended.
In other words, it is considered reasonable for flaws to be discovered in Proposed Standards.
換言すれば、提案された標準に発見された欠陥のために合理的と考えられています。
The requirements for Draft Standards are higher:
ドラフト規格の要件は高くなっています。
A Draft Standard must be well-understood and known to be quite
stable, both in its semantics and as a basis for developing an
implementation.
In other words, any document that has known deficiencies should not be promoted to Draft Standard.
言い換えれば、欠陥を知っていたすべての文書には、標準のドラフトに昇格するべきではありません。
[RFC2385], despite its 1998 publication date, describes a Message Authentication Code (MAC) that is considerably older. It utilizes a technique known as a "keyed hash function", using MD5 [RFC1321] as the hash function. When the original code was developed, this was believed to be a reasonable technique, especially if the key was appended (rather than prepended) to the data being protected. But cryptographic hash functions were never intended for use as MACs, and later cryptanalytic results showed that the construct was not as strong as originally believed [PV1, PV2]. Worse yet, the underlying hash function, MD5, has shown signs of weakness [Dobbertin, Wang]. Accordingly, the IETF community has adopted Hashed Message Authentication Code (HMAC) [RFC2104], a scheme with provable security properties, as its standard MAC.
[RFC2385]は、1998年の公開日にもかかわらず、かなり古いメッセージ認証コード（MAC）を記述する。これは、ハッシュ関数として、MD5 [RFC1321]を使用して、「鍵付きハッシュ関数」として知られている技術を利用します。元のコードを開発したときに、これは、キーが保護されたデータに（というよりプリペンド）添付された場合は特に、合理的な手法であると考えられました。しかし、暗号学的ハッシュ関数は、MACのように使用することを意図していない、と後に暗号解読の結果は、構築物は、もともと[PV1、PV2]信じほど強くなかったことを示したんでした。さらに悪いことに、基礎となるハッシュ関数MD5は、弱[Dobbertin、王]の兆候を示しています。したがって、IETFコミュニティは、その標準MACとして、ハッシュメッセージ認証コード（HMAC）[RFC2104]、証明可能なセキュリティ特性を有する方式を採用しました。
Beyond that, [RFC2385] does not include any sort of key management technique. Common practice is to use a password as a shared secret between pairs of sites, but this is not a good idea [RFC3562].
それ以上に、[RFC2385]は鍵管理技術の任意の並べ替えが含まれていません。一般的な慣行は、サイトのペア間の共有秘密としてパスワードを使用することですが、これは良いアイデア[RFC3562]ではありません。
Other problems are documented in [RFC2385] itself, including the lack of a type code or version number, and the inability of systems using this scheme to accept certain TCP resets.
他の問題は、タイプコードまたはバージョン番号の欠如、および特定のTCPリセットを受け入れるように、この方式を使用するシステムのできないことを含む、それ自体[RFC2385]に記載されています。
Despite the widespread deployment of [RFC2385] in BGP deployments, the IESG has thus concluded that it is not appropriate for use in other contexts. [RFC2385] is not suitable for advancement to Draft Standard.
BGP展開で[RFC2385]の広範な展開にもかかわらず、IESGは、このように、それは他のコンテキストでの使用のために適切ではないと結論づけました。 [RFC2385]は標準を起草する進歩には適していません。
Given the above analysis, it is reasonable to ask why [RFC2385] is still used for BGP. The answer lies in the deployment patterns peculiar to BGP.
上記の分析を考えると、[RFC2385]は、まだBGPのために使用されている理由を尋ねるのが妥当です。答えは、BGPに特有の展開パターンです。
BGP connections inherently tend to travel over short paths. Indeed, most external BGP links are one hop. Although internal BGP sessions are usually multi-hop, the links involved are generally inhabited only by routers rather than general-purpose computers; general-purpose computers are easier for attackers to use as TCP hijacking tools [Joncheray].
BGP接続は、本質的に短いパス上を移動する傾向があります。実際、ほとんどの外部BGPリンクは1つのホップです。内部BGPセッションは通常、マルチホップですが、関連するリンクは、一般的にルータだけではなく、汎用コンピュータが生息しています。汎用コンピュータは、攻撃者がTCP乗っ取りツール[Joncheray]として使用するのが簡単です。
Also, BGP peering associations tend to be long-lived and static. By contrast, many other security situations are more dynamic.
また、BGPピアリングの関連付けは長寿命と静的になる傾向があります。これとは対照的に、他の多くのセキュリティ状況はよりダイナミックです。
This is not to say that such attacks cannot happen. (If they couldn't happen at all, there would be no point to any security measures.) Attackers could divert links at layers 1 or 2, or they could (in some situations) use Address Resolution Protocol (ARP) spoofing at Ethernet-based exchange points. Still, on balance, BGP is employed in an environment that is less susceptible to this sort of attack.
これは、このような攻撃が起こることができないと言っているわけではありません。 （彼らは全く起こらなかった場合は、任意のセキュリティ対策へのポイントはないだろう。）攻撃者は、レイヤ1または2にあるリンクをそらすことができ、またはそれらは（いくつかの状況で）Ethernet-でアドレス解決プロトコル（ARP）スプーフィングを使用することができますベースの交換ポイント。それでも、バランスの上に、BGPは、この種の攻撃を受けにくい環境で使用されます。
There is another class of attack against which BGP is extremely vulnerable: false route advertisements from more than one autonomous system (AS) hop away. However, neither [RFC2385] nor any other transmission security mechanism can block such attacks. Rather, a scheme such as S-BGP [Kent] would be needed.
複数の自律システム（AS）離れホップから偽のルート通知：BGPは非常に脆弱であるに対して、攻撃の別のクラスがあります。しかし、どちらも[RFC2385]や他の伝送のセキュリティ・メカニズムは、そのような攻撃をブロックすることができます。むしろ、そのようなS-BGP [ケント]などの方式が必要とされるであろう。
The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385]. Deployment practices for LDP are very similar to those of BGP: LDP connections are usually confined within a single autonomous system and most frequently span a single link between two routers. This makes the LDP threat environment very similar to BGP's. Given this, and a considerable installed base of LDP in service provider networks, we are not deprecating [RFC2385] for use with LDP.
ラベル配布プロトコル（LDP）[RFC3036]も[RFC2385]を使用しています。自民党の展開プラクティスはBGPのものと非常に似ています：LDPの接続は、通常、単一の自律システム内に限定し、最も頻繁に2つのルータ間の単一のリンクをまたがっています。これは、BGPのに非常によく似LDPの脅威環境を作ります。この、およびサービスプロバイダーネットワークでの自民党のかなりのインストールベースを考えると、我々はLDPで使用するために[RFC2385]を卑下されていません。
The IESG believes that the variance described here will not adversely affect the security of the Internet.
IESGは、ここで説明した分散が悪影響インターネットのセキュリティに影響を与えないと考えています。
Given the above analysis, the IESG is persuaded that waiving the prerequisite requirement is the appropriate thing to do. [RFC2385] is clearly not suitable for Draft Standard. Other existing mechanisms, such as IPsec, would do its job better. However, given the current operational practices in service provider networks at the moment -- and in particular the common use of long-lived standard keys, [RFC3562] notwithstanding -- the marginal benefit of such schemes in this situation would be low, and not worth the transition effort. We would prefer to wait for a security mechanism tailored to the major threat environment for BGP.
上記の分析を考えると、IESGは、前提条件を放棄することは行うには適切なものであることを説得しています。 [RFC2385]は明らかドラフト標準には適していません。 IPsecなどの他の既存のメカニズムは、その仕事が良いだろう。しかし、現時点ではサービスプロバイダーネットワークでの現在の運用実務を与えられた - 特に長寿命の標準キーの一般的な用途は、[RFC3562]にもかかわらず - このような状況では、このような制度の限界便益が低いこと、およびないでしょう遷移努力する価値。私たちは、BGPのための主要な脅威環境に合わせたセキュリティ・メカニズムを待つことを好むだろう。
[Dobbertin] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
[Dobbertin] H. Dobbertin、 "最近の攻撃の後MD5の状況"、RSA LabsのCryptoBytes、巻。 2第2号、夏1996。
[Joncheray] Joncheray, L. "A Simple Active Attack Against TCP." Proceedings of the Fifth Usenix Unix Security Symposium, 1995.
[Joncheray] Joncheray、L. "TCPに対する単純な積極的な攻撃。"第五のUsenix Unixのセキュリティシンポジウム、1995年の議事。
[Kent] Kent, S., C. Lynn, and K. Seo. "Secure Border Gateway Protocol (Secure-BGP)." IEEE Journal on Selected Areas in Communications, vol. 18, no. 4, April, 2000, pp. 582-592.
[ケント]ケント、S.、C.リン、およびK.ソ。 「ボーダーゲートウェイプロトコル（セキュア-BGP）を固定します。」コミュニケーション、巻で選択された領域に関するIEEEジャーナル。 18、ありません。 4、2000年4月、頁582から592まで。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]リーチ、M.、 "TCP MD5署名オプションのためのキー管理の考慮事項"、RFC 3562、2003年7月。
[PV1] B. Preneel and P. van Oorschot, "MD-x MAC and building
fast MACs from hash functions," Advances in Cryptology
--- Crypto 95 Proceedings, Lecture Notes in Computer
Science Vol. 963, D. Coppersmith, ed., Springer-Verlag,
1995.
[PV2] B. Preneel and P. van Oorschot, "On the security of two
MAC algorithms," Advances in Cryptology --- Eurocrypt 96
Proceedings, Lecture Notes in Computer Science, U.
Maurer, ed., Springer-Verlag, 1996.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[Wang] Wang, X. and H. Yu, "How to Break MD5 and Other Hash Functions." Proceedings of Eurocrypt '05, 2005.
[王]王、X.およびH.ユー、「どのようにMD5および他のハッシュ関数を破ります。」 EUROCRYPT '05、2005年の議事。
Authors' Addresses
著者のアドレス
Steven M. Bellovin Department of Computer Science Columbia University 1214 Amsterdam Avenue, M.C. 0401 New York, NY 10027-7003
コンピュータサイエンスコロンビア大学のスティーブン・M・ベロビン部門1214アムステルダムアベニュー、M.C。 0401ニューヨーク、NY 10027から7003
Phone: +1 212-939-7149 EMail: bellovin@acm.org
電話：+1 212-939-7149電子メール：bellovin@acm.org
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
アレックスジニンアルカテル701 EミドルRdのマウンテンビュー、CA 94043
EMail: zinin@psg.com
メールアドレス：zinin@psg.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。