RFC4278 日本語訳

Network Working Group                                        S. Bellovin
Request for Comments: 4278                            AT&T Labs Research
Category: Informational                                         A. Zinin
                                                                 Alcatel
                                                            January 2006

Bellovinがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4278のAT&T研究室がカテゴリについて研究します: 情報のA.ジニンアルカテル2006年1月

  Standards Maturity Variance Regarding the TCP MD5 Signature Option
                 (RFC 2385) and the BGP-4 Specification

TCP MD5署名オプション(RFC2385)と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)インターネット協会(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 Standards Processは、ドキュメントに関するすべての引用規格が同じであるか、より高いレベルの標準化でそうであることを必要とします。 RFC2026部9.1で、IESGはIETFの標準的技法に変化を与えることができます。 IESGが、なぜBGP-4仕様の改訂版のためにそうすると考えているかがこのドキュメントでわかります。RFC2385、「TCP MD5 Signature Optionを通したBGPセッションズの保護」について仕様は標準に言及します。 RFC2385はProposed Standardレベルに残るでしょう。

1.  Introduction

1. 序論

   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 Standards Process[RFC2026]は、ドキュメントに関するすべての引用規格が同じであるか、より高いレベルの標準化でそうであることを必要とします。 RFC2026部9.1で、IESGはIETFの標準的技法に変化を与えることができます。 それによると、Draft StandardとしてアップデートされたBGP-4仕様[RFC4271]を発表すると考えています、[RFC2385]の引用規格、「TCP MD5 Signature Optionを通したBGPセッションズの保護」にもかかわらず。 RFC2385はProposed Standardのままで残るでしょう。 (それで説明された技術が[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]はめったに使用されていません。

Bellovin & Zinin             Informational                      [Page 1]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006

Bellovinとジニン情報[1ページ]のRFC4278規格円熟変化: RFC2385とBGP-2006年1月4日

   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仕様がDraft Standardとして発表されるのを許容するのに用いられるべきであると信じています。

   The following sections of the document give detailed explanations of
   the statements above.

ドキュメントの以下のセクションは上の声明の詳説を与えます。

2.  Draft Standard Requirements

2. 標準の要件を作成してください。

   The requirements for Proposed Standards and Draft Standards are given
   in [RFC2026].  For Proposed Standards, [RFC2026] warns that:

[RFC2026]でProposed StandardsとDraft Standardsのための要件を与えます。 Proposed Standardsに関しては、[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.

作成者は未熟な仕様としてProposed Standardsを扱うべきです。 仕様を経験を積むためにそれらを実装して、有効にして、テストして、はっきりさせるのは望ましいです。 しかしながら、問題を見つけるならProposed Standardsの内容を変えるかもしれないか、または、より良いソリューションを特定するので、そのような規格の実装を混乱しやすい環境に配布するのは推薦されません。

   In other words, it is considered reasonable for flaws to be
   discovered in Proposed Standards.

言い換えれば、それは欠点がProposed Standardsで発見されるのが妥当であると考えられます。

   The requirements for Draft Standards are higher:

Draft Standardsのための要件は、より高いです:

        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.

意味論と実装を開発する基礎としてよく理解していなければならなくて、かなり安定しているのが知られているDraft Standard。

   In other words, any document that has known deficiencies should not
   be promoted to Draft Standard.

言い換えれば、欠乏を知っていたどんなドキュメントもDraft Standardに促進するべきではありません。

Bellovin & Zinin             Informational                      [Page 2]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006

Bellovinとジニン情報[2ページ]のRFC4278規格円熟変化: RFC2385とBGP-2006年1月4日

3.  The TCP MD5 Signature Option

3. TCP MD5署名オプション

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

1998年の公表日付にもかかわらず、[RFC2385]はかなり古いメッセージ立証コード(MAC)について説明します。 それはハッシュ関数としてMD5[RFC1321]を使用して、「合わせられたハッシュ関数」として知られているテクニックを利用します。 元のコードが開発されたとき、これは合理的なテクニックであると信じられていました、特に保護されるデータにキーを追加したなら(prependedされているよりむしろ)。 しかし、構造物が元々信じられているほど[PV1、PV2]強くなかったというMACs、および後のcryptanalytic結果が目立ったように暗号のハッシュ関数は使用のために決して意図しませんでした。 まだより悪くて、基本的なハッシュ関数(MD5)は弱点[Dobbertin、ワング]の兆候を示しました。 それに従って、IETF共同体はHashedメッセージ立証コード(HMAC)[RFC2104]を採用しました、証明可能なセキュリティの特性がある体系、標準のMACとして。

   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]はDraft Standardへの前進に適していません。

4.  Usage Patterns for RFC 2385

4. 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リンクがワンバウンドです。 内部の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

これは、そのような攻撃が起こることができないと言わないためのものです。 (全く起こることができないなら、どんな安全策へのポイントも全くないでしょうに。) 攻撃者が層1か2にリンクを紛らすことができた、それら

Bellovin & Zinin             Informational                      [Page 3]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006

Bellovinとジニン情報[3ページ]のRFC4278規格円熟変化: RFC2385とBGP-2006年1月4日

   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.

イーサネットベースの交換ポイントでだましながら、Address Resolutionプロトコル(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が非常に被害を受け易いもう1人のクラスの攻撃があります: 1つ以上の自律システム(AS)からの誤ったルート広告は遠くを跳びます。 しかしながら、[RFC2385]もいかなる他のトランスミッションセキュリティー対策もそのような攻撃を妨げることができません。 むしろ、S-BGP[ケント]などの体系が必要でしょう。

5.  LDP

5. 自由民主党

   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.

また、Label Distributionプロトコル(自由民主党)[RFC3036]は[RFC2385]を使用します。 自由民主党のための展開練習はBGPのものと非常に同様です: 自由民主党の接続は、通常、単一の自律システムの中に閉じ込められて、最も頻繁に2つのルータの間の単一のリンクにかかっています。 これで、自由民主党脅威環境はBGPのものと非常に同様になります。 これ、およびサービスプロバイダーネットワークにおける自由民主党の多量のインストールされたベースを考えて、私たちは自由民主党との使用のために[RFC2385]を非難していません。

6.  Security Considerations

6. セキュリティ問題

   The IESG believes that the variance described here will not adversely
   affect the security of the Internet.

IESGは、ここで説明された変化がインターネットのセキュリティに悪影響を与えないと信じています。

7.  Conclusions

7. 結論

   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]は明確にDraft Standardに適当ではありません。 IPsecなどの他の既存のメカニズムは仕事を良くするでしょう。 --現在、サービスプロバイダーネットワークの現在の操作上の習慣、および特に[RFC3562]にもかかわらず、長命の標準のキーの一般の使用を考えて、しかしながら、この状況における、そのような体系のマージンの利益は、低くて、変遷取り組みの価値がないでしょう。 私たちは、BGPのために大きな脅威環境に適合したセキュリティー対策を待つのを好むでしょう。

8.  Informative References

8. 有益な参照

   [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研究室のCryptoBytes、Vol.2No.2、1996年夏。

   [Joncheray]  Joncheray, L.  "A Simple Active Attack Against TCP."
                Proceedings of the Fifth Usenix Unix Security Symposium,
                1995.

L. [Joncheray]Joncheray、「TCPに対する簡単な活発な攻撃。」 第5Usenix unixセキュリティシンポジウム、1995年の議事。

Bellovin & Zinin             Informational                      [Page 4]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006

Bellovinとジニン情報[4ページ]のRFC4278規格円熟変化: RFC2385とBGP-2006年1月4日

   [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.Seo。 「ボーダ・ゲイトウェイ・プロトコル(安全なBGP)を保証してください。」 Communications、vol.18、No.4、2000年4月、ページのSelected Areasの上のIEEE Journal 582-592.

   [RFC3562]    Leech, M., "Key Management Considerations for the TCP
                MD5 Signature Option", RFC 3562, July 2003.

[RFC3562] ヒル、M.、「TCP MD5署名オプションのためのKey Management問題」、RFC3562、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.はOorschot、「MD-x MAC、ハッシュ関数から速いMACsを造ること」をバンに積んで、中のAdvancesはCryptologyです。--- 暗号95Proceedings、コンピュータScience Vol.963におけるLecture Notes、D.Coppersmith、教育、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.バンOorschot、「2つのMACアルゴリズムのセキュリティ」、CryptologyのAdvances--- Eurocrypt96Proceedings、コンピュータScienceのLecture Notes、U.モウラー、教育、Springer-Verlag、1996

   [RFC1321]    Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
                1321, April 1992.

[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。

   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
                3", BCP 9, RFC 2026, October 1996.

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。

   [RFC2246]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
                RFC 2246, January 1999.

[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [RFC2385]    Heffernan, A., "Protection of BGP Sessions via the TCP
                MD5 Signature Option", RFC 2385, August 1998.

[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。

   [RFC2401]    Kent, S. and R. Atkinson, "Security Architecture for the
                Internet Protocol", RFC 2401, November 1998.

[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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.トーマス、「自由民主党仕様」、RFC3036、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.野兎、Eds、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271、1月2006日

   [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'の議事。

Bellovin & Zinin             Informational                      [Page 5]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006

Bellovinとジニン情報[5ページ]のRFC4278規格円熟変化: RFC2385とBGP-2006年1月4日

Authors' Addresses

作者のアドレス

   Steven M. Bellovin
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, M.C. 0401
   New York, NY 10027-7003

スティーブンM.Bellovinコンピュータサイエンス学部Columbia University1214アムステルダムアベニュー、ニューヨーク、M.C.0401ニューヨーク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

アレックスジニンアルカテル701E Middlefield第マウンテンビュー、カリフォルニア 94043

   EMail: zinin@psg.com

メール: zinin@psg.com

Bellovin & Zinin             Informational                      [Page 6]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006

Bellovinとジニン情報[6ページ]のRFC4278規格円熟変化: RFC2385とBGP-2006年1月4日

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Bellovin & Zinin             Informational                      [Page 7]

BellovinとジニンInformationalです。[7ページ]