RFC4822 日本語訳
4822 RIPv2 Cryptographic Authentication. R. Atkinson, M. Fanto. February 2007. (Format: TXT=53828 bytes) (Obsoletes RFC2082) (Updates RFC2453) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Atkinson Request for Comments: 4822 Extreme Networks Obsoletes: 2082 M. Fanto Updates: 2453 NIST Category: Standards Track February 2007
コメントを求めるワーキンググループR.アトキンソン要求をネットワークでつないでください: 4822の極端なネットワークが以下を時代遅れにします。 2082のM.Fantoアップデート: 2453年のNISTカテゴリ: 標準化過程2007年2月
RIPv2 Cryptographic Authentication
RIPv2の暗号の認証
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
IESG Note
IESG注意
In the interests of encouraging rapid migration away from Keyed-MD5 and its known weakness, the IESG has approved this document even though it does not meet the guidelines in BCP 107 (RFC 4107). However, the IESG stresses that automated key management should be used to establish session keys and urges that the future work on key management described in Section 5.6 of this document should be performed as soon as possible.
Keyed-MD5から遠くの急速な移行とその知られている弱点を奨励することのために、BCP107(RFC4107)のガイドラインを満たしませんが、IESGはこのドキュメントを承認しました。 しかしながら、IESGは、自動化されたかぎ管理がセッションキーを証明するのに使用されるべきであると強調して、このドキュメントのセクション5.6で説明されたかぎ管理への今後の活動ができるだけ早く実行されるべきであるよう促します。
Abstract
要約
This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section.
この注意は元々RFC2082で指定されたRIPv2 Cryptographic Authenticationメカニズムに改正について説明します。 このドキュメントは、RFC2082を時代遅れにして、RFC2453をアップデートします。 このドキュメントはRIPv2 Cryptographic Authenticationと共にハッシュアルゴリズムのSHAファミリーを使用できましたが、正本がどうKeyed-MD5の使用を指定しただけであるかに関する詳細を加えます。 また、このドキュメントは、このメカニズムに対する活発な攻撃で潜在的問題をはっきりさせて、重要なテキストをSecurity Considerations部に追加します。
Atkinson & Fanto Standards Track [Page 1] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[1ページ]RFC4822RIPv2
1. Introduction
1. 序論
Growth in the Internet has made us aware of the need for improved authentication of routing information. RIPv2 provides for unauthenticated service (as in classical RIP), or password authentication. Both are vulnerable to passive attacks currently widespread in the Internet. Well-understood security issues exist in routing protocols [Bell89]. Cleartext passwords, originally specified for use with RIPv2, are widely understood to be vulnerable to easily deployed passive attacks [HA94].
インターネットでの成長で、私たちはルーティング情報の改良された認証の必要性を意識するようになりました。 RIPv2は非認証されたサービス(古典的なRIPのように)、またはパスワード認証に備えます。 両方が現在インターネットで広範囲の受け身の攻撃に被害を受け易いです。 よく理解されている安全保障問題はルーティング・プロトコル[Bell89]で存在しています。 元々RIPv2との使用に指定されたCleartextパスワードが容易に配布している受け身の攻撃[HA94]に被害を受け易いのが広く理解されています。
The original RIPv2 cryptographic authentication specification, RFC 2082 [AB97], used the Keyed-MD5 cryptographic mechanism. While there are no openly published attacks on that mechanism, some reports [Dobb96a, Dobb96b] create concern about the ultimate strength of the MD5 cryptographic hash function. Further, some end users, particularly several different governments, require the use of the SHA hash function family rather than any other such function for policy reasons. Finally, the original specification uses a hashing construction widely believed to be weaker than the HMAC construction used with the algorithms added in this revision of the specification.
当初のRIPv2暗号の認証仕様(RFC2082[AB97])はKeyed-MD5の暗号のメカニズムを使用しました。 そのメカニズムに対するオープンに発行された攻撃が全くない間、いくつかのレポート[Dobb96a、Dobb96b]がMD5の暗号のハッシュ関数の究極のおよそ強さの関心を引き起こします。 さらに、何人かのエンドユーザ(特にいくつかの異なった政府)が方針のためのそのような機能が推論するいかなる他のもむしろSHAハッシュ関数ファミリーの使用を必要とします。 最終的に、正式仕様書はHMAC工事が加えられるアルゴリズムで仕様のこの改正を使用したより弱いと広く信じられている論じ尽くす工事を使用します。
This document obsoletes the original specification, RFC 2082 [AB97]. This specification differs from RFC 2082 by adding support for the SHA family of hash algorithms and the HMAC technique, while retaining the original Keyed-MD5 algorithm and mode. As the original RIPv2 Cryptographic Authentication mechanism was algorithm-independent, backwards compatibility is retained. This requirement for backwards compatibility precludes making significant protocol changes. So, this document limits changes to the addition of support for an additional family of cryptographic algorithms. The original specification has been very widely implemented, is known to be widely interoperable, and is also widely deployed.
このドキュメントは正式仕様書、RFC2082[AB97]を時代遅れにします。 この仕様は、オリジナルのKeyed-MD5アルゴリズムとモードを保有している間、ハッシュアルゴリズムとHMACのテクニックのSHAファミリーのサポートを加えることによって、RFC2082と異なっています。 オリジナルのRIPv2 Cryptographic Authenticationメカニズムがアルゴリズムから後方に独立していたとき、互換性は保有されます。 後方に互換性が、重要なプロトコルを作るのを排除するというこの要件は変化します。 それで、このドキュメントは変化を暗号アルゴリズムの追加ファミリーのサポートの追加に制限します。正式仕様書は、非常に広く履行されて、広く共同利用できるのが知られて、また、広く配布されます。
The authors do NOT believe that this specification is the final answer to RIPv2 authentication and encourage the reader to consult the Security Considerations section of this document for more details.
作者は、この仕様がRIPv2認証の最終的な答えであると信じて、読者がその他の詳細のためのこのドキュメントのSecurity Considerations部に相談するよう奨励しません。
If RIPv2 authentication is disabled, then only simple misconfigurations are detected. The original RIPv2 authentication mechanism relied upon reused cleartext passwords. Use of cleartext password authentication can protect against accidental misconfigurations if that were the only concern, but is not helpful from a security perspective. By simply capturing information on the wire -- straightforward even in a remote environment -- a hostile
RIPv2認証は障害があるなら、簡単なmisconfigurationsだけが検出されます。 当てにされたオリジナルのRIPv2認証機構はcleartextパスワードを再利用しました。 cleartextパスワード認証の使用は、それが唯一の関心であるなら偶然のmisconfigurationsから守ることができますが、セキュリティ見解から役立っていません。 単にリモート環境でさえ簡単なワイヤの情報を得ることによって、a敵対的です。
Atkinson & Fanto Standards Track [Page 2] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[2ページ]RFC4822RIPv2
entity can read the cleartext RIPv2 password and use that knowledge to inject false information into the routing system via the RIPv2 routing protocol.
実体は、RIPv2ルーティング・プロトコルでルーティングシステムに偽情報を注ぐのにcleartext RIPv2パスワードを読んで、その知識を使用できます。
This mechanism is intended to reduce the risk of a successful passive attack upon RIPv2 deployments. That is, deployment of this mechanism greatly reduces the vulnerability of the RIPv2-based routing system from a passive attack. When cryptographic authentication is enabled, we transmit the output of a keyed cryptographic one-way function in the authentication field of the RIPv2 packet, instead of sending a cleartext reusable password in the RIPv2 packet. The RIPv2 Authentication Key is known only to the authorized parties of the RIPv2 session. The RIPv2 Authentication Key is never sent over the network in the clear.
このメカニズムがRIPv2展開に対するうまくいっている受け身の攻撃の危険を減少させることを意図します。 すなわち、このメカニズムの展開は受け身の攻撃からRIPv2ベースのルーティングシステムの脆弱性を大いに減少させます。 暗号の認証が可能にされるとき、私たちはRIPv2パケットの認証分野での合わせられた暗号の一方向関数の出力を伝えます、RIPv2パケットでcleartext再使用可能パスワードを送ることの代わりに。 RIPv2 Authentication Keyは認可されたパーティーだけにおいてRIPv2セッションを知られています。 明確のネットワークの上にRIPv2 Authentication Keyを決して送りません。
In this way, protection is afforded against forgery or message modification. While it is possible to replay a message until the sequence number changes, a sequence number can be used to reduce replay risks. The mechanism does not provide confidentiality, since messages stay in the clear. Since the objective of a routing protocol is to advertise the routing topology, confidentiality is not normally required for routing protocols.
このように、偽造かメッセージ変更に対して保護を提供します。 一連番号が変化するまでメッセージを再演するのが可能である間、再生危険を減少させるのに一連番号を使用できます。 メッセージが明確に残っているので、メカニズムは秘密性を提供しません。 ルーティング・プロトコルの目的がルーティングトポロジーの広告を出すことであるので、通常、秘密性はルーティング・プロトコルに必要ではありません。
Other relevant rationales for the approach are that MD5 and SHA-1 are both being used for other purposes and are therefore generally already present in IP routers, as is some form of password management.
アプローチのための他の関連原理は、MD5とSHA-1が他の目的にともに使用されているということであり、したがって、一般に、IPルータで既に存在しています、何らかの形式のパスワード管理のように。
1.1. Terminology
1.1. 用語
In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [BCP14] and indicate requirement levels for compliant or conformant implementations.
本書では、単語“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTは中で[BCP14]について説明して、言いなりになっているかconformantな実装のために要件レベルを示すとき解釈されることであるべきですか?
2. Implementation Approach
2. 実装アプローチ
Implementation requires use of a special packet format, special authentication procedures, and also management controls. Implementers need to remember that the Security Considerations section is an integral part of this specification and contains important parts of this specification.
実装は特別なパケット・フォーマット、特別な認証手順、およびマネジメント・コントロールのも使用を必要とします。 Implementersは、Security Considerations部がこの仕様の不可欠の部分であり、この仕様の重要な部分を含むのを覚えている必要があります。
Atkinson & Fanto Standards Track [Page 3] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[3ページ]RFC4822RIPv2
2.1. RIPv2 PDU Format
2.1. RIPv2 PDU形式
The basic RIPv2 message format provides for an 8-octet header with an array of 20-octet records as its data content. When RIPv2 Cryptographic Authentication is enabled, the same header and content are used as with the original RIPv2 specification, but the 16-octet "Authentication" password field of the original RIPv2 specification is reused to contain a packet offset to the Authentication Data, a Key Identifier, the Authentication Data Length, and a non-decreasing sequence number.
基本的なRIPv2メッセージ・フォーマットはデータ内容として20八重奏の記録の勢ぞろいで8八重奏のヘッダーに備えます。 RIPv2 Cryptographic Authenticationが有効にされるとき、同じヘッダーと内容は当初のRIPv2仕様のように使用されていますが、当初のRIPv2仕様の16八重奏の「認証」パスワード欄は、Authentication Data、Key Identifier、Authentication Data Length、および非減少している一連番号まで相殺されたパケットを含むように再利用されます。
AUTHENTICATION TYPE
The "Authentication Type" is Cryptographic Hash Function, which
is indicated by the value 3.
AUTHENTICATION TYPE「認証タイプ」はCryptographic Hash Functionです。(そのCryptographic Hash Functionは値3によって示されます)。
RIPv2 PACKET LENGTH
An unsigned 16-bit offset from the start of the RIPv2 header to
the end of the regular RIPv2 packet (not including the
authentication trailer).
RIPv2ヘッダーの始まりからレギュラーのRIPv2パケット(認証トレーラを含んでいない)の端までのRIPv2 PACKET LENGTH Anの未署名の16ビットのオフセット。
KEY IDENTIFIER
An unsigned 8-bit field that contains the Key Identifier or
Key-ID. This, in combination with the network interface,
identifies the RIPv2 Security Association in use for this
packet. The RIPv2 Security Association, which is defined in
Section 2.2 below, includes the Authentication Key that was
used to create the Authentication Data for this RIPv2 message
and other parameters. In implementations supporting more than
one authentication algorithm, the RIPv2 Security Association
also includes information about which authentication algorithm
is in use for this message. A RIPv2 Security Association is
always associated with an interface, rather than with a router.
The actual cryptographic key is part of the RIPv2 Security
Association.
Key IdentifierかKey-IDを含むKEY IDENTIFIER Anの未署名の8ビットの分野。 ネットワーク・インターフェースと組み合わせて、これはこのパケットに、使用中のRIPv2 Security Associationを特定します。 RIPv2 Security Association(以下のセクション2.2で定義される)はこのRIPv2メッセージと他のパラメタのためのAuthentication Dataを作成するのに使用されたAuthentication Keyを含んでいます。 また、1つ以上の認証アルゴリズムをサポートする実装では、RIPv2 Security Associationはこのメッセージに、どの認証アルゴリズムが使用中であるかの情報を含んでいます。 RIPv2 Security Associationはいつもルータでというよりむしろインタフェースに関連しています。 実際の暗号化キーはRIPv2 Security Associationの一部です。
AUTHENTICATION DATA LENGTH
An unsigned 8-bit field that contains the length in octets of
the trailing Authentication Data field. The presence of this
field helps provide cryptographic algorithm independence.
引きずっているAuthentication Data分野の八重奏における長さを含むAUTHENTICATION DATA LENGTH Anの未署名の8ビットの分野。 この分野の存在は、暗号アルゴリズム独立を提供するのを助けます。
AUTHENTICATION DATA
This field contains the cryptographic Authentication Data used
to validate this packet. The length of this field is stored in
the AUTHENTICATION DATA LENGTH field above.
AUTHENTICATION DATA This分野はこのパケットを有効にするのに使用される暗号のAuthentication Dataを含んでいます。 この分野の長さは上にAUTHENTICATION DATA LENGTH分野に保存されます。
Atkinson & Fanto Standards Track [Page 4] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[4ページ]RFC4822RIPv2
SEQUENCE NUMBER
An unsigned 32-bit sequence number. The sequence number MUST
be non-decreasing for all messages sent from a given source
router with a given Key ID value.
SEQUENCE NUMBER Anの未署名の32ビットの一連番号。 一連番号が与えられたKey ID価値に従った与えられたソースルータから送られたすべてのメッセージのための非減少でなければならない。
The authentication trailer contains the Authentication Data, which is the output of the keyed cryptographic hash function. See later subsections of this section for details on computing this field.
認証トレーラはAuthentication Dataを含んでいます。(Authentication Dataは合わせられた暗号のハッシュ関数の出力です)。 この分野を計算して、後で詳細のためのこのセクションの小区分がオンであることを見てください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type=0x0003 |
+---------------+---------------+---------------+---------------+
| RIPv2 Packet Length | Key ID | Auth Data Len |
+---------------+---------------+---------------+---------------+
| Sequence Number (non-decreasing) |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| |
~ (RIPv2 Packet Length - 24) bytes of Data ~
| |
+---------------+---------------+---------------+---------------+
| 0xFFFF | 0x0001 |
+---------------+---------------+---------------+---------------+
| Authentication Data (variable length; 20 bytes with HMAC-SHA1)|
+---------------+---------------+---------------+---------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ | コマンド(1)| バージョン(1)| 経路ドメイン(2)| +---------------+---------------+-------------------------------+ | 0xFFFF| 認証タイプ=0x0003| +---------------+---------------+---------------+---------------+ | RIPv2パケット長| 主要なID| Auth Dataレン| +---------------+---------------+---------------+---------------+ | 一連番号(非減少)| +---------------+---------------+---------------+---------------+ | 予約されているのは、ゼロであるに違いありません。| +---------------+---------------+---------------+---------------+ | 予約されているのは、ゼロであるに違いありません。| +---------------+---------------+---------------+---------------+ | | ~ (RIPv2パケット長--24) バイトのData~| | +---------------+---------------+---------------+---------------+ | 0xFFFF| 0×0001| +---------------+---------------+---------------+---------------+ | 認証Data(可変長; HMAC-SHA1がある20バイト)| +---------------+---------------+---------------+---------------+
2.2. RIPv2 Security Association
2.2. RIPv2セキュリティ協会
Understanding the RIPv2 Security Association concept is central to understanding this specification. A RIPv2 Security Association contains the set of shared authentication configuration parameters needed by the legitimate sender or any legitimate receiver.
RIPv2 Security Association概念を理解しているのはこの仕様を理解しているのに一番重要です。 RIPv2 Security Associationは正統の送付者かどんな正統の受信機によっても必要とされた共有された認証設定パラメータのセットを含んでいます。
An implementation MUST be able to support at least 2 concurrent RIPv2 Security Associations on each RIP interface. This is a functional requirement for supporting key rollover. Support for key rollover is mandatory.
実装はそれぞれのRIPインタフェースの少なくとも2同時発生のRIPv2 Security Associationsをサポートすることができなければなりません。 これは、主要なロールオーバーをサポートするための機能条件書です。主要なロールオーバーのサポートは義務的です。
The RIPv2 Security Association, defined below, is selected by the sender based on the outgoing router interface. Each RIPv2 Security Association has a lifetime and other configuration parameters
以下で定義されたRIPv2 Security Associationは外向的なルータインタフェースに基づく送付者によって選択されます。 各RIPv2 Security Associationには、生涯、他の設定パラメータがあります。
Atkinson & Fanto Standards Track [Page 5] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[5ページ]RFC4822RIPv2
associated with it. In normal operation, a RIPv2 Security Association is never used outside its lifetime. Certain abnormal cases are discussed later in this document.
それに関連しています。 通常の操作では、RIPv2 Security Associationは生涯、決して使用されません。 後で本書ではある異常なケースについて議論します。
The minimum data items in a RIPv2 Security Association are as follows:
RIPv2 Security Associationの最小のデータ項目は以下の通りです:
KEY-IDENTIFIER (KEY-ID)
The unsigned 8-bit KEY-ID value is used to identify the RIPv2
Security Association in use for this packet.
未署名の8ビットのKEY-IDがこのパケットに、使用中のRIPv2 Security Associationを特定するのに使用されるのを評価するKEY-IDENTIFIER(KEY-ID)。
The receiver uses the combination of the interface the packet
was received upon and the KEY-ID value to uniquely identify the
appropriate Security Association.
受信機は、唯一適切なSecurity Associationを特定するのにパケットが受け取られたインタフェースとKEY-ID価値の組み合わせを使用します。
The sender selects which RIPv2 Security Association to use
based on the outbound interface for this RIPv2 packet and then
places the correct KEY-ID value into that packet. If multiple
valid and active RIPv2 Security Associations exist for a given
outbound interface at the time a RIPv2 packet is sent, the
sender may use any of those security associations to protect
the packet.
送付者は、このRIPv2パケットのために外国行きのインタフェースに基づいてどのRIPv2 Security Associationを使用したらよいかを選択して、次に、正しいKEY-ID値をそのパケットに置きます。 RIPv2パケットを送るとき複数の有効でアクティブなRIPv2 Security Associationsが与えられた外国行きのインタフェースに存在しているなら、送付者はパケットを保護するそれらのセキュリティ協会のいずれも使用するかもしれません。
AUTHENTICATION ALGORITHM
This specifies the cryptographic algorithm and algorithm mode
used with the RIPv2 Security Association. This information is
never sent in cleartext over the wire. Because this
information is not sent on the wire, the implementer chooses an
implementation specific representation for this information.
At present, the following values are possible: KEYED-MD5,
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
AUTHENTICATION ALGORITHM ThisはRIPv2 Security Associationと共に使用される暗号アルゴリズムとアルゴリズムモードを指定します。 cleartextでこの情報をワイヤの上に決して送りません。 この情報がワイヤに送られないので、implementerはこの情報の実装の特定の表現を選びます。 現在のところ、以下の値は可能です: 合わせられたMD5、HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512。
AUTHENTICATION KEY
This is the value of the cryptographic authentication key used
with the associated Authentication Algorithm. It MUST NOT ever
be sent over the network in cleartext via any protocol. The
length of this key will depend on the Authentication Algorithm
in use. Operators should take care to select unpredictable and
strong keys, avoiding any keys known to be weak for the
algorithm in use. [ESC05] contains helpful information on both
key generation techniques and cryptographic randomness.
AUTHENTICATION KEY Thisは関連Authentication Algorithmと共に使用される暗号の認証キーの値です。 かつて、どんなプロトコルでもcleartextのネットワークの上にそれを送ってはいけません。 このキーの長さは使用中のAuthentication Algorithmに依存するでしょう。 オペレータは予測できないで強いキーを選択するために注意するべきです、使用中のアルゴリズムに弱いのが知られているどんなキーも避けて。 [ESC05]はキー生成のテクニックと暗号の偶発性の両方に関する役立つ情報を含んでいます。
Atkinson & Fanto Standards Track [Page 6] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[6ページ]RFC4822RIPv2
SEQUENCE NUMBER
This is an unsigned 32-bit number. For a given KEY-ID value
and sender, this number MUST NOT decrease. In normal
operation, the operator should rekey the RIPv2 session prior to
reaching the maximum value. The initial value used in the
sequence number is arbitrary. Receivers SHOULD keep track of
the most recent sequence number received from a given sender.
SEQUENCE NUMBER Thisは未署名の32ビットの数です。 与えられたKEY-ID値と送付者に関しては、この数は減少してはいけません。 通常の操作では、オペレータは最大値に達する前のRIPv2セッションのrekeyがそうするべきです。 一連番号に使用される初期の値は任意です。 受信機SHOULDは与えられた送付者から受け取られた最新の一連番号の動向をおさえます。
START TIME
This is a local representation of the day and time that this
Security Association first becomes valid.
START TIME Thisは1日のローカルの表現とこのSecurity Associationが最初に有効になる時間です。
STOP TIME
This is a local representation of the day and time that this
Security Association becomes invalid (i.e., when it expires).
It is permitted, but not recommended, for an operator to
configure this to "never expire". The "never expire" value is
not recommended operational practice because it reduces
security as compared with periodic rekeying. Normally, a RIPv2
Security Association is deleted at its STOP TIME. However,
there are certain pathological cases, which are discussed in
Section 5.1.
STOP TIME Thisは1日のローカルの表現とこのSecurity Associationが無効になる(すなわち、それはいつ期限が切れますか)時間です。 それは、オペレータが「決して期限が切れない」ようにこれを構成することが受入れられますが、勧められません。 周期的な「再-合わせ」ることと比べてセキュリティを下げるので、操作上の習慣は「決して期限が切れないでください」という値に推薦されません。 通常、RIPv2 Security AssociationはSTOP TIMEで削除されます。 しかしながら、ある病理学的なケースがあります。(セクション5.1でケースについて議論します)。
The authentication trailer consists of the Authentication Data, which is the output of the keyed cryptographic hash function. See later subsections of this section for details on computing this field.
認証トレーラはAuthentication Dataから成ります。(Authentication Dataは合わせられた暗号のハッシュ関数の出力です)。 この分野を計算して、後で詳細のためのこのセクションの小区分がオンであることを見てください。
2.3. Basic Authentication Processing
2.3. 基本認証処理
When the authentication type is "Cryptographic Hash Function", message processing is changed in message creation and reception as compared with the original RIPv2 specification in [Mal94].
認証タイプが「暗号のハッシュ関数」であるときに、[Mal94]の当初のRIPv2仕様と比べてメッセージ作成とレセプションでメッセージ処理を変えます。
This section describes the message processing generically. Additional algorithm-dependent processing that is required is described in separate, subsequent sections of this document. As of this writing, there are 2 kinds of algorithm-dependent processing. One covers the "Keyed-MD5" algorithm. The other covers the "HMAC-SHA1" family of algorithms.
このセクションは一般的にメッセージ処理について説明します。 必要である追加アルゴリズム依存する処理はこのドキュメントの別々の、そして、その後のセクションで説明されます。 この書くこと現在、2種類のアルゴリズム依存する処理があります。 1つは「合わせられたMD5"アルゴリズム」をカバーしています。 もう片方が「アルゴリズムのHMAC-SHA1"ファミリー」をカバーしています。
2.3.1. Message Generation
2.3.1. メッセージ世代
The RIPv2 Packet is created as usual, with these exceptions:
RIPv2 Packetはこれらの例外で通常通りで作成されます:
(1) The UDP checksum SHOULD be calculated, but MAY be set to zero
because any of the cryptographic authentication mechanisms in
this specification will provide stronger integrity protection
than the standard UDP checksum.
(1) UDPチェックサムSHOULDは、計算されますが、この仕様による暗号の認証機構のどれかが標準のUDPチェックサムより強い保全保護を提供するので、ゼロに用意ができるかもしれません。
Atkinson & Fanto Standards Track [Page 7] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[7ページ]RFC4822RIPv2
(2) The Authentication Type field indicates Cryptographic
Authentication (3).
(2) Authentication Type分野はCryptographic Authentication(3)を示します。
(3) The Authentication "password" field is reused to store a packet
offset to the Authentication Data, a Key Identifier, the
Authentication Data Length, and a non-decreasing sequence number.
(3) Authentication「パスワード」分野は、Authentication Data、Key Identifier、Authentication Data Length、および非減少している一連番号まで相殺されたパケットを保存するために再利用されます。
See also Section 2.2 above on RIPv2 Security Association for other important background information.
また、他の重要な基礎的な情報において、セクション2.2がRIPv2 Security Associationで上であることを見てください。
When creating the RIPv2 Packet, the following process is followed:
RIPv2 Packetを作成するとき、以下のプロセスは続かれています:
(1) The Packet Length field of the RIPv2 header indicates the size of
the main body of the RIPv2 packet.
(1) RIPv2ヘッダーのPacket Length分野はRIPv2パケットの本体のサイズを示します。
(2) An appropriate RIPv2 Security Association is selected for use
with this packet, based on the outbound interface for the packet.
Any valid RIPv2 Security Association for that outbound interface
may be used. The Authentication Data Offset, Key Identifier, and
Authentication Data Length fields are filled in appropriately.
(2) 適切なRIPv2 Security Associationは使用のためにこのパケットで選択されます、パケットのための外国行きのインタフェースに基づいて。 その外国行きのインタフェースへのどんな有効なRIPv2 Security Associationも使用されるかもしれません。 Authentication Data Offset、Key Identifier、およびAuthentication Data Length分野は適切に記入されます。
(3) Algorithm-dependent processing occurs now, either for the
"Keyed-MD5" algorithm or for the "HMAC-SHA1" algorithm family.
See the respective sub-sections (below) for details of this
algorithm-dependent processing.
(3) アルゴリズム依存する処理が現在起こる、「アルゴリズムか「HMAC-SHA1"アルゴリズムファミリー」のための合わせられたMD5" このアルゴリズム依存する処理の詳細に関してそれぞれの小区分(below)を見てください。
(4) The resulting Authentication Data value is written into the
Authentication Data field. The trailing pad (if any) is not
actually transmitted, as it is entirely predictable from the
message length and Authentication Algorithm in use.
(4) 結果として起こるAuthentication Data値はAuthentication Data分野に書かれています。 引きずっているパッド(もしあれば)は実際に送られません、それがメッセージ長と使用中のAuthentication Algorithmから完全に予測できるとき。
2.3.2. Message Reception
2.3.2. メッセージレセプション
When the message is received, the process is reversed:
メッセージが受信されているとき、プロセスは逆にされます:
(1) The received Authentication Data is set aside and stored for
later use,
(1) 容認されたAuthentication Dataはかたわらに置かれて、後の使用のために保存されます。
(2) The appropriate RIPv2 Security Association is determined from the
value of the Key Identifier field and the interface the packet
was received on. If there is no valid RIPv2 Security Association
for the received Key Identifier on the interface that the packet
was received on, then:
(2) 適切なRIPv2 Security Associationはパケットが受け取られたKey Identifier分野とインタフェースの値から断固としています。 容認されたKey Identifierのためのどんな有効なRIPv2 Security Associationもパケットが受け取られたインタフェースにありません、そして:
(a) all processing of the incoming packet ceases, and
そして(a) 入って来るパケットのすべての処理がやむ。
(b) a security event SHOULD be logged by the RIPv2 subsystem of
the receiving system. That security event should indicate at
(b) セキュリティイベントSHOULD、受電方式のRIPv2サブシステムで、登録されてください。 そのセキュリティイベントは示すべきです。
Atkinson & Fanto Standards Track [Page 8] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[8ページ]RFC4822RIPv2
least the day/time that the bad packet was received, the
Source IP Address of the received RIPv2 packet, the Key-ID
field value, the interface the bad packet arrived upon, and
the fact that no valid RIPv2 Security Association was found
for that interface and Key-ID combination.
どんな有効なRIPv2 Security Associationも値と、悪いパケットが到着したインタフェースと、事実ではありませんでしたが、そのインタフェースとKey-ID組み合わせに関して見つけられて、悪いパケットを受け取った日/時に容認されたRIPv2パケットのSource IP Address、Key-IDがさばく最少。
(3) Algorithm-dependent processing is performed, using the algorithm
specified by the appropriate RIPv2 Security Association for this
packet. This results in calculation of the Authentication Data
based on the information in the received RIPv2 packet and
information from the appropriate RIPv2 Security Association for
that packet.
(3) 適切なRIPv2 Security Associationによってこのパケットに指定されたアルゴリズムを使用して、アルゴリズム依存する処理は実行されます。 これは容認されたRIPv2パケットの情報とそのパケットのための適切なRIPv2 Security Associationからの情報に基づくAuthentication Dataの計算をもたらします。
(4) The calculated Authentication Data result is compared with the
received Authentication Data.
(4) 計算されたAuthentication Data結果は容認されたAuthentication Dataと比較されます。
(5) If the calculated authentication data result does not match the
received Authentication Data field, then:
(5) 次に、計算された認証データ結果が容認されたAuthentication Data分野に合っていないなら:
(a) the message MUST be discarded without being processed, and
そして(a) 処理されないでメッセージを捨てなければならない。
(b) a security event SHOULD be logged by the RIPv2 subsystem of
the receiving system. That security event SHOULD indicate at
least the day/time that the bad packet was received, the
Source IP Address of the received RIPv2 packet, the Key-ID
field value, the interface the bad packet arrived upon, and
the fact that RIPv2 Authentication failed upon receipt of the
packet.
(b) セキュリティイベントSHOULD、受電方式のRIPv2サブシステムで、登録されてください。 そのセキュリティイベントSHOULDは少なくとも悪いパケットを受け取った日/時間、容認されたRIPv2パケットのSource IP Address、Key-ID分野価値、悪いパケットが到着したインタフェース、およびRIPv2 Authenticationがパケットを受け取り次第失敗したという事実を示します。
(6) If the neighbor has been heard from recently enough to have
viable routes in the local routing table, and the received
sequence number is less than the last sequence number received,
then the message MUST be discarded unprocessed. If the received
sequence number is less than the last sequence number received,
that fact SHOULD be logged as a security event. This logged
security event SHOULD indicate at least the day/time that the bad
packet was received, the Source IP Address of the received RIPv2
packet, the Key-ID field value, and the fact that an out-of-order
RIPv2 sequence number was received.
隣人の声が地方の経路指定テーブル、および容認された一連番号で実行可能なルートを持つことができるくらいの最近から聞かれたなら(6)が最後の一連番号が受けた以下である、そして、未加工でメッセージを捨てなければなりません。 容認された一連番号が最後の一連番号以下が受信されて、事実SHOULDがセキュリティイベントとして登録されるということであるなら。 この登録されたセキュリティイベントSHOULDは少なくとも悪いパケットを受け取った日/時間、容認されたRIPv2パケットのSource IP Address、Key-ID分野価値、および不適切なRIPv2一連番号を受け取ったという事実を示します。
When connectivity to the neighbor has been lost, the receiver
SHOULD be ready to accept either:
隣人への接続性は失われて、受信機はSHOULDです。いつ、受け入れる準備ができていてください:
- a message with a sequence number of zero.
- ゼロの一連番号があるメッセージ。
- a message with a higher sequence number than the last
received sequence number.
- 最終より高い一連番号があるメッセージは一連番号を受けました。
Atkinson & Fanto Standards Track [Page 9] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[9ページ]RFC4822RIPv2
(7) Acceptable messages are now truncated to the RIPv2 message
itself, minus the authentication trailer, and are processed
normally (i.e., in accordance with the RIPv2 base specification
in RFC 2453 [Mal98]). The last received sequence number for this
RIPv2 Security Association and sender is also updated.
(7) 許容できるメッセージは、今認証トレーラを引いてRIPv2メッセージ自体に先端を切られて、通常(すなわち、RFC2453[Mal98]のRIPv2基礎仕様通りに)、処理されます。 また、このRIPv2 Security Associationと送付者のための最後の容認された一連番号をアップデートします。
NOTA BENE: A router that has forgotten its current sequence number but remembers its Security Association MUST send its first packet with a sequence number of zero. This leaves a small opening for a replay attack. To reduce the risk of such attacks by precluding the situation where a router has forgotten its current sequence number, implementers SHOULD provide non-volatile storage for all components of a RIPv2 Security Association, and receiving systems SHOULD provide non-volatile storage for the last received sequence number from each sender. See also the Security Considerations section of this document.
背板嘆願: 現在の一連番号を忘れましたが、Security Associationを覚えているルータはゼロの一連番号と共に最初のパケットを送らなければなりません。 これは小径端部を反射攻撃に残します。 ルータが現在の一連番号を忘れたところで状況を排除することによってそのような攻撃の危険を減少させるために、implementers SHOULDはRIPv2 Security Associationのすべての部品に非揮発性記憶装置を供給します、そして、受電方式SHOULDは非揮発性記憶装置を各送付者から最後の容認された一連番号に提供します。 また、このドキュメントのSecurity Considerations部を見てください。
2.4. Keyed-MD5 Algorithm-Dependent Processing
2.4. 合わせられたMD5のアルゴリズム依存する処理
This section describes the algorithm-dependent processing steps applicable when the "Keyed-MD5" authentication algorithm is in use. The RIPv2 Authentication Key is always 16 octets when "Keyed-MD5" is in use.
「合わせられたMD5"認証アルゴリズムは使用中です」であるときに、このセクションは適切な状態でアルゴリズム依存する処理ステップについて説明します。 「合わせられたMD5"は使用中である」ときに、いつもRIPv2 Authentication Keyが16の八重奏です。
(1) The RIPv2 Authentication Key is appended to the RIPv2 packet in
memory.
(1) メモリのRIPv2パケットにRIPv2 Authentication Keyを追加します。
(2) The Trailing Pad for MD5 and message length fields are added in
memory. The diagram below shows how these additions appear when
appended in memory:
(2) MD5のためのTrailing Padとメッセージ長分野はメモリで加えられます。 以下のダイヤグラムはメモリで追加するとこれらの追加がどう現れるかを示しています:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Key |
/ (16 octets long) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad octets (as defined by RFC 1321) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証キー| /(16八重奏長さ)/| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロか以上が八重奏を水増しします(RFC1321によって定義されるように)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64ビットのメッセージ長MSW| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64ビットのメッセージ長LSW| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(3) The Authentication Data is then calculated according to the MD5
algorithm defined by RFC 1321 [Rivest92].
(3) そして、RFC1321[Rivest92]によって定義されたMD5アルゴリズムによると、Authentication Dataは計算されます。
Atkinson & Fanto Standards Track [Page 10] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[10ページ]RFC4822RIPv2
2.5. HMAC-SHA1 Algorithm-Dependent Processing
2.5. HMAC-SHA1のアルゴリズム依存する処理
This section describes the processing steps for HMAC Authentication. While HMAC was originally documented in [KMC97], for this specification, the terminology used in [FIPS-198] is used. While the current specification only provides full details for HMAC Authentication using the National Institute of Standards and Technology (NIST) SHA-1 algorithm (and its direct derivatives), this same basic process could be used with other cryptographic hash functions in the future. Because the RIPv2 packet is only hashed once, the overhead of the double hashing in this process is negligible.
このセクションはHMAC Authenticationのために処理ステップについて説明します。 HMACは元々この仕様のために[KMC97]に記録されましたが、[FIPS-198]で使用される用語は使用されています。 現在の仕様が米国商務省標準技術局(NIST)SHA-1アルゴリズム(そして、ダイレクト派生物)を使用することで一部始終をHMAC Authenticationに供給しているだけである間、この同じ塩基性製鋼法は将来、他の暗号のハッシュ関数と共に使用されるかもしれません。 RIPv2パケットが一度論じ尽くされるだけであるので、このプロセスの二重論じ尽くすことのオーバーヘッドは取るにたらないです。
The US NIST Secure Hash Standard (SHS), defined by [FIPS-180-2], includes specifications for SHA-1, SHA-256, SHA-384, and SHA-512. This specification defines processing for each of these.
[FIPS-180-2]によって定義された米国NIST Secure Hash Standard(SHS)はSHA-1、SHA-256、SHA-384、およびSHA-512のための仕様を含んでいます。 この仕様はそれぞれのこれらのための処理を定義します。
The output of the cryptographic computations (e.g., HMAC-SHA1) is NOT truncated for RIPv2 Cryptographic Authentication.
暗号の計算(例えば、HMAC-SHA1)の出力はRIPv2 Cryptographic Authenticationのために先端を切られません。
The Authentication Data Length is equal to the Message Digest Size for the hash algorithm in use.
使用中のハッシュアルゴリズムに、Authentication Data LengthはMessage Digest Sizeと等しいです。
Any key value known to be weak with an algorithm defined by the NIST Secure Hash Standard MUST NOT be used with such an algorithm in an implementation of this specification. US NIST is the authoritative source for public information on weak keys for those algorithms.
この仕様の実装にそのようなアルゴリズムでアルゴリズムがNIST Secure Hash Standardによって定義されている状態で弱いのが知られている少しのキー値も使用してはいけません。 US NISTはそれらのアルゴリズムのための弱いキーの上の公開情報のための権威筋です。
In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used:
以下でのアルゴリズム記述以下の用語体系([FIPS-198]と一致している)は使用されています:
H is the specific hashing algorithm,
for example, SHA-1 or SHA-256.
Ko is the cryptographic key used with the hash algorithm.
B is the block-size of H, measured in octets, not bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64.
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets, not bits.
For example, with SHA-1, L == 20.
XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times.
Ipad is the hexadecimal value 0x36 repeated B times.
Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
例えば、Hは、特定の論じ尽くすアルゴリズム、SHA-1またはSHA-256です。 コーはハッシュアルゴリズムで使用される暗号化キーです。 Bはビットではなく、八重奏で測定されたHのブロック・サイズです。 Bがハッシュサイズではなく、内部ブロックサイズであることに注意してください。 SHA-1とSHA-256のために: B=64。 SHA-384とSHA-512のために: B=128Lはビットではなく、八重奏で測定されたハッシュの長さです。 SHA-1、例えばL=20と共に。 XORは排他的論理和操作です。 Opadによる16進価値の0x5cがB回を繰り返したということです。 Ipadは繰り返された0×36B回16進値です。 Apadは(L/4)回繰り返された16進価値の0x878FE1F3です。
Atkinson & Fanto Standards Track [Page 11] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[11ページ]RFC4822RIPv2
(1) PREPARATION OF KEY
In this application, Ko is always L octets long.
(1) PREPARATION OF KEY In、このアプリケーションであり、いつもコーはL八重奏ロングです。
If the Authentication Key is L octets long, then Ko is set equal
to the Authentication Key. If the Authentication Key is more
than L octets long, then Ko is set to H(Authentication Key). If
the Authentication Key is less than L octets long, then Ko is set
to the Authentication Key with zeros appended to the end of the
Authentication Key such that Ko is L octets long.
長い間Authentication KeyがL八重奏であるなら、コーはAuthentication Keyと等しいセットです。 長い間Authentication KeyがL八重奏以上なら、コーはH(認証Key)に用意ができています。 コーが長い間Authentication KeyがL八重奏以下であるならゼロと共にAuthentication Keyの端まで追加されたAuthentication Keyに用意ができているので、長い間、コーはL八重奏です。
(2) FIRST HASH
First, the RIPv2 packet's Authentication Data field is filled
with the value Apad.
(2) FIRST HASH First、RIPv2パケットのAuthentication Data分野は値のApadで満たされます。
Then, a first hash, also known as the inner hash, is computed as
follows:
First-Hash = H(Ko XOR Ipad || (RIPv2 Packet))
次に、最初のまた、内側のハッシュとして知られているハッシュは以下の通り計算されます: 最初に、ハッシュ=H(コーXOR Ipad| | (RIPv2パケット))
(3) SECOND HASH
Then a second hash, also known as the outer hash, is computed as
follows:
Second-Hash = H(Ko XOR Opad || First-Hash)
(3) また、外側のハッシュとして知られているSECOND HASH Then1秒ハッシュは以下の通り計算されます: 第2ハッシュ=H(コーXOR Opad| | 最初に、ハッシュ)
(4) RESULT
The result Second-Hash becomes the authentication data that is
sent in the Authentication Data field of the RIPv2 packet. The
length of the Authentication Data field is always identical to
the message digest size of the hash function H that is being
used.
(4) RESULT結果Second-ハッシュはRIPv2パケットのAuthentication Data分野で送られる認証データになります。 Authentication Data分野の長さはいつも使用されているハッシュ関数Hのメッセージダイジェストサイズと同じです。
This also implies that use of hash functions with larger output
sizes will also increase the size of the packet as transmitted on
the wire.
また、これは、また、より大きい出力サイズがあるハッシュ関数の使用がワイヤの上に伝えられるようにパケットのサイズを増強するのを含意します。
3. Management Procedures
3. 管理手順
Key management is an important component of this mechanism and proper implementation is central to providing the intended level of risk reduction.
かぎ管理はこのメカニズムの重要な部品です、そして、適切な履行は意図しているレベルのリスク削減を供給するのに一番重要です。
3.1. Key Management Requirements
3.1. Key Management要件
It is strongly desirable that a hypothetical security breach in one Internet protocol not automatically compromise other Internet protocols. The Authentication Key of this specification SHOULD NOT be configured or stored using protocols (e.g., RADIUS) or cryptographic algorithms that have known flaws.
1つのインターネットプロトコルにおける仮定している機密保護違反が、他のインターネットがプロトコルであると自動的に感染しないのは、強く望ましいです。 プロトコル(例えば、RADIUS)か欠点を知っていた暗号アルゴリズムを使用することで構成されているか、または保存されたこの仕様SHOULD NOTのAuthentication Key。
Atkinson & Fanto Standards Track [Page 12] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[12ページ]RFC4822RIPv2
Implementations MUST support the storage of more than one key at the same time, although it is recognized that only one key will normally be active on an interface. Implementations MUST associate a specific Security Association lifetime (i.e., date/time first valid and date/time no longer valid) and a key identifier with each key. Implementations also MUST support manual key distribution. An example of manual key distribution is having the privileged user typing in the key, key lifetime, and key identifier on the router console. An operator may configure the Security Association lifetime to infinite, which means that the session is never rekeyed. However, instead, it is strongly recommended that operators rekey regularly, using a moderately short Security Association lifetime (e.g., 24 hours).
実装は同時に1個以上のキーのストレージをサポートしなければなりません、通常、1個のキーだけがインタフェースでアクティブになると認められますが。 実装は特定のSecurity Association生涯(すなわち、/時間もう最初に、有効、そして、日付/時間日付の有効な)、主要な識別子を各キーに関連づけなければなりません。 実装も手動の主要な分配をサポートしなければなりません。 手動の主要な分配に関する例で、特権ユーザはルータコンソールの上に主要で、主要な生涯、および主要な識別子をタイプしています。 オペレータは無限へのSecurity Association生涯を構成するかもしれません。(無限は、セッションが決して「再-合わせ」られないことを意味します)。 しかしながら、(例えば、24時間)適度に短いSecurity Association生涯を費やして、代わりに、そのオペレータrekeyは定期的に強くそれに推薦されます。
This specification requires support for at least two authentication algorithms, so the implementation MUST require that the authentication algorithm be specified for each key when the other key information is entered. Manual deletion of active Security Associations MUST be supported.
この仕様が少なくとも2つの認証アルゴリズムに支持を要するので、実装は、もう片方の主要な情報が入力されるとき、認証アルゴリズムが各キーに指定されるのを必要としなければなりません。 アクティブなSecurity Associationsの手動の削除をサポートしなければなりません。
It is likely that the IETF will define a standard key management protocol for use with routing protocols. It is strongly desirable to use an IETF standards-track key management protocol to distribute RIPv2 Authentication Keys among communicating RIPv2 implementations. Such a protocol would provide scalability and significantly reduce the human administrative burden. The Key-ID field can be used as a hook between RIPv2 and such a future protocol.
IETFは使用のためにルーティング・プロトコルで標準のかぎ管理プロトコルを定義しそうでしょう。 RIPv2実装を伝えるのにRIPv2 Authenticationキーズを分配するのにIETF標準化過程かぎ管理プロトコルを使用するのは強く望ましいです。 そのようなプロトコルは、スケーラビリティを提供して、人間の管理負担をかなり減少させるでしょう。 RIPv2とそのような将来のプロトコルの間のフックとしてKey-ID分野を使用できます。
Key management protocols have a long history of subtle flaws that are often discovered long after the protocol was first described in public. To avoid having to change all RIPv2 implementations should such a flaw be discovered, integrated key management protocol techniques were deliberately omitted from this specification.
かぎ管理プロトコルには、プロトコルが最初に公然と説明されたずっと後にしばしば発見される微妙な欠点の長い歴史があります。 そのような欠点が発見されるならすべてのRIPv2実装を変えなければならないのを避けるために、統合かぎ管理プロトコルのテクニックは故意にこの仕様から省略されました。
3.2. Key Management Procedures
3.2. Key Management手順
As with all security methods using keys, it is necessary to change the RIPv2 Authentication Key on a regular basis. To maintain routing stability during such changes, implementations MUST be able to store and use more than one RIPv2 Authentication Key on a given interface at the same time.
キーを使用するすべてのセキュリティメソッドのように、定期的にRIPv2 Authentication Keyを変えるのが必要です。 実装は、同時に、与えられたインタフェースの1RIPv2 Authentication Keyを保存して、そのような変化の間、ルーティングの安定性を維持するのに、使用できなければなりません。
Each key will have its own Key Identifier (KEY-ID), which is stored locally. The combination of the Key Identifier and the interface associated with the message uniquely identifies the Authentication Algorithm and RIPv2 Authentication Key in use.
各キーにはそれ自身のKey Identifier(KEY-ID)があるでしょう。(Key Identifierは局所的に保存されます)。 メッセージに関連しているKey Identifierとインタフェースの組み合わせは唯一使用中のAuthentication AlgorithmとRIPv2 Authentication Keyを特定します。
Atkinson & Fanto Standards Track [Page 13] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[13ページ]RFC4822RIPv2
As noted above in Section 2.3.1, the party creating the RIPv2 message will select a valid RIPv2 Security Association from the set of valid RIPv2 Security Associations for that interface. The receiver MUST use the Key Identifier and receiving interface to determine which RIPv2 Security Association to use for authentication of the received message. More than one RIPv2 Security Association MAY be associated with an interface at the same time. The receiver MUST NOT simply try all RIPv2 Security Associations (i.e., keys) that might be configured for RIPv2 on the receiving interface, as that creates an easily exploited denial-of-service attack on the RIP subsystem of the receiver. (At least one widely used implementation of the previous version of this specification violates these requirements as of the publication date of this document and has consequent security vulnerabilities.)
上で述べたようにセクション2.3.1では、RIPv2メッセージを作成するパーティーは有効なRIPv2 Security Associationsのセットから有効なRIPv2 Security Associationをそのインタフェースに選択するでしょう。 受信機は、受信されたメッセージの認証にどのRIPv2 Security Associationを使用したらよいかを決定するのにKey Identifierと受信インタフェースを使用しなければなりません。 1RIPv2 Security Associationが同時に、インタフェースに関連しているかもしれません。 受信機は受信インタフェースのRIPv2のために構成されるかもしれないすべてのRIPv2 Security Associations(すなわち、キー)を絶対に試みてはいけません、それが容易に利用されたサービス不能攻撃を受信機のRIPサブシステムに作成するとき。(この仕様の旧バージョンの少なくとも1つの広く使用された実装が、このドキュメントの公表日付現在、これらの要件に違反して、結果のセキュリティの脆弱性を持っています。)
Hence, it is possible to have fairly smooth RIPv2 Security Association (i.e., key) rollovers, without losing legitimate RIPv2 messages due to an invalid shared key and without requiring people to change all the keys at once. To ensure a smooth rollover, each communicating RIPv2 system must be updated with the new RIPv2 Security Association (including the new key) several minutes before the current RIPv2 Security Association will expire and several minutes before the new RIPv2 Security Association lifetime begins. Also, the new RIPv2 Security Association should have a lifetime that starts several minutes before the old RIPv2 Security Association expires. This gives time for each system to learn of the new security association before that security association will be used. It also ensures that the new security association will begin use and the current security association will go out of use before the current security association's lifetime expires. For the duration of the overlap in security association lifetimes, a system may receive messages corresponding to either security association and successfully authenticate the message. The Key-ID in the received message is used to select the appropriate security association (i.e., key) to be used for authentication.
したがって、無効の共有されたキーのため正統のRIPv2メッセージを失うことなしで人々がすぐにすべてのキーを変えるのが必要であるなしで滑らかなRIPv2 Security Association(すなわち、主要な)ロールオーバーを公正に持っているのは可能です。 滑らかなロールオーバーを確実にするために、現在のRIPv2 Security Associationが期限が切れる数分前と新しいRIPv2 Security Association寿命が始まる数分前に新しいRIPv2 Security Association(新しいキーを含んでいる)と共にそれぞれの交信しているRIPv2システムをアップデートしなければなりません。 また、新しいRIPv2 Security Associationには、古いRIPv2 Security Associationが期限が切れる数分前に始まる寿命があるはずです。 これはそのセキュリティ協会が使用される前に各システムが新しいセキュリティ協会を知る時間を与えます。 また、それは、新しいセキュリティ協会が使用を始めるのを確実にします、そして、現在のセキュリティ協会の寿命が期限が切れる前に現在のセキュリティ協会は使用から行くでしょう。 セキュリティ協会生涯のオーバラップの持続時間のために、システムは、どちらかのセキュリティ協会に対応するメッセージを受け取って、首尾よくメッセージを認証するかもしれません。 受信されたメッセージのKey-IDは、適切なセキュリティ協会(すなわち、主要な)が認証に使用されるのを選択するのに使用されます。
4. Conformance Requirements
4. 順応要件
For this specification, the term "conformance" has identical meaning to the phrase "full compliance".
この仕様に関しては、「順応」という用語は「完全な承諾」という句に同じ意味を持っています。
The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm MUST be implemented by all conforming implementations. In addition, the HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 algorithms SHOULD be implemented. MD5 is defined in [Rivest92]. SHA-1, SHA-256, SHA-384, and SHA-512 have been defined by the US NIST in [FIPS-180-2].
実装を従わせて、すべてでKeyed MD5認証アルゴリズムとHMAC-SHA1アルゴリズムを実装しなければなりません。 追加、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512アルゴリズムSHOULDでは、実装されてください。 MD5は[Rivest92]で定義されます。 SHA-1、SHA-256、SHA-384、およびSHA-512は[FIPS-180-2]でUS NISTによって定義されました。
Atkinson & Fanto Standards Track [Page 14] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[14ページ]RFC4822RIPv2
A conforming implementation MAY also support additional authentication algorithms, provided those additional algorithms are publicly and openly specified.
また、それらの追加アルゴリズムが公的にオープンに指定されるなら、従う実装は、追加認証がアルゴリズムであるとサポートするかもしれません。
Manual key distribution as described above MUST be supported by all conforming implementations. All implementations MUST support the smooth key rollover described under "Key Management Procedures". This also means that implementations MUST support at least 2 concurrent RIPv2 Security Associations.
実装を従わせて、上で説明される手動の主要な分配はすべてで後押しされていなければなりません。 すべての実装が「Key Management手順」の下で説明された滑らかな主要なロールオーバーをサポートしなければなりません。 また、これは、実装が少なくとも2同時発生のRIPv2 Security Associationsをサポートしなければならないことを意味します。
The user documentation provided with the implementation ought to contain clear instructions on how to configure the implementation such that smooth key rollover occurs successfully.
実装が提供されたユーザドキュメンテーションがどう実装を構成するかに関する明確な指示を含むべきであるので、滑らかな主要なロールオーバーは首尾よく起こります。
Implementations SHOULD support a standard key management protocol for secure distribution of RIPv2 Authentication Keys once such a key management protocol is standardized by the IETF.
そのようなかぎ管理プロトコルがIETFによっていったん標準化されると、実装SHOULDはRIPv2 Authenticationキーズの安全な分配のために標準のかぎ管理プロトコルをサポートします。
The Security Considerations section of this document is an integral part of the specification, not just a discussion of the protocol.
このドキュメントのSecurity Considerations部はプロトコルの議論だけではなく、仕様の不可欠の部分です。
5. Security Considerations
5. セキュリティ問題
This entire memo describes and specifies an authentication mechanism for the RIPv2 routing protocol that is believed to be secure against passive attacks. The term "passive attack" is defined in RFC 1704 [HA94]. The analysis contained in RFC 1704 motivated this work. Passive attacks are clearly widespread in the Internet at present [HA94].
この全体のメモは、受け身の攻撃に対して安全であると信じられているRIPv2ルーティング・プロトコルに、認証機構を説明して、指定します。 「受け身の攻撃」という用語はRFC1704[HA94]で定義されます。 RFC1704に含まれた分析はこの仕事を動機づけました。 受け身の攻撃は現在のところ[HA94]、インターネットで明確に広範囲です。
Protection against active attacks is incomplete in this current specification. The main issue relative to active attacks lies in the need to support the case where another router has recently rebooted and that router lacks the non-volatile storage needed to remember the RIPv2 Security Association(s) and last received RIPv2 sequence number(s) across that reboot.
活発な攻撃に対する保護はこの現在の仕様で不完全です。 別のルータが最近、リブートされて、そのルータがRIPv2 Security Association(s)を覚えているのに必要である非揮発性記憶装置を欠いて、最後にそのリブートの向こう側にRIPv2一連番号を受けたケースを支える必要には活発な攻撃に比例した本題があります。
5.1. Known Pathological Cases
5.1. 知られている病理学的なケース
Two known pathological cases exist that MUST be handled by implementations. Both of these are failures of the network manager. Each of these should be exceedingly rare in normal operation.
実装で扱わなければならない2つの知られている病理学的なケースが存在しています。 これらの両方はネットワークマネージャの失敗です。 それぞれのこれらは通常の操作できわめてまれであるはずです。
(1) During key rollover, devices might exist that have not yet been
successfully configured with the new key. Therefore, routers
SHOULD implement an algorithm that detects the set of RIPv2
Security Associations being used by its neighbors, and transmit
its messages using both the new and old RIPv2 Security
(1) 主要なロールオーバーの間、新しいキーでまだ首尾よく構成されていないデバイスは存在するかもしれません。 したがって、ルータSHOULDは、隣人によって使用されるRIPv2 Security Associationsのセットをそれが検出するアルゴリズムに実装して、新しくて古いRIPv2 Securityを使用することでメッセージを送ります。
Atkinson & Fanto Standards Track [Page 15] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[15ページ]RFC4822RIPv2
Associations (i.e., keys) until all of the neighbors are using
the new security association or the lifetime of the old security
association expires. Under normal circumstances, this elevated
transmission rate will exist for a single RIP update interval.
隣人のすべてまでの協会(すなわち、キー)が新しいセキュリティ協会を使用しているか、または古いセキュリティ協会の寿命は期限が切れます。 通常の状況下で、この高い通信速度は単一のRIPアップデート間隔の間、存在するでしょう。
(2) In the event that the last RIPv2 Security Association of an
interface expires, it is unacceptable to revert to an
unauthenticated condition, and not advisable to disrupt routing.
Therefore, the router MUST send a "last RIPv2 Security
Association expiration" notification to the network manager
(e.g., via SYSLOG, SNMP, and/or other means) and SHOULD treat
that last Security Association as having an infinite lifetime
until the lifetime is extended, the Security Association is
deleted by network management, or a new security association is
configured.
(2) インタフェースの最後のRIPv2 Security Associationが期限が切れる場合、ルーティングを混乱させるのは、非認証された状態に振り向けるのにおいて容認できなくて、賢明ではありません。 したがって、ルータはネットワークマネージャ(例えば、SYSLOG、SNMP、そして/または、他の手段を通した)に「最後のRIPv2 Security Association満了」通知を送らなければなりません、そして、SHOULDが寿命が拡張されるまで無限の生涯を持っているとしてその最後のSecurity Associationを扱うか、Security Associationがネットワークマネージメントで削除されるか、または新しいセキュリティ協会は構成されます。
In some circumstances, the practice described in (2) can leave an
opening to an active attack on the RIPv2 routing subsystem.
Therefore, any actual occurrence of a RIPv2 Security Association
expiration MUST cause a security event to be logged by the
implementation. This log item MUST include at least a note that the
RIPv2 Authentication Key expired, the RIP routing protocol
instance(s) affected, the routing interfaces affected, the Key-ID
that is affected, and the current date/time. Operators are
encouraged to check such logs as an operational security practice to
help detect active attacks on the RIPv2 routing subsystem. Further,
implementations SHOULD provide a configuration knob ("fail secure")
to let a network operator prefer to have the RIPv2 routing fail when
the last key expires, rather than continue using RIPv2 in an insecure
manner.
いくつかの事情では、(2)で説明された習慣はRIPv2ルーティングサブシステムに対する活発な攻撃に始まりを残すことができます。 したがって、RIPv2 Security Association満了のどんな実際の発生も実装でセキュリティイベントを登録させなければなりません。 このログ項目はRIPv2 Authentication Keyが期限が切れたという少なくともメモ、ルーティング・プロトコルインスタンスが影響したRIP、インタフェースが影響したルーティング、影響を受けるKey-ID、および現在の日付/時間を含まなければなりません。 オペレータがRIPv2ルーティングサブシステムに対する活発な攻撃を検出するのを助けるために操作上のセキュリティ実践のようなログをチェックするよう奨励されます。 さらに、ネットワーク・オペレータに不安定な方法でRIPv2を使用し続けているより最後のキーがむしろ期限が切れるとRIPv2ルーティングが失敗されるのを好ませるように、実装SHOULDは構成ノブ(「安全な状態で、失敗する」)を提供します。
5.2 Network Management Considerations
5.2 ネットワークマネージメント問題
Also, the use of SNMP, even SNMPv3 with cryptographic authentication and cryptographic confidentiality enabled, to modify or configure the RIPv2 Security Associations, or any component of the security association (for example, the cryptographic key), is NOT RECOMMENDED. This practice would create a potential for a cascading vulnerability, whereby a compromise in the SNMP security implementation would necessarily lead to a compromise not only of the local routing table (which could be accessed via SNMP) but also of all other routers that receive RIPv2 packets (directly or indirectly) from the compromised router.
また、SNMPの使用(RIPv2 Security Associationsを変更するか、または構成するのが可能にされた暗号の認証と暗号の秘密性があるSNMPv3、またはセキュリティ協会(例えば、暗号化キー)のどんなコンポーネントさえも)は、NOT RECOMMENDEDです。 この習慣は滝の脆弱性の可能性を作成するでしょう。(SNMPセキュリティ実装における感染は必ず脆弱性で感染しているルータから地方の経路指定テーブル(SNMPを通してアクセスできた)だけではなく、RIPv2パケットを受ける他のすべてのルータ(直接か間接的である)について感染につながるでしょう)。
Atkinson & Fanto Standards Track [Page 16] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[16ページ]RFC4822RIPv2
Similarly, the use of protocols not designed and evaluated for use in key management (e.g., RADIUS, Diameter) to configure the security association is also NOT RECOMMENDED. Reading the Security Associations via SNMP is allowed, but the information is to be treated as security-sensitive and protected by using the priv mode.
同様に、また、セキュリティ協会を構成するかぎ管理(例えば、RADIUS、Diameter)における設計されないで使用のための評価のプロトコルの使用はNOT RECOMMENDEDです。 情報は、SNMPを通してSecurity Associationsを読むのが許されていますが、セキュリティ敏感であるとして扱われて、privモードを使用することによって保護されることです。
Also, the use of SNMP to configure which form of RIPv2 authentication is in use is also NOT RECOMMENDED because of a similar cascading failure issue. Any future revision of the RIPv2 Management Information Base (MIB) [MB94] should consider making the rip2IfConfAuthType object read-only. Further, this object would need a new enum value to accommodate the RIPv2 cryptographic authentication type. In addition, the compliance statement for this MIB does not have a MIN-ACCESS for this object. At a minimum, if the MIB is updated, a new compliance statement SHOULD be written for this object that allows this object to be implemented as read-only. For the rip2ifConfAuthKey object, since this object always returns ''H when read, the object's MIN-ACCESS in any revised compliance statement SHOULD be not-accessible if the MIB is updated.
また、また、同様の滝の失敗問題のためにどの形式のRIPv2認証が使用中であるかを構成するSNMPの使用はNOT RECOMMENDEDです。 RIPv2 Management Information基地(MIB)[MB94]のどんな今後の改正も、rip2IfConfAuthTypeをオブジェクト書き込み禁止にすると考えるべきです。 さらに、このオブジェクトは、RIPv2の暗号の認証タイプに対応するために新しいenum値を必要とするでしょう。 さらに、このMIBのための承諾声明には、このオブジェクトのためのMIN-ACCESSがありません。 最小限では、このオブジェクトに関して、このオブジェクトは書かれていて、MIBがアップデートされて、a新しい承諾声明SHOULDであるなら読書唯一としてそれで実装します。 このオブジェクトがいつも戻るのでrip2ifConfAuthKeyが反対する、「読んでください、いずれのオブジェクトのMIN-ACCESSが承諾声明SHOULDを改訂したH、MIBをアップデートするならアクセスしやすくない、」
Further, for similar reasons, any future revisions to the RIPv2 Management Information Base (MIB) SHOULD deprecate or omit any objects that would permit the writing of any RIPv2 Security Association or RIPv2 Security Association component (e.g., the cryptographic key).
さらに、RIPv2 Management Information基地(MIB)のSHOULDへのどんな今後の改正も、同様の理由で、どんなRIPv2 Security AssociationやRIPv2 Security Associationの部品(例えば、暗号化キー)の書くことも可能にするどんなオブジェクトも、非難するか、または省略します。
Also, it is RECOMMENDED that any future revisions to the RIPv2 Management Information Base (MIB) consider adding MIB objects to hold information about any RIPv2 security events that might have occurred, and MIB objects that could be used to read the set of security events that have been logged by the RIPv2 subsystem. For each security event mentioned in this document, it is also RECOMMENDED that appropriate notifications be included, with a MAX-ACCESS of Accessible-for-notify, in any future versions of the RIPv2 MIB module.
また、RIPv2サブシステムで登録されたのは、RIPv2 Management Information基地(MIB)へのどんな今後の改正も、起こったどんなRIPv2セキュリティイベント、および使用できたMIBオブジェクトの情報も保持するためにMIBオブジェクトを加えるとセキュリティイベントのセットが読まれると考えるRECOMMENDEDです。 本書では言及されたそれぞれのセキュリティイベントのために、また、適切な通知が含まれているのは、RECOMMENDEDです、マックス-ACCESSと共にAccessible、通知、RIPv2 MIBモジュールのどんな将来のバージョンでも。
5.3. Key Management Considerations
5.3. Key Management問題
For the past several years, manual configuration (e.g., via a console) has been commonly used to create and modify RIPv2 Security Associations. There are a number of large-scale RIP deployments today that successfully use manual configuration of RIPv2 Security Associations. There are also sites that use scripts (e.g., combining Tcl/Expect, PERL, and SSHv2) with a site-specific configuration database and secure console connections to dynamically manage all aspects of their router configurations, including their RIPv2 Security Associations. This last approach is similar to the current IETF approach to Network Configuration (NetConf) standards.
過去数年間、手動の構成(例えば、コンソールを通した)は、RIPv2 Security Associationsを作成して、変更するのに一般的に使用されています。 今日の首尾よくRIPv2 Security Associationsの手動の構成を使用する多くの大規模なRIP展開があります。 ダイナミックにそれらのルータ構成の全面を管理するのに、サイト特有の構成データベースと安全なコンソール接続があるスクリプト(例えば、Tcl/が予想する結合、Perl、およびSSHv2)を使用するサイトもあります、それらのRIPv2 Security Associationsを含んでいて。 この最後のアプローチはNetwork Configuration(NetConf)規格への現在のIETFアプローチと同様です。
Atkinson & Fanto Standards Track [Page 17] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[17ページ]RFC4822RIPv2
Recent IETF Multicast Security (MSEC) working group efforts into multicast key management appear promising. Several large RIPv2 deployments happen to also have deployed the Kerberos authentication system. Recent IETF work into the use of Kerberos for Internet Key Negotiation (KINK) also seems relevant; one might use Kerberos to support RIPv2 key management functions for use at sites that have already deployed Kerberos. It is hoped that in the future the IETF will standardize a key management protocol suitable for managing RIPv2 Security Associations.
マルチキャストかぎ管理への最近のIETF Multicast Security(MSEC)ワーキンググループ取り組みは有望に見えます。 また、いくつかの大きいRIPv2展開がたまたまケルベロス認証システムを配布しました。 また、ケルベロスのインターネットKey Negotiation(KINK)の使用に対する最近のIETF仕事は関連しているように見えます。 1つは、既にケルベロスを配布したサイトでの使用のためにRIPv2かぎ管理が機能であるとサポートするのにケルベロスを使用するかもしれません。 将来IETFがRIPv2 Security Associationsを管理するのに適当なかぎ管理プロトコルを標準化することが望まれています。
5.4. Assurance Considerations
5.4. 保証問題
Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating RIPv2 implementations. This mechanism also depends on the RIPv2 Authentication Key being kept confidential by all parties. If any of these are incorrect or insufficiently secure, then no real security will be provided to the users of this mechanism.
ユーザは、このメカニズムによって提供されたセキュリティの品質をRIPv2実装をすべて伝える際に完全実装している認証アルゴリズムの強さ、使用されるキーの強さ、およびセキュリティー対策の正しい実装に依存するのを理解する必要があります。 また、このメカニズムはすべてのパーティーによって秘密にされるRIPv2 Authentication Keyによります。 これらのどれかが不正確であるか、または不十分に安全であるなら、このメカニズムのユーザに物上担保を全く提供しないでしょう。
Use of high-assurance development methods is RECOMMENDED for implementations of this specification, in order to reduce the risk of subtle implementation flaws that might adversely impact the operational risk reduction that this specification seeks to provide.
高保証開発メソッドの使用はこの仕様の実装のためのRECOMMENDEDです、逆に、この仕様が供給しようとする操作上のリスク削減に影響を与えるかもしれない微妙な実装欠点の危険を減少させるために。
5.5. Confidentiality and Traffic Analysis Considerations
5.5. 秘密性とトラヒック分析問題
Confidentiality is not provided by this mechanism. It is generally considered that an IP routing protocol does not require confidentiality, as the purpose of any routing protocols is to disseminate information about the topology of the network.
秘密性はこのメカニズムによって提供されません。 一般に、IPルーティング・プロトコルが秘密性を必要としないと考えられます、どんなルーティング・プロトコルの目的もネットワークのトポロジーの情報を広めることであるので。
Protection against traffic analysis is also not provided. Mechanisms such as bulk link encryption SHOULD be used when protection against traffic analysis is required [CKHD89].
また、トラヒック分析に対する保護は提供されません。 大量などのメカニズムは暗号化SHOULDをリンクします。トラヒック分析に対する保護が必要であった[CKHD89]ら、使用されてください。
5.6. Other Security Considerations
5.6. 他のセキュリティ問題
Separately, the receipt of a RIPv2 packet using cryptographic authentication but containing an invalid or unknown Key-ID value might indicate an active attack on the RIP routing subsystem and is a significant security event. Therefore, any actual receipt of a RIPv2 packet using cryptographic authentication and containing an unknown, expired, or otherwise invalid KEY-ID value SHOULD cause a security event to be logged by the implementation. This log item SHOULD include at least the fact that the invalid KEY-ID was received, the source IP address of the packet containing the invalid KEY-ID, the
別々に、暗号の認証を使用しますが、無効の、または、未知のKey-ID値を含むRIPv2パケットの領収書は、RIPルーティングサブシステムに対する活発な攻撃を示すかもしれなくて、重要なセキュリティイベントです。 したがって、暗号の認証を使用して、未知を含むRIPv2パケットのどんな実際の領収書でありも、満期の、または、そうでなければ、無効のKEY-ID値のSHOULDは実装でセキュリティイベントを登録させます。 このログ項目SHOULDは無効のKEY-IDを受け取ったという少なくとも事実を含んでいます、無効のKEY-IDを含むパケットのソースIPアドレス
Atkinson & Fanto Standards Track [Page 18] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[18ページ]RFC4822RIPv2
interface(s) the packet was received on, the KEY-ID received, and the current date/time.
パケットが受け取られた(s)、受け取られたKEY-ID、および現在の日付/時間を連結してください。
A subtle user-interface consideration also should be noted. If a user interface only permits the entry of human-readable text (e.g., a password in US-ASCII format) for use as a cryptographic key, significant numbers of bits of the cryptographic key in use become predictable, thereby reducing the strength of the key in this context. For this reason, implementations of this specification SHOULD support the entry of RIPv2 cryptographic authentication keys in hexadecimal format.
微妙なユーザーインタフェースの考慮も注意されるべきです。 ユーザーインタフェースが使用のために暗号化キーの暗号化キー、重要な数のビットとして人間読み込み可能なテキスト(例えば、米国-ASCII書式におけるパスワード)のエントリーを使用中に可能にするだけであるなら、予測できるようになってください、その結果、キーの強さをこのような関係においては減少させます。 この理由で、この仕様SHOULDの実装は16進形式における、RIPv2の暗号の認証キーのエントリーをサポートします。
5.7. Future Security Directions
5.7. 将来のセキュリティ方向
Specification and deployment of a standards-track key management protocol that supports this RIPv2 cryptographic authentication mechanism would be a significant next step in operational risk reduction and might actually increase the ease of deployment and operation of this mechanism. Such specification is beyond the scope of this document. Recent IETF work in MSEC and KINK working groups appears promising in this regard. Recent IETF work in the NETCONF working group towards standardizing methods for secure configuration management of routers is also relevant.
このRIPv2が暗号の認証機構であるとサポートする標準化過程かぎ管理プロトコルの仕様と展開は、操作上のリスク削減における次の重要なステップであるだろう、実際に展開の容易さとこのメカニズムの操作を増強するかもしれません。 そのような仕様はこのドキュメントの範囲を超えています。 MSECとKINKワーキンググループにおける最近のIETF仕事はこの点で有望に見えます。 また、ルータの安全な構成管理のためにメソッドを標準化することに向かったNETCONFワーキンググループにおける最近のIETF仕事も関連しています。
Finally, we observe that this mechanism is not the final word on RIPv2 authentication. Rather, it is believed that this particular mechanism represents a significant risk reduction over previous methods (e.g., plaintext passwords), while remaining straightforward to implement correctly and also straightforward to deploy.
最終的に、私たちは、このメカニズムがRIPv2認証に関する最終的な単語でないことを観測します。 むしろ、正しく実装するために簡単であって、また、配布するために簡単なままである間、この特定のメカニズムが前のメソッド(例えば、平文パスワード)の上のかなりのリスク削減を表すと信じられています。
User communities that believe this mechanism is not adequate to their needs are encouraged to consider using digital signatures with RIPv2. [MBW97] specifies the use of OSPF with Digital signatures; that document might be a starting point for creating such a specification for the RIPv2 protocol. Digital signatures are significantly more expensive computationally and are also significantly more difficult to deploy operationally, as compared with the mechanism specified here. However, it appears likely that much of the mechanism in this document could be reused with digital signatures.
このメカニズムが彼らの必要性に適切でないと信じているユーザーコミュニティが、RIPv2とのデジタル署名を使用すると考えるよう奨励されます。 [MBW97]はDigital署名によるOSPFの使用を指定します。 そのドキュメントは、RIPv2プロトコルのためのそのような仕様を作成するための出発点であるかもしれません。 デジタル署名は、計算上かなり高価であり、また、操作上配布するのもかなり難しいです、ここで指定されるメカニズムと比べて。 しかしながら、デジタル署名で本書ではメカニズムのそれだけを再利用できたのがありそうに見えます。
6. Acknowledgments
6. 承認
Fred Baker was co-author of the earlier RIPv2 MD5 Authentication document [AB97]. This document is a direct derivative of that earlier document, though it has been significantly reworked. The current authors would like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST for review of versions of this document.
フレッド・ベイカーは以前のRIPv2 MD5 Authenticationドキュメント[AB97]の共著者でした。 それはかなり作りなおされましたが、このドキュメントはその以前のドキュメントのダイレクト派生物です。 現在の作者はこのドキュメントのバージョンのレビューについて(米国)NISTのビルBurr、ティム・ポーク、ジョン・ケルシー、およびモリスドーキンに感謝したがっています。
Atkinson & Fanto Standards Track [Page 19] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[19ページ]RFC4822RIPv2
7. Normative References
7. 引用規格
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[Mal98] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[Mal98] マルキン、G.は「1998年11月にバージョン2インチ、STD56、RFC2453を裂きます」。
[FIPS-180-2] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>.
[FIPS-180-2]米国商務省標準技術局、「安全なハッシュ規格」、FIPS PUB180-2、2002年8月、<http://csrc.nist.gov/刊行物/fips/fips180-2/fips180-2.pdf>。
[FIPS-198] National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198, March 2002, <http://csrc.nist.gov/publications/
fips/fips198/fips-198a.pdf>.
[FIPS-198]米国商務省標準技術局、「合わせられたハッシュメッセージ立証コード(HMAC)」、FIPS PUB198、2002年3月、<http://csrc.nist.gov/刊行物/fips/fips198/fips-198a. pdf>。
8. Informative References
8. 有益な参照
[AB97] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication",
RFC 2082, January 1997.
[AB97] ベイカーとF.とR.アトキンソン、「裂け目-2MD5認証」、RFC2082、1997年1月。
[Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Volume 19,
Number 2, pp. 32-48, April 1989.
[Bell89]S.Bellovin、「TCP/IPプロトコル群の警備上の問題」、ACMコンピュータCommunications Review、Volume19、Number2、ページ 32-48と、1989年4月。
[CKHD89] Cole Jr, Raymond, Donald Kallgren, Richard Hale, and
John R. Davis, "Multilevel Secure Mixed-Media
Communication Networks", Proceedings of the IEEE
Military Communications Conference (MILCOM '89), IEEE,
1989.
[CKHD89] コールJr、レイモンド、ドナルドKallgren、リチャード・ヘール、およびジョン・R.デイヴィス、「多レベルの安全な混合媒体通信ネットワーク」、IEEE軍事通信コンファレンス(MILCOM89年)、IEEE、1989年の議事。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress",
Technical Report, 2 May 1996. (Presented at Rump
Session of EuroCrypt 1996.)
[Dobb96a] Dobbertin、H.、「MD5湿布の暗号文解読術」、技術報告書、1996年5月2日。 (EuroCrypt1996の臀部セッションのときに、提示されます。)
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent
Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
[Dobb96b] Dobbertin、H.、「最近の攻撃の後のMD5の状態」、CryptoBytes、Vol.2、No.2、1996年夏。
[ESC05] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[ESC05]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[HA94] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[HA94] ハラーとN.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
Atkinson & Fanto Standards Track [Page 20] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[20ページ]RFC4822RIPv2
[KMC97] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[KMC97] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[Mal94] Malkin, G., "RIP Version 2 - Carrying Additional
Information", RFC 1723, November 1994.
[Mal94] マルキン、G.が「追加情報を運んで、バージョン2をコピーする」、RFC1723、11月1994日
[MB94] Malkin, G. and F. Baker, "RIP Version 2 MIB Extension",
RFC 1724, November 1994.
[MB94] マルキンとG.とF.ベイカー、「裂け目のバージョン2MIB拡張子」、RFC1724、1994年11月。
[MBW97] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
1997年6月の[MBW97]マーフィーとS.とムジナ、M.とB.ウェリントン、「デジタル署名があるOSPF」RFC2154。
[Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[Rivest92] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
Authors' Addresses
作者のアドレス
R. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
R.アトキンソン極端は3585モンロー・通りカリフォルニア95051サンタクララ(米国)をネットワークでつなぎます。
Phone: +1 (408) 579-2800 EMail: rja@extremenetworks.com
以下に電話をしてください。 +1 (408) 579-2800 メールしてください: rja@extremenetworks.com
M. Fanto (US) National Institute of Standards and Technology Gaithersburg, MD 20878 USA
M.Fanto(米国)米国商務省標準技術局MD20878ゲイザースバーグ(米国)
Phone: +1 (301) 975-2000 EMail: mattjf@umd.edu Web: http://csrc.nist.gov
以下に電話をしてください。 +1 (301) 975-2000 メールしてください: mattjf@umd.edu ウェブ: http://csrc.nist.gov
Atkinson & Fanto Standards Track [Page 21] RFC 4822 RIPv2 Cryptographic Authentication February 2007
認証2007年2月の暗号のアトキンソンとFanto標準化過程[21ページ]RFC4822RIPv2
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Atkinson & Fanto Standards Track [Page 22]
アトキンソンとFanto標準化過程[22ページ]
一覧
スポンサーリンク
