[要約] 要約：RFC 4278は、TCP MD5 Signature Option（RFC 2385）とBGP-4仕様の標準成熟度の違いに関する情報を提供しています。 目的：このRFCの目的は、TCP MD5 Signature OptionとBGP-4仕様の関係を明確にし、実装者が適切なセキュリティ対策を行うためのガイダンスを提供することです。
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 (RFC 2385) and the BGP-4 Specification
TCP MD5署名オプション（RFC 2385）および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).
Copyright（c）The Internet Society（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がBGP-4仕様の改訂版に対してそうすることを検討している理由を説明します。これは、RFC 2385、「TCP MD5署名オプションを介したBGPセッションの保護」を指します。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の標準プラクティスに差異を付与できます。それに従って、[RFC2385]、「TCP MD5署名オプションを介したBGPセッションの保護」への規範的言及にもかかわらず、更新された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 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.
[RFC2385]は、広く実装されており、BGP-4に対して定義された唯一の伝送セキュリティメカニズムです。IPSEC [RFC2401]やTLS [RFC2246]などの他の可能なメカニズムは、この目的に使用されることはめったにありません。プロトコルのセキュリティ機能の長年の要件を考えると、義務付けられたセキュリティメカニズムなしに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、Wang]。したがって、IETFコミュニティは、標準MACとして、証明可能なセキュリティプロパティを備えたスキームであるHashed Message Authentication Code（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.
他の問題は、[RFC2385]自体に文書化されています。これには、タイプコードまたはバージョン番号の欠如や、このスキームを使用して特定のTCPリセットを受け入れることができないことが含まれます。
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でリンクをそらすことができます。または、（状況によっては）イーサネットベースの交換ポイントでアドレス解像度プロトコル（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.
BGPが非常に脆弱な別のクラスの攻撃があります。複数の自律システム（AS）が飛び去った誤ったルート広告。ただし、[RFC2385]も他の伝送セキュリティメカニズムも、そのような攻撃をブロックすることはできません。むしろ、S-BGP [Kent]などのスキームが必要です。
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]を使用しています。LDPの展開プラクティスはBGPの展開と非常に似ています。LDP接続は通常、単一の自律システム内に限定され、最も頻繁に2つのルーター間の単一のリンクに及びます。これにより、LDPの脅威環境は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、vol。2 No. 2、1996年夏。
[Joncheray] Joncheray, L. "A Simple Active Attack Against TCP." Proceedings of the Fifth Usenix Unix Security Symposium, 1995.
[Joncheray] Joncheray、L。「TCPに対する簡単なアクティブな攻撃」。第5回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.
[Kent] Kent、S.、C。Lynn、およびK. Seo。「セキュアボーダーゲートウェイプロトコル（Secure-BGP）。」Communicationsの選択された領域に関するIEEEジャーナル、Vol。18、いいえ。4、2000年4月、582-592ページ。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech、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.
[Pv1] B. PreneelおよびP. Van Oorschot、「MD-X MACおよびハッシュ関数からの高速MACの構築」、Cryptogyの進歩--- Crypto 95 Proceedings、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.
[PV2] B. PreneelおよびP. Van Oorschot、「2つのMACアルゴリズムのセキュリティについて」、暗号化の進歩---ユーロクライプ96手続き、コンピューターサイエンスの講義ノート、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] Bradner、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.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「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.、Li、T。、およびS. Hares、eds。、「A Border Gateway Protocol 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.
[Wang] Wang、X。およびH. Yu、「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ニューヨーク、ニューヨーク10027-7003
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
アレックス・ジニン・アルカテル701 E Middlefield Rd Mountain View、CA 94043
EMail: zinin@psg.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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）によって提供されます。