RFC2154 日本語訳
2154 OSPF with Digital Signatures. S. Murphy, M. Badger, B.Wellington. June 1997. (Format: TXT=72701 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Murphy
Request for Comments: 2154 M. Badger
Category: Experimental B. Wellington
Trusted Information Systems
June 1997
コメントを求めるワーキンググループS.マーフィー要求をネットワークでつないでください: 2154年のM.ムジナカテゴリ: 実験的なB.ウェリントンは1997年6月に情報システムを信じました。
OSPF with Digital Signatures
デジタル署名があるOSPF
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co- existence with, standard OSPF V2 is described.
このメモはLink州データにデジタル署名認証を追加して、証明メカニズムをルータデータに提供しなければならなかったOSPFに拡大について説明します。 加えられたLSA処理とかぎ管理は詳細です。 移行のためのメソッド、共同存在、標準のOSPF V2は説明されます。
Table of Contents
目次
1 Acknowledgements ............................................. 2 2 Introduction ................................................. 2 3 LSA Processing ............................................... 4 3.1 Signed LSA ................................................. 4 3.2 Router Public Key LSA (PKLSA) .............................. 5 3.3 MaxAge Processing .......................................... 7 4 Key Management ............................................... 8 4.1 Identifying Keys ........................................... 8 4.1.1 Identifying Router Keys and PKLSAs ....................... 8 4.1.2 Identifying TE Public Keys ............................... 8 4.1.3 Key to use for Signing ................................... 9 4.1.4 Key to use for Verification .............................. 9 4.2 Trusted Entity (TE) Requirements ........................... 10 4.3 Scope for Keys and Signature Algorithms..................... 10 4.4 Router Key Replacement ..................................... 11 4.5 Trusted Entity Key Replacement ............................. 12 4.6 Flexible Cryptographic Environments ........................ 14 4.6.1 Multiple Signature Algorithms ............................ 14 4.6.2 Multiple Trusted Entities ................................ 15 4.6.3 Multiple Keys for One Router ............................. 16 5 Compatibility with Standard OSPF V2 .......................... 16 6 Special Considerations/Restrictions for the ABR-ASBR ......... 17 7 LSA formats .................................................. 18
1承認… 2 2序論… 2 3LSA処理… 4 3.1はLSAに署名しました… 4 3.2 ルータ公開鍵LSA(PKLSA)… 5 3.3 MaxAge処理… 7 4Key Management… 8 4.1 キーを特定します… 8 4.1 .1 ルータキーとPKLSAsを特定します… 8 4.1 .2 Te公開鍵を特定します… 8 4.1 Signingに使用する.3キー… 9 4.1 Verificationに使用する.4キー… 9 4.2は実体(Te)要件を信じました… 10 4.3 キーのための範囲と署名アルゴリズム… 10 4.4 ルータの主要な交換… 11 4.5は実体の主要な交換を信じました… 12 4.6 フレキシブルな暗号の環境… 14 4.6 .1 複数の署名アルゴリズム… 14 4.6 .2倍数は実体を信じました… 1つのルータのための15 4.6.3Multipleキーズ… 16 標準のOSPF V2との5の互換性… 16 6 ABR-ASBRに、特別な問題/制限… 17 7 LSA形式… 18
Murphy, et. al. Experimental [Page 1] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[1ページ]RFC2154OSPF
7.1 Router Public Key LSA (PKLSA) .............................. 18 7.2 Router Public Key Certificate .............................. 20 7.3 Signed LSA ................................................. 23 8 Configuration Information .................................... 26 9 Remaining Vulnerabilities .................................... 26 9.1 Area Border Routers ........................................ 27 9.2 Internal Routers ........................................... 27 9.3 Autonomous System Border Routers ........................... 28 10 Security Considerations ..................................... 28 11 References .................................................. 29 12 Authors' Addresses .......................................... 29
7.1 ルータ公開鍵LSA(PKLSA)… 18 7.2ルータ公開鍵証明書… 20 7.3はLSAに署名しました… 23 8 構成情報… 26 9 脆弱性のままで、残っています… 26 9.1 領域境界ルータ… 27 9.2の内部のルータ… 27 9.3 自律システム境界ルータ… 28 10のセキュリティ問題… 28 11の参照箇所… 29 12人の作者のアドレス… 29
1. Acknowledgements
1. 承認
The idea of signing routing information is not new. Foremost, of course, there is the design that Radia Perlman reported in her thesis [4] and in her book [5] for signing link state information and for distribution of the public keys used in the signing. IDPR [7] also recommends the use of public key based signatures of link state information. Kumar and Crowcroft [2] discuss the use of secret and public key authentication of inter-domain routing protocols. Finn [1] discusses the use of secret and public key authentication of several different routing protocols. The design reported here is closest to that reported in [4] and [7]. It should be noted that [4] also presents techniques for protecting the forwarding of data packets, a topic that is not considered here, as we consider it not within the scope of the OSPF working group.
ルーティングが情報であると署名するというアイデアは新しくはありません。 最前に、Radiaパールマンがリンク状態が情報であると署名して、署名に使用される公開鍵の分配のために彼女の論文[4]と彼女の本[5]で報告したデザインがもちろんあります。 また、IDPR[7]は、公開鍵の使用がリンク州の情報の署名を基礎づけたことを勧めます。 クマーとクロウクロフト[2]は相互ドメインルーティング・プロトコルの秘密と公開鍵認証の使用について議論します。 フィンランド人[1]は秘密の使用といくつかの異なったルーティング・プロトコルの公開鍵認証について議論します。 ここで報告されたデザインが[4]と[7]で報告されたその最も近くにあります。 また、[4]がデータ・パケットの推進を保護するためのテクニックを提示することに注意されるべきです、ここで考えられない話題、私たちがOSPFワーキンググループのいずれの範囲の中でもそれを考えないとき。
The authors would also like to acknowledge many fruitful discussions with many members of the OSPF working group, particularly Fred Baker of Cisco Systems, Dennis Ferguson of MCI Telecommunications Corp., John Moy of Cascade Communications Corp., Curtis Villamizar of ANS, Inc., and Rob Coltun of FORE Systems.
また、作者はOSPFワーキンググループの多くのメンバー、特にシスコシステムズのフレッド・ベイカー、MCI Telecommunications社のデニスファーガソン、Cascade Communications社のジョンMoy、ANS Inc.のカーティスVillamizar、およびFORE SystemsのロブColtunとの多くの有意義な論議を承諾したがっています。
2. Introduction
2. 序論
It is well recognized that there is a need for greater security in routing protocols. OSPF currently provides "simple password" authentication where the password travels "in the clear", and there is work in progress[11] to provide keyed MD5 authentication for OSPF protocol packets between neighbors. The simple password authentication is vulnerable because any listener can discover and use the password. Keyed MD5 authentication is very useful for protection of protocol packets passed between neighbors, but does not address authentication of routing data that is flooded from source to eventual destination, through routers which may themselves be faulty or subverted.
ルーティング・プロトコルにおける、よりすばらしいセキュリティの必要があるとよく認められます。 OSPFは現在、パスワードが「明確」を移動して、OSPFプロトコルパケットのための合わせられたMD5認証を隣人の間に提供するために処理中の作業[11]があるところに「簡単なパスワード」認証を提供します。 どんなリスナーもパスワードを発見して、使用できるので、簡単なパスワード認証は被害を受け易いです。 合わせられたMD5認証は非常に隣人の間で通過されたプロトコルパケットの保護の役に立ちますが、そうするかもしれないルータを通してソースから最後の目的地まで自分たちで水につかっているルーティングデータのアドレス認証は、不完全でなく、また打倒されていませんか?
Murphy, et. al. Experimental [Page 2] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[2ページ]RFC2154OSPF
The basic idea of this proposal is to add digital signatures to OSPF LSA data, distribute certified router information and keys, and use a neighbor-to-neighbor authentication algorithm (like keyed MD5) to protect local protocol exchanges. The content of a Hello packet, Link State Request, Link State Update, or Database Description will be protected by the neighbor-to-neighbor algorithm. The LSAs that are being flooded inside the Link State Update packets are individually protected by a digital signature. Each LSA will be signed by the originator of that information and the signature will stay with the data in its travels via OSPF flooding. This will provide end-to-end integrity and authentication for LSA data. The digital signature attached to an LSA by the source router provides assurance that the data comes from the advertising router. It will also ensure that the data has not been modified by some other router in the course of flooding. In the case where incorrect routing data is originated by a faulty router, the signature will identify the source of the problem.
この提案の基本的な考え方は、地方のプロトコル交換を保護するのにOSPF LSAデータにデジタル署名を追加して、公認されたルータ情報とキーを分配して、隣人から隣人への認証アルゴリズムを使用する(合わせられたMD5のように)ことです。 Helloパケット、Link州Request、Link州Update、またはDatabase記述の内容は隣人から隣人へのアルゴリズムで保護されるでしょう。 Link州Updateパケットの中で水につかっている存在であるLSAsはデジタル署名で個別に保護されます。 各LSAはその情報の創始者によって署名されるでしょう、そして、署名はOSPF氾濫を通して旅行におけるデータで残るでしょう。 これはLSAデータのための終わりから終わりへの保全と認証を提供するでしょう。 ソースルータによってLSAに付けられたデジタル署名はデータが広告ルータから来るという保証を提供します。 また、それは、データが氾濫の間にある他のルータによって変更されていないのを確実にするでしょう。 不正確なルーティングデータが不完全なルータによって溯源される場合では、署名は問題の源を特定するでしょう。
Digital signatures are implemented using public key cryptography. There are some good books on the subject of cryptography [6], but the high level view of how this design uses public key cryptography is as follows: Each router has a pair of keys, a public key and a private key. The private key is used to generate a unique signature of a block of data (in this case, the LSA). Each router signs its LSAs by first running a one-way hash algorithm (like MD5 or SHA) on the data, and then using its private key to sign the digest. The signature of an LSA is appended to the LSA. The public key can be used by any other router to verify the signature. The private key must be kept secret by one router and the public key must be distributed to all the routers that will receive link state information from the signer. The distribution is accomplished by creating a new LSA, the Public Key LSA (PKLSA), and distributing it via the standard OSPF flooding procedure. Flooding will ensure that a router public key is sent everywhere that the router's signed LSAs are sent.
デジタル署名は、公開鍵暗号を使用することで実装されます。 いくつかの良書が暗号[6]の問題を扱っていますが、このデザインがどう公開鍵暗号を使用するかに関する高い平らな意見は以下の通りです: 各ルータには、1組のキー、公開鍵、および秘密鍵があります。 秘密鍵は、1ブロックのデータのユニークな署名が(この場合LSA)であると生成するのに使用されます。 一方向ハッシュアルゴリズム(MD5やSHAのような)をデータに実行して、次に、ダイジェストに署名するのに秘密鍵を使用することで各ルータは最初にでLSAsに署名します。 LSAの署名をLSAに追加します。 公開鍵はいかなる他のルータによっても使用されて、署名について確かめることができます。 1つのルータで秘密鍵を秘密にしなければなりません、そして、署名者からリンク州の情報を受け取るすべてのルータに公開鍵を分配しなければなりません。 分配は、新しいLSA、Public Key LSA(PKLSA)を作成して、標準のOSPF氾濫手順でそれを分配することによって、実行されます。 氾濫は、ルータ公開鍵がルータがLSAsであると署名されるのが送られるいたる所に送られるのを確実にするでしょう。
Any router can send out a public key and claim to be a given router, so the public key itself provides no assurance of the actual identity of the sender. This assurance must be provided by a Trusted Entity. The Trusted Entity (TE) is a system that generates certificates for routers. A certificate is a packet of information about a router that identifies the router and supplies a public key. Certified router information will include the router id, its role, the address ranges that the router may advertise, a timestamp and the router's public key. The certificate is signed by the TE. Each router must be configured with a certificate and a TE public key to use in verifying other routers' certificates. A router PKLSA contains the certificate for that router. A router receiving a PKLSA verifies the certificate using the TE public key, and then verifies the whole LSA using the
どんなルータも与えられたルータになるように公開鍵とクレームを出すことができるので、公開鍵自体は送付者の実際のアイデンティティの保証を全く提供しません。 Trusted Entityはこの保証を提供しなければなりません。 Trusted Entity(TE)はルータのための証明書を作るシステムです。 証明書はルータを特定して、公開鍵を供給するルータの情報のパケットです。 公認されたルータ情報はルータイド、役割、ルータが広告を出すかもしれないアドレスの範囲、タイムスタンプ、およびルータの公開鍵を含むでしょう。 証明書はTEによって署名されます。 他のルータの証明書について確かめる際に使用する証明書とTE公開鍵で各ルータを構成しなければなりません。 ルータPKLSAはそのルータのための証明書を含んでいます。 PKLSAを受けるルータは、TE公開鍵を使用することで証明書について確かめて、次に、全体のLSA使用について確かめます。
Murphy, et. al. Experimental [Page 3] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[3ページ]RFC2154OSPF
router public key contained in the certificate. Successful verification provides assurance that the PKLSA is from the correct router, and that it has not been altered by any other router in the flood path.
証明書に含まれたルータ公開鍵。 うまくいっている検証はPKLSAが正しいルータから来ていて、それが洪水経路のいかなる他のルータによっても変更されていないという保証を提供します。
OSPF with Digital Signatures is backward compatible with standard OSPF V2 in a limited way. Within an AS there may be "signed" areas and "unsigned" areas. The behavior of a mixed AS is discussed in section 5.
Digital SignaturesとOSPFは限られた方法で標準のOSPF V2と互換性があった状態で後方です。 中では、そこのASが領域と「未署名」の領域であると「署名されるかもしれません」。 セクション5で混ぜられたASの動きについて議論します。
Digital signatures for OSPF LSAs can be implemented with the following major functions:
以下の主要な機能でOSPF LSAsのためのデジタル署名を実装することができます:
(1) Support for a digital signature algorithm
(1) デジタル署名アルゴリズムのサポート
(2) Support for a signed version of all routing information LSAs
(2) すべてのルーティングの署名しているバージョンには、情報がLSAsであるとサポートしてください。
(3) Support for a new LSA: Router Public Key LSA (PKLSA)
(3) 新しいLSAのために以下をサポートしてください。 ルータ公開鍵LSA(PKLSA)
(4) A mechanism for key certification and certificate distribution
(4) 主要な証明と証明書分配のためのメカニズム
(5) Extra configuration data (detail in section 7):
(5) 付加的なコンフィギュレーション・データ(セクション7の詳細):
Trusted Entity (TE) information and key(s)
Router certification data and key
Area environment flag (signed/unsigned)
Timing intervals
信じられたEntity(TE)情報、主要な(s)ルータ証明データ、および主要なArea環境旗(署名しているか未署名の)のタイミング間隔
An implementation of this design exists, based on the OSPF in Gated version 3.5Beta3. This implementation is available for use/experimentation. Please contact the authors for information.
このデザインの実装はGatedバージョン3.5Beta3のOSPFに基づいて存在しています。 この実装は使用/実験に利用可能です。 情報のために作者に連絡してください。
3. LSA Processing
3. LSA処理
3.1. Signed LSA
3.1. LSAであると署名されます。
A signed LSA contains the standard OSPF V2 header and data plus key identification information, a signature length and a signature. The top bit of the LS type field is set to indicate the presence of a signature. The signature covers the LSA header (starting with the options field), the LSA data, and the key identification information and the signature length that must be appended to the LSA data. There are two exceptions to this coverage: first, an LSA created with age=MaxAge has a signature that begins with the age field (see section on maxage); second, the LSA header checksum is set to zero for the generation of the signature. To assist in parsing the message, the key id information and the signature length fields are placed at the end of the LSA, following the signature. However, the
署名しているLSAは標準のOSPF V2ヘッダー、データ、主要な識別情報、署名の長さ、および署名を含んでいます。 LSタイプ分野のトップビットが署名の存在を示すように設定されます。 署名はLSAヘッダー(オプション野原から始まる)、LSAデータ、主要な識別情報、およびLSAデータに追加しなければならない署名の長さを含んでいます。 この適用範囲への2つの例外があります: まず最初に、時代で作成されたLSA=MaxAgeには、時代分野で始まる署名があります(maxageの上のセクションを見てください)。 2番目に、LSAヘッダーチェックサムは署名の世代のためにゼロに設定されます。 分析するのを助けるために、メッセージ、主要なイド情報、および署名長さの野原はLSAの端に置かれます、署名に続いて。 しかしながら
Murphy, et. al. Experimental [Page 4] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[4ページ]RFC2154OSPF
message must be signed and verified with these fields immediately appended to the LSA data. This can be accomplished either by doing the sign and verify "in parts" (allowed by RSAREF), or by storing the LSA data with appended fields and the LSA signature separately in the link state database (LSDB).
メッセージに署名されて、すぐにこれらの野原をLSAデータに追加している状態で確かめなければなりません。 これは、サインをすることによって達成されて、「部品」(RSAREFによって許容されている)について確かめるか、または別々にリンクに追加された分野とLSA署名でLSAデータを保存することによって、データベース(LSDB)を述べることができます。
When a signed LSA is received, the signature can be verified using the public key of the advertising router contained in the advertising router's PKLSA. If the signature verifies, then the signed LSA is stored for use in routing calculations. If the signature verification fails, the LSA must be discarded. If the identified key is not available (in a PKLSA from the advertising router), then the signed LSA must be stored for a period of time defined by the configurable MAX_TRANSIT_DELAY interval. If the key arrives within this interval, the LSA will be processed then. If the key does not arrive within this interval, the LSA will be discarded. This delay period prevents loss of routing information due to LSAs arriving prior to their associated PKLSAs (which should not normally be the case, but could happen).
署名しているLSAが受け取られているとき、広告ルータのPKLSAに含まれた広告ルータの公開鍵を使用することで署名について確かめることができます。 署名が確かめる、そして、署名しているLSAはルーティング計算における使用のために保存されます。 署名照合が失敗するなら、LSAを捨てなければなりません。 特定されたキーが利用可能でないなら(広告ルータからのPKLSAの)、しばらく構成可能なマックス_TRANSIT_DELAY間隔のそばで定義されていた状態で署名しているLSAを保存しなければなりません。 キーがこの間隔中に届くと、LSAは処理されるでしょう。 キーがこの間隔中に届かないと、LSAは捨てられるでしょう。 この遅れの期間は、LSAsによるルーティング情報の損失が彼らの関連PKLSAs(通常ケースであるはずがありませんが、起こることができた)の前で到着するのを防ぎます。
If the LSA is a Router Links LSA, the router's advertised links must be checked against the allowed address ranges stored in the PKLSA for the advertising router. All network links (link types 2 and 3) must have an IP address that fits in one of the ranges defined by the list of address ranges in the PKLSA (format 7.2). If there is a link that does not fit into one of these ranges, then an error must be logged and the LSA must be discarded. Careful subnetting and corresponding ranges can provide very tight control on what is advertised. A much less restrictive, but still useful, level of control can be obtained by defining allowed address ranges for an area, so that all routers in an area could be configured with the same set. To trivially satisfy this checking, one range with a zero address and mask can be defined that contains all IP addresses.
LSAがRouterリンクスLSAであるなら、広告ルータのためにPKLSAに保存された許容アドレスの範囲に対してルータの広告を出しているリンクをチェックしなければなりません。 すべてのネットワークリンク(リンク型2と3)がPKLSA(形式7.2)にアドレスの範囲のリストによって定義された範囲の1つをうまくはめ込むIPアドレスを持たなければなりません。 これらの範囲の1つに収まらないリンクがあれば、誤りを登録しなければなりません、そして、LSAを捨てなければなりません。 慎重なサブネッティングと対応する範囲は非常にきついコントロールを広告に掲載されていることに提供できます。 許容アドレスの範囲を領域と定義することによって、はるかに制限していませんが、まだ役に立つ管理水準を得ることができます、同じセットで領域のすべてのルータを構成できるように。 この照合、ゼロがある1つの範囲を些細なことに満たすために、すべてのIPアドレスを含むアドレスとマスクは定義できます。
Link State Acknowledgements must be sent for all LSAs that are discarded due to verification failures, that are stored waiting for keys, and that are discarded because they are advertising a link that they are not allowed to advertise.
すべての検証失敗のため捨てられた、キーを待ちながら保存された、それらが広告を出すことができないリンクの広告を出しているので捨てられたLSAsのためにリンク州Acknowledgementsを送らなければなりません。
3.2. Router Public Key LSA (PKLSA)
3.2. ルータ公開鍵LSA(PKLSA)
A Router Public Key LSA (PKLSA) is sent in the same manner as all other LSAs. This LSA contains the router's public key and identifying information that has been certified by a Trusted Entity. The router public key is used to verify signatures produced by this router. There is only one PKLSA stored per router in the LSDB for an area, so the Router Id and LS type can be used to retrieve a given PKLSA. The Router Id is stored in the PKLSA Link State Id field to
他のすべてのLSAsと同じ方法でRouter Public Key LSA(PKLSA)を送ります。 このLSAはTrusted Entityによって公認されたルータの公開鍵と身元が分かる情報を含んでいます。 ルータ公開鍵は、このルータによって起こされた署名について確かめるのに使用されます。 LSDBにルータ単位で領域として保存された1PKLSAしかないので、与えられたPKLSAを検索するのにRouter IdとLSタイプを使用できます。 Router IdはPKLSA Link州Id分野に保存されます。
Murphy, et. al. Experimental [Page 5] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[5ページ]RFC2154OSPF
use in retrieving the PKLSA. Identification information in the certified data (TE Id, Rtr Key Id) can be used to uniquely identify the current router key (section 7.2).
PKLSAを検索する際に、使用します。 唯一、現在のルータキー(セクション7.2)を特定するのに公認されたデータ(TE Id、Rtr Key Id)の識別情報を使用できます。
To assist in parsing the message, the router signature length and the certification length fields are at the end of the LSA, following the signature. The message must be signed and verified with these fields immediately appended to the LSA data. The router signature of the PKLSA is verified in the same manner as other signed LSAs. In addition, the certification must be verified using the referenced TE public key. If either verification fails, for any reason, the PKLSA is discarded.
メッセージ、ルータ署名の長さ、および証明の長さを分析するのを助けるために、分野はLSAの端にあります、署名に続いて。 メッセージに署名されて、すぐにこれらの野原をLSAデータに追加している状態で確かめなければなりません。 PKLSAのルータ署名は他の署名しているLSAsと同じ方法で確かめられます。 さらに、参照をつけられたTE公開鍵を使用することで証明について確かめなければなりません。 検証がどんな理由でも失敗するなら、PKLSAは捨てられます。
A successfully verified PKLSA is stored for use in verifying signed LSAs from the advertising router. For every router that this router is in contact with, there may be one PKLSA stored at any given time. Each PKLSA is uniquely identified by the values (TE Id, Rtr Key Id) in the certified data (format in 7.2). When a PKLSA arrives for a given router, and there is already a PKLSA stored for that router, the PKLSA with the most recent "Create Time" is the one kept.
首尾よく確かめられたPKLSAはLSAsであると署名される検証における使用のために広告ルータから保存されます。 このルータに接触しているあらゆるルータのために、その時々で保存された1PKLSAがあるかもしれません。 公認されたデータ(7.2における形式)の値(TE Id、Rtr Key Id)によって各PKLSAは唯一特定されます。 PKLSAが与えられたルータのために到着して、そのルータのために保存されたPKLSAが既にあるとき、最新であるのがあるPKLSA「時間を作成してください」は保たれたものです。
Whenever groups of LSAs are sent by a router (as when synchronizing databases or sending updates), the PKLSAs must be sent/requested before other LSAs to minimize the time spent processing LSAs that arrive prior to their associated keys. The PKLSA is sent at intervals like all other LSAs, and it is sent immediately if a router obtains a new key to distribute. A PKLSA is sent via OSPF flooding within an OSPF area. PKLSAs are not flooded outside an area with the exception of an Autonomous System Border Router's PKLSAs which must be flooded wherever AS external LSAs are flooded. The decision to flood or not flood can be implemented by checking the router role (Rtr, ABR, ASBR, ABR-ASBR) stored in the certified part of the PKLSA.
ルータでLSAsのグループを送るときはいつも、(いつとして連動しているデータベースか送付アップデート、)、時間を最小にする他のLSAsが彼らの関連キーの前で到着する処理LSAsを費やす前に、PKLSAsを送らなければならないか、または要求しなければならないか。 他のすべてのLSAsのような間隔を置いて、PKLSAを送ります、そして、ルータが分配する新しいキーを入手するなら、すぐに、それを送ります。 OSPF領域の中のOSPF氾濫を通してPKLSAを送ります。 ASの外部のLSAsがどこにあふれても、PKLSAsはAutonomous System Border Routerの水につかるに違いないPKLSAs以外の領域の外にあふれません。 PKLSAの公認された部分に保存されたルータの役割(Rtr、ABR、ASBR、ABR-ASBR)をチェックすることによって、浸水するか、または浸水しないという決定を実装することができます。
A router may flush its keys from routing tables by flooding a PKLSA for that key with age=MaxAge. This is called premature aging of the PKLSA. A key can also be removed from routing tables (superseded) by a PKLSA from the same router, containing a valid certificate for a new key with a more recent Create Time. If a key is superseded by a more recent key it is not necessary to flush the old key with a "MaxAge" PKLSA.
ルータは氾濫時代があるそのキーのためのPKLSA=MaxAgeで経路指定テーブルからキーを洗い流すかもしれません。 これはPKLSAの時期尚早な年をとると呼ばれます。 また、PKLSAは経路指定テーブル(取って代わられる)から同じルータからキーを取り外すことができます、より最近のCreate Timeと共に新しいキーのための有効な証明書を含んでいて。 キーが、より最近のキーによって取って代わられるなら、"MaxAge"PKLSAと共に古いキーを洗い流すのは必要ではありません。
When a new key is received, the LSAs stored in the LSDB that are signed with the old key must be replaced within MAX_TRANSIT_DELAY. if the sending router is working properly. This is because a router distributing a new key sends all of its self-originated LSAs signed with the new key immediately after sending the new PKLSA. (See section 4.4 on Router Key Replacement). To ensure that data signed with an old (possibly subverted) key does not persist in the LSDB in
新しいキーが受け取られているとき、マックス_TRANSIT_DELAYの中で古いキーで署名されるLSDBに保存されたLSAsを取り替えなければなりません。送付ルータであるなら、適切に働くのは、そうですか? これは新しいPKLSAを送る直後新しいキーを分配するルータが新しいキーで署名された自己によって溯源されたLSAsのすべてを送るからです。 (Router Key Replacementの上のセクション4.4を見ます。) 古い(ことによると打倒された)キーで署名されたデータが中でLSDBに固執しないのを確実にするために
Murphy, et. al. Experimental [Page 6] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[6ページ]RFC2154OSPF
error, all LSAs signed with a flushed or superseded key are aged to within MAX_TRANSIT_DELAY of MaxAge. This should allow time for the new LSAs signed with the new key to arrive. If new LSAs do not arrive, or if the key has been flushed and not replaced, then the old LSA data will disappear from the LSDB in a timely fashion.
誤り、aが洗い流されている状態で署名されるすべてのLSAsまたは取って代わられたキーがMaxAgeについてマックス_TRANSIT_DELAYに熟成します。 これは、到着するように新しいキーで署名された新しいLSAsのための時間を許容するべきです。 キーが新しいLSAsが到着しないか、洗い流されて、または取り替えられていないと、古いLSAデータはLSDBから直ちに見えなくなるでしょう。
Link State Acknowledgements must be sent for PKLSAs that are discarded due to verification failures or because the PKLSA was less recent than the one already stored.
検証失敗のためかPKLSAが既に保存されたものほど最近でなかったことので捨てられたPKLSAsのためにリンク州Acknowledgementsを送らなければなりません。
3.3. MaxAge Processing
3.3. MaxAge処理
The age field in the OSPF LSA header is used to keep track of how long a given LSA has been in the system. When the age field reaches MaxAge, a router stops using the LSA for routing, and it floods the MaxAge LSA to make sure that all routers stop using this LSA. In the normal course of the OSPF protocol, an LSA is always replaced by an updated version before the age reaches MaxAge, unless the advertising router fails, or changes in the AS have made the routing information in the LSA inaccurate. An LSA with age=MaxAge is either:
OSPF LSAヘッダーの時代分野は、どれくらい長い与えられたLSAがシステムにあったかに関する道を保つのに使用されます。 時代分野がMaxAgeに達すると、ルータは、ルーティングにLSAを使用するのを止めます、そして、それはすべてのルータが、このLSAを使用するのを止めるのを確実にするMaxAge LSAをあふれさせます。 OSPFプロトコルの常軌では、時代がMaxAgeに達する前にいつもLSAをアップデートされたバージョンに取り替えます、広告ルータが失敗するか、またはLSAのルーティング情報がASにおける変化で不正確になっていない場合。 時代があるLSA=MaxAgeはどちらかです:
(1) being intentionally flushed from the AS by the advertising router
because the information in it is no longer accurate, or
または(1) それの情報がもう正確でないので故意に広告ルータによってASから洗い流される。
(2) an orphan LSA that has aged to MaxAge because its originating
router has not refreshed it at the normal refresh intervals.
(2) 起因するルータが標準でそれをリフレッシュしていないのでMaxAgeに年をとった孤児LSAは間隔をリフレッシュします。
The age field cannot generally be included in the signature, because it must be updated by routers other than the originating router. For the same reason, the age field is not included in the checksum computation. The age field must be protected, because if a faulty router started to age out other router's LSAs, it would effectively deny service to those other routers.
一般に、署名に時代分野を含むことができません、起因するルータ以外のルータでそれをアップデートしなければならないので。 同じ理由から、時代分野はチェックサム計算に含まれていません。 時代分野を保護しなければなりません、不完全なルータが他のルータのLSAsから年をとり始めるなら、事実上それらの他のルータに対するサービスを否定するので。
To protect the age field, the signature must include the age field if and only if the originating router creates an LSA with age=MaxAge. Verification of the signature on a signed LSA must include the age field if and only if the age field value is MaxAge. In this manner, the originating router can flush an LSA, but other routers cannot. An LSA that ages to MaxAge in the LSDB of any router is still discarded by that router, but it is not synchronously flushed from the AS.
そして、時代分野を保護するために、署名が時代分野を含まなければならない、起因するルータが時代=MaxAgeと共にLSAを作成する場合にだけ。 署名しているLSAにおける署名の検証が時代分野を含まなければならない、時代分野価値である場合にだけ、MaxAgeはそうです。 この様に、起因するルータはLSAを洗い流すことができますが、他のルータは洗い流すことができません。 どんなルータのLSDBのMaxAgeへのその時代のLSAもそのルータによってまだ捨てられていますが、それはASから同時洗い流されません。
Murphy, et. al. Experimental [Page 7] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[7ページ]RFC2154OSPF
An LSA will be removed from a router's Link State Database in one of two ways: 1) the router receives a version of the LSA with the age field set to MaxAge and a valid signature that covers the age field, or 2) the LSA incrementally reaches MaxAge while it is stored by the router.
LSAはルータのLink州Databaseから2つの方法の1つで取り外されるでしょう: 1) ルータがMaxAgeに設定された時代分野と時代分野をカバーする有効な署名でLSAのバージョンを受けるか、または2は)LSAを受けます。増加して、範囲MaxAgeはそれである間、ルータによって保存されます。
If a standard OSPF V2 router goes down, an LSA from that router will age in the LSDBs of each remaining router until it reaches MaxAge somewhere. As soon as it reaches MaxAge in some router's LSDB it is flooded, and this causes it to be flushed from the AS in a synchronized fashion. If router running OSPF with digital signatures goes down, its signed LSAs will be aged out by each remaining router individually. This will slow database convergence but the databases will still converge, and a fairly obvious security hole will be closed.
標準のOSPF V2ルータが落ちると、MaxAgeにどこかに届くまで、そのルータからのLSAはそれぞれの残っているルータのLSDBsで年をとるでしょう。 何らかのルータのLSDBでMaxAgeに達するとすぐに、それは水につかっています、そして、これで、ASから連動しているファッションでそれを洗い流します。 デジタル署名でOSPFを実行するルータが落ちると、署名しているLSAsはそれぞれの残っているルータによる外で個別に熟成するでしょう。 それでも、データベースは一点に集まるでしょう、そして、これはデータベース集合を遅くするでしょうが、かなり明白なセキュリティーホールは閉じられるでしょう。
4. Key Management
4. Key Management
4.1. Identifying Keys
4.1. キーを特定します。
4.1.1. Identifying Router Keys and PKLSAs
4.1.1. ルータキーとPKLSAsを特定します。
A router key is identified by the Router Id, and the identifiers associated with the particular key in its certificate: TE Id and Router Key Id. All three of these values are stored in a PKLSA (format in 7.1). The Router Id is the standard LSA header Advertising Router. The (TE Id, Rtr Key Id) are stored in the PKLSA certified data. The TE Id is a number assigned to a Trusted Entity that must uniquely identify one TE in the AS. The TE Id in a certificate identifies the TE that produced the certificate. The Rtr Key Id is associated with a key by the Trusted Entity that produced the certificate. The Trusted Entity must produce a stream of Rtr Key Ids for one router such that the router will not re-use a key id until all references to the last key having that id are gone from the AS. If a key is re-played, or re-used too soon, the Create Time in the key certification will determine which key is current. Rtr Key Ids do not have to be sequential.
ルータキーは証明書の特定のキーに関連しているRouter Id、および識別子によって特定されます: Teイドとルータの主要なアイダホ州 これらのすべての3つの値がPKLSA(7.1における形式)に保存されます。 Router Idは標準のLSAヘッダーAdvertising Routerです。 (TE Id、Rtr Key Id)はデータであることが公認されたPKLSAに保存されます。 TE Idは唯一ASの1TEを特定しなければならないTrusted Entityに割り当てられた数です。 証明書のTE Idは証明書を製作したTEを特定します。 Rtr Key Idは証明書を製作したTrusted Entityでキーに関連しています。 そのイドを持っている最後のキーのすべての参照がASからなくなるまでルータが主要なイドを再使用しないで、Trusted Entityは1つのルータのためにRtr Key Idsの流れを起こさなければなりません。 キーが再演されるか、またはあまりに早く再使用されると、主要な証明におけるCreate Timeは、どのキーがよく見られるかを決定するでしょう。 Rtr Key Idsは連続している必要はありません。
4.1.2. Identifying TE Public Keys
4.1.2. Te公開鍵を特定します。
Each TE public key has an associated TE Id, TE Key Id. The combination of (TE Id, TE Key Id) uniquely identifies one TE public key in the AS. The TE Id is a number assigned to a Trusted Entity
それぞれのTE公開鍵には、関連TE Id、TE Keyアイダホ州があります。 組み合わせ、(TE Id、TE Key Id)は唯一ASの1つのTE公開鍵を特定します。 TE IdはTrusted Entityに割り当てられた数です。
Murphy, et. al. Experimental [Page 8] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[8ページ]RFC2154OSPF
that uniquely identifies one TE in the AS. The TE Key Id must identify one particular key for a TE at any given time. The TE Key Id distinguishes between a new key and an old key for the same TE. The TE Key Id also differentiates between keys for different signature algorithms if one TE serves multiple algorithms. Each TE can have at most one current key per signature algorithm.
それは唯一ASの1TEを特定します。 TE Key Idはその時々でTEのために1個の特定のキーを特定しなければなりません。 TE Key Idは同じTEのために新しいキーと古いキーを見分けます。 また、1TEが複数のアルゴリズムに役立つなら、TE Key Idは異なった署名アルゴリズムのためにキーを区別します。各TEは最も1つに署名アルゴリズムあたり主要な電流を持つことができます。
There can be multiple TE keys stored on each router. A TE public key is used to verify the certificates issued by other routers, and in an AS with several TEs, any given router may need several TE public keys. TE Key Ids do not have to be used sequentially, and they can be re-used. There is no timestamp for TE keys because these are not certified.
各ルータに保存された複数のTEキーがあることができます。 TE公開鍵は他のルータによって発行された証明書について確かめるのに使用されます、そして、数個のTEsとASでは、どんな与えられたルータもいくつかのTE公開鍵を必要とするかもしれません。 TE Key Idsを連続して使用する必要はありません、そして、彼らを再使用できます。 これらが公認されないので、TEキーのためのタイムスタンプが全くありません。
It is the responsibility of Configuration Management to ensure that TE Key Ids are not re-used before all references to a previously used key with the same (TE Id, TE Key Id) are gone from the AS, that a given (TE Id, TE Key Id) on one router identifies the same key as it does on any other router, and that the rules for TE Key Replacement (section 4.5) are followed.
同じくらい(TE Id、TE Key Id)がある以前中古のキーのすべての参照がASからなくなる前にTE Key Idsが再使用されていなくて、あるルータに関する当然のこと(TE Id、TE Key Id)がいかなる他のルータでも特定するように同じキーを特定して、TE Key Replacement(セクション4.5)のための規則が従われているのを保証するのは、Configuration Managementの責任です。
4.1.3. Key to use for Signing
4.1.3. Signingに使用するために、主要です。
A router is configured with a pair of keys. The private key is protected from disclosure and is used for signing. The public key is flooded in a PKLSA and is used for verifying signatures. A router may have one key per area to use for signing at any given time. A router may use the same key for several or all areas.
ルータは1組のキーで構成されます。 秘密鍵は、公開から保護されて、署名に使用されます。 公開鍵は、PKLSAで水につかって、署名について確かめるのに使用されます。 ルータには、1その時々で署名するのに使用する領域あたり1個のキーがあるかもしれません。 ルータは数個かすべての領域に同じキーを使用するかもしれません。
4.1.4. Key to use for Verification
4.1.4. Verificationに使用するために、主要です。
There are three uses of signature verification in this design:
このデザインにおける、署名照合の3つの用途があります:
(1) The signature in a signed LSA (format in 7.3) can be verified
with the public key distributed by the advertising router in a
Public Key LSA. A signed LSA contains the (TE Id, Rtr Key Id) of
the key used to sign it. The signed LSA's Advertising Router Id
is used to retrieve the router's PKLSA , and the (TE Id, Rtr Key
Id) indicates if the router key in the PKLSA is the same as the
one used to generate the signature.
(1) 公開鍵がPublic Key LSAで広告ルータによって分配されている状態で、署名しているLSA(7.3における形式)の署名について確かめることができます。 署名しているLSAが含んでいる、(TE Id、Rtr Key Id) それに署名するのに使用されるキーについて。 そして、署名しているLSAのAdvertising Router IdがルータのPKLSAを検索するのに使用される、ものが以前はよく署名を生成していたとき、(TE Id、Rtr Key Id)は、PKLSAで主要なルータが同じであるかどうかを示します。
(2) The router's signature in a PKLSA (format in 7.1) is verified
with the public key contained in that PKLSA.
(2) 公開鍵がそのPKLSAに含まれている状態で、PKLSA(7.1における形式)のルータの署名は確かめられます。
Murphy, et. al. Experimental [Page 9] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[9ページ]RFC2154OSPF
(3) The PKLSA contains data certified with a signature generated
by a TE. The PKLSA certified data contains the (TE Id, TE Key
Id) for the TE key that can be used to verify the certificate
(format in 7.2). TE public keys must be configured on each
router.
(3) PKLSAは署名がTEによって生成されている状態で公認されたデータを含んでいます。 公認されたデータが含むPKLSA、(TE Id、TE Key Id) TEキーに関しては、証明書(7.2における形式)について確かめるのにそれを使用できます。 各ルータでTE公開鍵を構成しなければなりません。
4.2. Trusted Entity (TE) Requirements
4.2. 信じられた実体(Te)要件
This design does not specify how the Trusted Entity (TE) must be implemented, where it must reside, or how it must communicate with routers. There are several very different possible approaches to the implementation of a Trusted Entity (e.g., an offline system with distribution of keys by floppy or secure e-mail, an online automated key distribution center, etc.) This design does mandate certain requirements for what a Trusted Entity must do. A Trusted Entity must generate a certificate for each signing router that contains individualized information about that router (format in 7.2) and is signed with the Trusted Entity private key. The Trusted Entity must have a unique TE Id for itself, it must create a Rtr Key Id for each router key that is unique for the given Router for this TE at this time, and it must timestamp certificates with a Create Time that is consistent for itself and for any other Trusted Entities operating in the AS. Note: routers do not have to be time-synched, but TEs do. Create Time is used by routers as a relative measure to determine which key is more recent.
このデザインは、どのように、Trusted Entity(TE)を実装しなければならないか、そして、どこに住んでいなければならないか、そして、またはそれがルータでどのように交信しなければならないかを指定しません。 Trusted Entity(例えば、フロッピーディスクの、または、安全なメールによるキーの分配があるオフライン・システム、オンライン自動化された主要な配送センターなど)の実装へのいくつかの非常に異なった可能なアプローチがあります。 このデザインはTrusted Entityがしなければならないことのためのある要件を強制します。 Trusted Entityはそのルータ(7.2における形式)の個性化された情報を含んでいて、Trusted Entity秘密鍵を契約されるそれぞれの署名ルータのための証明書を作らなければなりません。 Trusted Entityにはそれ自体のためのユニークなTE Idがなければなりません、そして、それぞれの与えられたRouterに、このときこのTEのためにユニークなルータキーのためにRtr Key Idを作成しなければなりません、そして、それはASで作動するそれ自体といかなる他のTrusted Entitiesにおいても、一貫したCreate Timeがあるタイムスタンプ証明書を作成しなければなりません。 以下に注意してください。 ルータは時間によってsynchedされている必要はありませんが、TEsはsynchedされる必要はありません。 どのキーを決定するか相対的な程度が、より最近ので、ルータで使用されるTimeを作成してください。
The TE Public key, TE Id, TE Key Id and Signature Algorithm must be made available to each router processing certificates from this TE.
このTEから証明書を処理する各ルータはTE Publicキー、TE Id、TE Key Id、およびSignature Algorithmを入手しなければなりません。
A TE can theoretically create certificates for more than one signature algorithm. The TE key and the router public key certified do not have to be of the same signature algorithm.
TEは理論的に1つ以上の署名アルゴリズムのための証明書を作成できます。 TEキーと公認されたルータ公開鍵は同じ署名アルゴリズムのものである必要はありません。
There can be more than one TE in an AS but the TE Id must identify a unique TE.
1TEがASにあることができますが、TE IdはユニークなTEを特定しなければなりません。
4.3. Scope for Keys and Signature Algorithms
4.3. キーと署名アルゴリズムのための範囲
The concept of "scope" relates to Router Keys, TE Keys, and Signature Algorithms.
「範囲」の概念はRouterキーズ、TEキーズとSignature Algorithmsに関連します。
(1) The scope of a PKLSA and therefore a router key, is defined to
be the set of routers that will receive and store that PKLSA in
the course of OSPF flooding. A router produces a PKLSA for each
attached area. In a router with more than one area, the PKLSAs
for each area may match, or each may contain a different key.
The scope of PKLSA for an internal router is all the routers in
that area. An ABR has multiple PKLSAs, each having a scope of
PKLSAとしたがって、ルータの範囲がOSPFの間にそのPKLSAを受けて、保存するルータのセットが氾濫であったなら合わせて、定義される(1)。 ルータはそれぞれの付属領域にPKLSAを生産します。 1つ以上の領域があるルータでは、各領域へのPKLSAsは合うかもしれませんか、またはそれぞれが異なったキーを含むかもしれません。 内部のルータのためのPKLSAの範囲はすべて、その領域のルータです。 それぞれaを持っているのは、ABRには複数のPKLSAsがあるのを見ます。
Murphy, et. al. Experimental [Page 10] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[10ページ]RFC2154OSPF
one attached area. The scope of an ASBR's PKLSA is the same as
the scope of the ASBRs ASEs - all the routers in all the non-stub
areas in the AS. An ASBR that is an ABR produces multiple PKLSAs
that each have a scope of all the routers in all the non-stub
areas in the AS. (This last case results in some situations that
require special management - section 6)
1つは領域を付けました。 ASBRのPKLSAの範囲はASBRs ASEsの範囲と同じです--ASのすべての非スタッブ領域のすべてのルータ。 ABRであるASBRはASのすべての非スタッブ領域にそれぞれすべてのルータの範囲を持っている複数のPKLSAsを生産します。 (この最後のケースは特別な管理を必要とするいくつかの状況をもたらします--セクション6)
(2) The scope of a TE key is defined to be the set of routers that are
configured with this key. If a system is configured properly,
then a TE public key will be configured on all the routers that
will receive PKLSAs certified by that TE key. The minimum scope
for a TE key is an area. If one router distributes a key
certified with a given TE key, then all the routers in the area
must be able toverify the certificate. A TE Key certifying an
ASBRs key must have a scope of all non-stub areas in the AS. If
the TE key is not on some router that receives PKLSAs certified by
that TE key, then those PKLSAs and all the LSAs that require them
will be discarded. A TE key gets to all the routers in its scope
via out-of-band configuration.
(2) TEキーの範囲は、このキーで構成されるルータのセットになるように定義されます。 システムが適切に構成されると、TE公開鍵はそのTEキーによって公認されたPKLSAsを受けるすべてのルータで構成されるでしょう。 TEキーのための最小の範囲は領域です。 あるルータがaで公認されたキーを分配するなら、次に、キー、その領域のすべてのルータができるに違いないという当然のことのTEは証明書をtoverifyします。 ASBRsが主要であることを公認するTE KeyはASにすべての非スタッブ領域の範囲を持たなければなりません。 TEキーがそのTEキーによって公認されたPKLSAsを受ける何らかのルータにないと、彼らを必要とするそれらのPKLSAsとすべてのLSAsが捨てられるでしょう。 TEキーはバンドで出かけることを通した範囲構成ですべてのルータを始めます。
(3) The scope of a signature algorithm is defined to be the set of
routers that are capable of verifying the given algorithm's
signatures. The minimum scope for a signature algorithm is an
area. All routers in an area must be able to verify any signature
algorithm used for signing by any router in the area. The
algorithm used to certify an ASBRs key must have a scope of all
non-stub areas in the AS if the ASEs are to be accessible
everywhere (see section 6). If a signature algorithm is not
available to verify an LSA, then the LSA must be discarded. If a
signature algorithm is not available to verify the certification
in a PKLSA, then the PKLSA must be discarded.
(3) 署名アルゴリズムの範囲は、与えられたアルゴリズムの署名について確かめることができるルータのセットになるように定義されます。 署名アルゴリズムのための最小の範囲は領域です。 領域のすべてのルータがその領域のどんなルータでも署名するのに使用されるどんな署名アルゴリズムも確かめることができなければなりません。 ASEsがいたる所でアクセスしやすいつもりであるなら(セクション6を見てください)、ASBRsが主要であることを公認するのに使用されるアルゴリズムはASにすべての非スタッブ領域の範囲を持たなければなりません。 署名アルゴリズムがLSAについて確かめるために利用可能でないなら、LSAを捨てなければなりません。 署名アルゴリズムがPKLSAで証明について確かめるために利用可能でないなら、PKLSAを捨てなければなりません。
4.4. Router Key Replacement
4.4. ルータの主要な交換
Router keys should be changed periodically, and immediately if a key is found to be compromised. The regular period for changing a key is some locally determined function of the size of the key and the level of security needed.
キーが感染されるのがわかっているなら、すぐに、定期的にルータキーを変えるべきです。 キーを変えるための通常の期間はキーのサイズと必要であるセキュリティのレベルの何らかの局所的に決定している関数です。
Each router can have ONE valid key per area at any given time. Restricting the number of keys at a given time to one key per router per area allows key replacement to also serve the purpose of key revocation, without having a revocation list and without routers having synchronized time. Each key for the router/area revokes the last key, provided the "new" key has a more recent Create Time than the last key. The Create Time in each certificate is used to prevent an old key from being reused, but this Create Time is used only for comparing the relative ages of certificates, and does not require the
各ルータはその時々で1領域あたりのONEの有効なキーを持つことができます。 また、領域単位で一時に1ルータあたり1個のキーのキーの数を制限するのに、主要な交換は取消しリストとルータなしでそうしていなくて持っている主要な取消しの目的に連動している時間に勤めることができます。 ルータ/領域への各キーは最後のキーを取り消します、「新しい」キーに最後のキーより最近のCreate Timeがあるなら。 各証明書のCreate Timeは再利用されています、このCreate Timeだけが証明書の相対年代を比較するのにだけ使用されるということであるので古いキーを防ぐのに使用されて、必要ではありません。
Murphy, et. al. Experimental [Page 11] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[11ページ]RFC2154OSPF
router to run a time synchronization protocol itself. An ABR can use the same key for all it's attached areas, or it can have a unique key for each area. This allows an AS to be managed by area with each area potentially having a different TE, signature algorithm, key size, and/or key.
時間同期化プロトコル自体を実行するルータ。 ABRがそれの付属領域に同じキーを使用できますか、またはそれは各領域へのユニークキーを持つことができます。 これは、異なったTE、署名アルゴリズム、主要なサイズ、そして/または、キーを持ちながら、ASが各領域がある領域によって潜在的に管理されるのを許容します。
When a new key replaces an old key, the router must quickly replace LSAs signed with the old key with LSAs signed with the new key. To change a router key the following steps must be followed:
新しいキーが古いキーを取り替えるとき、ルータはすばやく古いキーで署名されたLSAsを新しいキーで署名されるLSAsに取り替えなければなりません。 ルータキーを変えるために、以下の方法に従わなければなりません:
(1) A valid certificate for the new key must be obtained for the
router.
(1) 新しいキーのための有効な証明書をルータに入手しなければなりません。
(2) The router builds and sends a new PKLSA with the new certificate.
(2) ルータは、新しい証明書がある新しいPKLSAを造って、送ります。
(3) The router signs each self-originated LSA with the new key and
sends them.
(3) ルータは、それぞれの自己によって溯源されたLSAに新しいキーで署名して、それらを送ります。
When a PKLSA is received:
PKLSAが受け取られているとき:
(1) If the PKLSA's age = MaxAge, remove the PKLSA from the LSDB and
age LSAs signed with this key to be MaxAge - MAX_TRANSIT_DELAY,
if they were not already older than this. This is a way to get
rid of a key that should no longer be used.
(1) PKLSAの時代がMaxAgeと等しいなら、このキーがLSAsが契約したLSDBと時代であるのからPKLSAを取り外してください。MaxAge--マックス_TRANSIT_DELAY彼らがこれより既に古くなかったなら。 これはもう使用されるべきでないキーを取り除く方法です。
(2) If the PKLSA is a refresh LSA for an existing key, update the
LSDB.
(2) PKLSAがaであるなら、既存のキーのためにLSAをリフレッシュしてください、そして、LSDBをアップデートしてください。
(3) If the PKLSA contains a different key than the one currently
stored for this router, compare the certificate Create Time. If
the PKLSA key is less recent, discard it. If the PKLSA key is
more recent, install it in the LSDB and remove the old key from
the LSDB. If an old key was deleted from the LSDB, age LSAs
signed with this key to be MaxAge - MAX_TRANSIT_DELAY, if they
were not already older than this.
(3) PKLSAが現在このルータのために保存されているものと異なったキーを含むなら、証明書Create Timeを比較してください。 PKLSAキーがそれほど最近でないなら、それを捨ててください。 PKLSAキーが、より最近なら、それをLSDBにインストールしてください、そして、LSDBから古いキーを取り外してください。 古いキーがLSDBから削除されたなら、時代LSAsは、このキーがMaxAgeであることを契約しました。--マックス_TRANSIT_DELAY彼らがこれより既に古くなかったなら。
4.5. Trusted Entity Key Replacement
4.5. 信じられた実体主要な交換
It is necessary to change a TE public key periodically. It is recommended that the TE public key be relatively large, so that it does not frequently require replacement. A router may store multiple TE public keys. Each key is uniquely identified by TE Id and TE Key Id. TE keys are used to verify certificates received from other routers in their PKLSAs. When a router sends a new certificate signed with a new TE Key, all the routers that receive the PKLSA containing the certificate must have that new TE Key in order to verify, store, and use that PKLSA. Management of TE public keys is done outside the OSPF protocol, and a method is suggested, but not
定期的にTE公開鍵を変えるのが必要です。 TE公開鍵が比較的大きいのが、お勧めであるので、それは頻繁に交換を必要としません。 ルータは複数のTE公開鍵を保存するかもしれません。 各キーはTE IdとTE Keyアイダホ州によって唯一特定されます。 TEキーは、それらのPKLSAsの他のルータから受け取られた証明書について確かめるのに使用されます。 ルータが新しいTE Keyを契約された新しい証明書を送るとき、証明書を含むPKLSAを受けるすべてのルータが、そのPKLSAを確かめて、保存して、使用するためにその新しいTE Keyを持たなければなりません。 OSPFプロトコルの外でTE公開鍵を管理しています、そして、しかし、メソッドを示します。
Murphy, et. al. Experimental [Page 12] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[12ページ]RFC2154OSPF
mandated by this design. Initially all routers must be configured with the TE Keys they will need to verify the certificates they will receive. To prevent use of a (possibly compromised) TE Key, that key must be replaced by a new (possibly null) TE Key having the same TE Id and signature algorithm. A compromised or faulty router can continue using certificates signed with the old TE key, but none of the properly configured routers will be able to verify them.
このデザインで、強制されます。 初めは、彼らが彼らが受け取る証明書について確かめる必要があるTEキーズですべてのルータを構成しなければなりません。 (ことによると感染されます)のTE Keyの使用を防ぐために、そのキーを同じTE Idと署名アルゴリズムを持っている新しい(ことによるとヌルの)TE Keyに取り替えなければなりません。 感染しているか不完全なルータは、古いTEキーで署名された証明書を使用し続けることができますが、適切に構成されたルータのいずれもそれらについて確かめることができないでしょう。
Changing a TE public key presents a design challenge. When a TE Public Key is changed, all the certificates depending on that key must also change. The router keys in the certificates may or may not be changed at the same time. When the TE key and certificates change, all PKLSAs depending on these must be reissued. In order to verify these new certificates, all routers receiving the new PKLSAs must have the new TE Public Key. So, the TE key replacement must be a synchronized event. Routers are not required to have synchronized clocks. The TE public key may well be distributed to the routers via an out-of-band mechanism (like a smart-card reader or other sneaker- net method). It is not reasonable to require that all the routers obtain the TE public key at the same time. There are probably several methods for meeting these requirements. The method tested in our implementation is as follows:
TE公開鍵を変えると、デザイン挑戦は提示されます。 また、TE Public Keyを変えるとき、そのキーによるすべての証明書が変化しなければなりません。 同時に、証明書のルータキーを変えるかもしれません。 TEキーと証明書が変化するとき、これらによるすべてのPKLSAsを再発行しなければなりません。 これらの新しい証明書について確かめるために、新しいPKLSAsを受けるすべてのルータが新しいTE Public Keyを持たなければなりません。 それで、TEの主要な交換は連動しているイベントであるに違いありません。 ルータは、時計を連動させたのに必要ではありません。 バンドで出ているメカニズム(スマートカードリーダーや他のスニーカー純額法のような)でTE公開鍵はたぶんルータに分配されるでしょう。 すべてのルータが同時にTE公開鍵を得るのが必要であるのは妥当ではありません。 たぶん、これらの必要条件を満たすためのいくつかのメソッドがあります。 私たちの実装でテストされたメソッドは以下の通りです:
(1) Define a period of time needed to get the new TE key on all
routers. This could be minutes, hours, even days depending on
how the distribution is accomplished. This time period is a
configuration value for each router (TE_KEY_DIST_INT) and must be
the same for all routers sharing a TE.
(1) すべてのルータで主要な新しいTEを手に入れるのが必要であることで、期間を定義してください。 日間、分配がどう優れているかによりさえして、これは数分であるかもしれません。 この期間は、各ルータ(TE_KEY_DIST_INT)のための構成値であり、TEを共有するすべてのルータに、同じであるに違いありません。
(2) Install a new TE key and associated certificates (if there are
any) on each router. Signal the router code when the new TE key
is available to be accessed.
(2) 新しいTEキーと関連証明書(いずれかあれば)を各ルータにインストールしてください。 新しいTEキーがアクセスされているために利用可能であるときにはルータコードに合図してください。
(3) The router sets a timer for the TE_KEY_DIST_INT. The router
sets a flag indicating the presence of a new TE key.
(3) ルータはTE_KEY_DIST_INTにタイマを設定します。 ルータは、旗が新しいTEキーの存在を示すように設定します。
(4) For each router, if the timer goes off:
各ルータのための(4)タイマが発射されるなら
Access the new TE key.
If there are new certificates, build and send a new PKLSA.
Age all PKLSAs in the LSDB certified by the old TE Key
to MaxAge - MAX_TRANSIT_DELAY.
新しいTEキーにアクセスしてください。 新しい証明書があれば、新しいPKLSAを造って、送ってください。 古いTE KeyによってMaxAgeに公認されたLSDBのすべてのPKLSAsの年をとってください--マックス_TRANSIT_DELAY。
Murphy, et. al. Experimental [Page 13] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[13ページ]RFC2154OSPF
(5) For each router, if a PKLSA certified by a new TE key comes in
before the timer goes off:
(5) 各ルータのために、新しいTEキーによって公認されたPKLSAが以前入るなら、タイマは発射されます:
If the new TE key cannot be accessed, discard the PKLSA and
log an ERROR.
Access the new TE key.
Process the received PKLSA.
If there are new certificates, build and send a new PKLSA.
Age all PKLSAs in the LSDB certified by the old TE key
to MaxAge - MAX_TRANSIT_DELAY.
新しいTEキーにアクセスできないなら、PKLSAを捨ててください、そして、ERRORを登録してください。 新しいTEキーにアクセスしてください。 容認されたPKLSAを処理してください。 新しい証明書があれば、新しいPKLSAを造って、送ってください。 MaxAgeに主要な古いTEによって公認されたLSDBのすべてのPKLSAsの年をとってください--マックス_TRANSIT_DELAY。
The effect of this method is that it takes a predetermined interval of time to change the TE public key. That interval is the amount of time from the installation of the new TE key on the FIRST router installed, until the time that router reads the key in. By the time the first router reads the key in, all other routers should have the new key. If some router does not get the new TE key in time, it will be unable to verify all the new PKLSAs that are received. It will log error messages and route data based on it's old database until those LSAs time out. The simple way to fix a router in this error condition is to load the new TE key and restart the router. If this error is expected to occur, and restarting the router is not acceptable, then some special purpose code will be needed to read in the TE key after it has been otherwise distributed, and do database synchronization to catch up with the other routers.
このメソッドの効果はTE公開鍵を変える時間の予定された間隔でかかるということです。 その間隔はルータがキーを読む時間までインストールされたFIRSTルータで主要な新しいTEのインストールからの時間です。 最初のルータが主要であるのと、もう片方を読む時までには、ルータには、新しいキーがあるべきです。 何らかのルータが時間内に主要な新しいTEを手に入れないと、すべての受け取られていている新しいPKLSAsについて確かめることができないでしょう。 それはエラーメッセージを登録するでしょう、そして、それらのLSAsタイムアウトまでそれに基づくルートデータは古いデータベースです。 このエラー条件におけるルータを修理する簡単な方法は、新しいTEキーを積み込んで、ルータを再開することです。 この誤りが起こると予想されて、ルータを再開するのが許容できないと、何らかの専用コードが、それが別の方法で分配された後にTEキーで読んで、他のルータに追いつくためにデータベース同期をするのに必要でしょう。
The group of routers that need the new TE key are all the routers in the scope of that Trusted Entity.
新しいTEキーを必要とするルータのグループはすべて、そのTrusted Entityの範囲のルータです。
4.6. Flexible Cryptographic Environments
4.6. フレキシブルな暗号の環境
It is likely that an AS will have one cryptographic environment in use throughout the AS, with one trusted entity, one signature algorithm in use, and one key in use per router. To allow those cases where this is not true, multiple signature algorithms, multiple trusted entities, and multiple keys per router are allowed.
ASには、AS中で使用中の1つの暗号の環境がありそうでしょう、1つの信じられた実体、使用中の1つの署名アルゴリズム、および1ルータあたり使用中の1個のキーで。 これが本当でないそれらのケースを許容するために、複数の署名アルゴリズム、複数の信じられた実体、および複数の1ルータあたりのキーが許容されています。
4.6.1. Multiple Signature Algorithms
4.6.1. 複数の署名アルゴリズム
It is possible to support multiple signature algorithms. Each router and TE key has a signature algorithm associated with it. All routers sending a key with a given algorithm must be capable of generating signatures of that kind, and all routers receiving keys with a given algorithm must be able to verify the signatures. If a router receives an LSA signed with a signature algorithm that it does not support, the LSA must be discarded. LSAs that cannot be verified by a router are not flooded by that router. When using multiple signature algorithms, the scope of each algorithm must be determined
複数の署名がアルゴリズムであるとサポートするのは可能です。それぞれのルータとTEキーには、それに関連している署名アルゴリズムがあります。 与えられたアルゴリズムでキーを送るすべてのルータがその種類の署名を生成することができなければなりません、そして、与えられたアルゴリズムでキーを受けるすべてのルータが署名について確かめることができなければなりません。 ルータがそれがサポートしない署名アルゴリズムを契約されたLSAを受けるなら、LSAを捨てなければなりません。 ルータが確かめることができないLSAsはそのルータによってあふれさせられません。 複数の署名アルゴリズムを使用するとき、それぞれのアルゴリズムの範囲は断固としているに違いありません。
Murphy, et. al. Experimental [Page 14] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[14ページ]RFC2154OSPF
(see section 4.3), and routers must be configured with support for these algorithms accordingly.
(セクション4.3を見ます)、これらのアルゴリズムのサポートでそれに従って、ルータを構成しなければなりません。
If an Area supports two signature algorithms and is to have full connectivity, some routers may sign with algorithm A and others with algorithm B, but all routers in the area must be able to verify signatures for A and B. In an AS that is divided into areas, it is possible for each area to have a different signature algorithm. The ABR connecting two areas would have to support both algorithms, but the internal routers in a given area would only have to know one algorithm.
Areaが2つの署名アルゴリズムをサポートして、完全な接続性を持つつもりであるなら、いくつかのルータがAのための署名について確かめることができて、B.Inが領域に分割されるASであったに違いないならアルゴリズムAとしかし、アルゴリズムB、すべてのルータがその領域にある他のものと契約するかもしれなくて、各領域には異なった署名アルゴリズムがあるのは、可能です。 2つの領域をつなげるABRは両方のアルゴリズムをサポートしなければならないでしょう、しかし、与えられた領域の内部のルータが1つのアルゴリズムを知るだけでよいでしょう。
ASBRs present a problem for this sort of division. ASEs flood throughout the non-stub areas of an AS. Any router that cannot verify an ASE will discard it without flooding. So, to have access to an ASE, a router, and all the routers in the flooding path, must support the algorithm used by the ASBR. One way around these difficulties is to have a lowest-common-denominator algorithm that is used for signing by all ASBRs and is supported for verification throughout the AS in addition to other algorithms used. Another approach is to place ASBRs on the backbone, and configure all areas using a signature algorithm different from the ASBR to have a default route to the backbone. A combined approach will allow an ASBR to be in a non-backbone area if it uses a signature algorithm supported on the backbone, and the areas using different signature algorithms are configured with a default to the backbone. There are special limitations in the case of a router that is an ABR and also an ASBR: see section 6.
ASBRsはこの種類の分割に問題を提示します。 ASEsはASの非スタッブ領域中で浸水します。 ASEについて確かめることができないどんなルータも氾濫なしでそれを捨てるでしょう。 それで、ASEに近づく手段を持つために、ルータ、および氾濫経路のすべてのルータがASBRによって使用されたアルゴリズムをサポートしなければなりません。 これらの困難の周りの1つの方法はAS中に使用される他のアルゴリズムに加えてすべてのASBRsで署名するのにおいて使用されていて、検証のためにサポートされる最小公分母アルゴリズムを持つことです。 別のアプローチは、デフォルトルートを持つASBRからバックボーンまで異なった状態でバックボーンにASBRsを置いて、署名アルゴリズムを使用するすべての領域を構成することです。 バックボーンでサポートされた署名アルゴリズムを使用すると、ASBRが非バックボーン領域に結合したアプローチであるでしょう、そして、異なった署名アルゴリズムを使用する領域はデフォルトによってバックボーンに構成されます。 ABRとまたASBRであるルータの場合には特別な制限があります: セクション6を見てください。
There is currently only one signature algorithm (RSA_MD5) defined for use by this design. The RSA algorithm is defined in PKCS #1 [9] and the signature and key formats used by this design are defined in RFC2065 [10].
現在、使用のためにこのデザインによって定義された1つの署名アルゴリズム(RSA_MD5)しかありません。 RSAアルゴリズムはPKCS#1[9]で定義されます、そして、このデザインによって使用される署名と主要な書式はRFC2065[10]で定義されます。
4.6.2. Multiple Trusted Entities
4.6.2. 複数の信じられた実体
It is possible to have multiple Trusted Entities in an AS. Each TE has a unique TE identifier. Every router receiving PKLSAs certified by a given TE must have that TE's public key. If a router receives a PKLSA certified by a TE for which it does not have a public key, the PKLSA must be discarded. When using multiple TEs, the scope of each TE must be determined (see section 4.3), and routers in this scope must be configured with the TE key.
ASに複数のTrusted Entitiesを持っているのは可能です。 各TEには、ユニークなTE識別子があります。 PKLSAsが与えられたTEで公認したあらゆるルータ受信がそのTEの公開鍵を持たなければなりません。 ルータがそれが公開鍵を持っていないTEによって公認されたPKLSAを受けるなら、PKLSAを捨てなければなりません。 複数のTEsを使用するとき、それぞれのTEの範囲は断固としているに違いありません、そして、(セクション4.3を見てください)TEキーでこの範囲のルータを構成しなければなりません。
Murphy, et. al. Experimental [Page 15] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[15ページ]RFC2154OSPF
4.6.3. Multiple Keys for One Router
4.6.3. 1つのルータのための複数のキー
An ABR may have one key for each attached area. These keys may differ in size, algorithm and/or certifying TE. Generally, each key will have a "scope" of the attached area, and there will be no conflict between keys.
ABRには、それぞれの付属領域あたり1個のキーがあるかもしれません。 これらのキーはサイズ、アルゴリズム、そして/または、TEを公認するのにおいて異なるかもしれません。 一般に、各キーには、付属領域の「範囲」があるでしょう、そして、キーの間には、闘争が全くないでしょう。
There are special limitations in the case of a router that is an ABR and also an ASBR: see section 6.
ABRとまたASBRであるルータの場合には特別な制限があります: セクション6を見てください。
5. Compatibility with Standard OSPF V2
5. 標準のOSPF V2との互換性
OSPF with Digital Signatures is compatible with standard OSPF V2 in an autonomous system. Within an AS, there may be "signed" areas and "unsigned" areas. There will never be both signed and unsigned LSAs used in any one area. Each area will have an environment flag indicating whether it is "signed" or "unsigned". The environment flag is a per area configuration value for the router. The signed areas must contain all routers running OSPF with Digital Signatures, and the unsigned areas contain routers running standard OSPF V2 code (or OSPF with Digital Signatures with all areas set to be unsigned). An area border router connecting a signed to an unsigned area must be running OSPF with Digital Signatures with one area set to be unsigned.
Digital SignaturesとOSPFは自律システムで標準のOSPF V2と互換性があります。 ASの中では、領域と「未署名」の領域は「署名されるかもしれません」。 署名しているものとどんな領域でも使用される同様に未署名のLSAsが決してないでしょう。 各領域で、環境旗は、それが「署名されます」かそれとも「未署名であるか」を示すでしょう。 環境旗はルータのための領域構成価値あたりaです。 署名している領域はDigital SignaturesとOSPFを実行するすべてのルータを含まなければなりません、そして、未署名の領域は標準のOSPF V2コードを実行するルータを含んでいます(すべての領域があるDigital SignaturesとOSPFは未署名であるためにセットしました)。 未署名の領域に署名されるaを接続する境界ルータはDigitalがあるOSPFをある領域があるSignaturesが未署名であるように設定する実行することであるに違いありません。
In order to arrange this limited compatibility, a router running OSPF with Digital Signatures must be able to process both signed and unsigned LSAs. The only router that will actually be processing both kinds of LSAs is an Area Border Router connecting a signed area to an unsigned area. An ABR connecting a signed to an unsigned area will generate signed summaries for one area and unsigned summaries for the other. An ABR must not flood signed LSAs into unsigned areas. An ABR must not flood unsigned LSAs into signed areas. This will result in AS External LSAs being dropped if they reach an area that has a different environment from the one in which they were created. There are special limitations in the case of a router that is an ABR and also an ASBR: see section 6.
この限られた互換性をアレンジするために、Digital SignaturesとOSPFを実行するルータは署名しているものと同様に未署名のLSAsを処理できなければなりません。 実際にLSAsの両方の種類を処理する唯一のルータが未署名の領域に署名している領域をつなげるArea Border Routerです。 未署名の領域に署名されるaを接続するABRはある領域のための署名している概要ともう片方のための未署名の概要を作るでしょう。 ABRは未署名の領域へ署名しているLSAsをあふれさせてはいけません。 ABRは署名している領域へ未署名のLSAsをあふれさせてはいけません。 これは彼らが作成されたものから異なった環境を持っている領域に達するなら下げられるAS External LSAsをもたらすでしょう。 ABRとまたASBRであるルータの場合には特別な制限があります: セクション6を見てください。
Complete connectivity is provided within the AS, because of the summarization provided by ABRs connecting signed and unsigned areas. There are limitations on connectivity to AS external routes in an AS with a mixture of signed and unsigned areas, depending on the location of AS border routers. An ASBR in a signed area will generate signed ASE LSAs. These LSAs will be flooded to every contiguously connected signed area. The connected signed areas are the "scope" of these ASEs. A host located in an area that is not in this scope, will not have connectivity to these external routes. An ASBR in an unsigned area will generate unsigned ASE LSAs. These LSAs
ABRsの接続の署名していて未署名の領域によって提供された総括のためにASの中で完全な接続性を提供します。 制限が署名していて未署名の領域の混合物があるASのAS外部経路への接続性にあります、AS境界ルータの位置によって。 署名している領域のASBRは署名しているASE LSAsを生成するでしょう。 これらのLSAsが水につかる、あらゆる、近接して、署名している領域は接続しました。 接続署名している領域はこれらのASEsの「範囲」です。 ホストはこの範囲にない領域で場所を見つけて、これらの外部経路に接続性を持たないでしょう。 未署名の領域のASBRは未署名のASE LSAsを生成するでしょう。 これらのLSAs
Murphy, et. al. Experimental [Page 16] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[16ページ]RFC2154OSPF
will have a scope of all the contiguously connected unsigned areas, and will be available to hosts in this scope. To arrange complete connectivity to an ASE route in an AS with signed and unsigned areas:
すべての範囲を持つ、未署名の領域が近接して接続して、この範囲のホストにとって入手できるでしょう。 手配するには、署名していて未署名の領域があるASのASEルートに接続性を完成してください:
(1) Place the ASBR on the backbone.
(1) バックボーンにASBRを置いてください。
(2) Signed Backbone: have some ABR in each unsigned area advertise a
default route to the backbone.
(2)の署名しているバックボーン: それぞれの未署名の領域のいくらかのABRにデフォルトルートにバックボーンに広告を出させてください。
(3) Unsigned Backbone: have some ABR in each signed area advertise a
default route to the backbone.
(3)の未署名のバックボーン: それぞれの署名している領域のいくらかのABRにデフォルトルートにバックボーンに広告を出させてください。
Given this design for a mixed AS, routing is available throughout the AS, but the authentication and integrity provided by this design will be effective only for routes that are inside a signed area, or traverse only signed areas. There is no mechanism for a data packet to state a preference for signed routes. The basic rules of the OSPF protocol ensure that intra-area routes are preferred to inter-area routes, that routes within the AS are preferred to AS external routes, and that inter-area routes go from area1->backbone->area2. OSPF does not allow looping, or routes of the form area1->area2- >area3. Because of these properties of OSFP routing, an AS can contain signed and unsigned areas, and achieve a predictable level of authentication.
混ぜられたASのためのこのデザインを考えて、ルーティングがAS中で利用可能ですが、このデザインによって提供された認証と保全は、署名している領域の中にないルートしか有効であるか、または署名している領域だけを横断するでしょう。 データ・パケットが署名しているルートのための優先を述べるように、メカニズムは全くありません。 OSPFプロトコルの基本的なルールは、イントラ領域ルートが相互領域ルートより好まれて、ASの中のルートがルートがarea1->から行かせるAS外部経路、およびその相互領域バックボーン->より好まれるのを確実にします。area2。 OSPFはループ、またはフォームarea1->のルートにarea2->を許容しません。area3。 OSFPルーティングのこれらの特性のために、ASは署名していて未署名の領域を含んでいて、予測できるレベルの認証を達成できます。
6. Special Considerations/Restrictions for the ABR-ASBR
6. ABR-ASBRに、特別な問題/制限
There are special restrictions and configuration considerations for a router running OSPF with Digital Signatures that is both an Area Border Router and an Autonomous System Border Router. An ASBR produces AS external LSAs that are flooded throughout the non-stub areas of the AS. An ABR that is generating digital signatures may be using a different key, certifying Trusted Entity, or signature algorithm for each of its attached areas, or it might be signing in some areas and not in others.
ルータのためのArea Border RouterとAutonomous System Border Routerの両方であるDigital SignaturesとOSPFを実行する特別な制限と構成問題があります。 ASBRはASの非スタッブ領域中で水につかっているAS外部のLSAsを生産します。 デジタル署名を生成しているABRは異なったキーを使用しているかもしれません、Trusted Entity、または署名アルゴリズムをそれぞれの付属領域に公認して、または他のもので署名するのではなく、いくつかの領域で署名して、それはそうするかもしれません。
An ABR/ASBR with no restrictions on its configuration could produce multiple versions of an ASE that would all be flooded throughout the non-stub areas of the AS. The results of this production of multiple versions of LSAs would be detrimental to performance, and could produce unpredictable routing behavior.
構成における制限のないABR/ASBRはASの非スタッブ領域中ですべて水につかっているASEの複数のバージョンを生産できました。 LSAsの複数のバージョンのこの生産の結果は、性能に有害であるだろう、予測できないルーティングの振舞いを起こすかもしれません。
Murphy, et. al. Experimental [Page 17] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[17ページ]RFC2154OSPF
The PKLSA of an ASBR is also flooded throughout the non-stub areas of the AS, and in the case of an ABR/ASBR there could be multiple, distinct PKLSAs for a given router, one per attached area, all being flooded throughout the AS. If two distinct PKLSAs from one ABR/ASBR router were present in one area, the key with the most recent create time would be stored, and all LSAs signed with a less recent key would be unverifiable.
また、ASBRのPKLSAもASの非スタッブ領域中で水につかっています、そして、ABR/ASBRの場合には、与えられたルータのための複数の、そして、異なったPKLSAsがあるかもしれません、付属領域あたり1つ、AS中で水につかっているすべての存在。 1つのABR/ASBRルータからの2異なったPKLSAsによる1つの領域でのプレゼント、最新であるのがあるキーが時間を作成するということであるなら保存されて、それほど最近でないキーで署名されたすべてのLSAsが立証不可能でしょう。
The simplest way to deal with this problem, and the method recommended by this document, is the following:
この問題に対処する最も簡単な方法、およびこのドキュメントによって推薦されたメソッドは以下です:
If an ASBR must also be an ABR, then the security configuration (key, signature algorithm, certifying Trusted Entity, environment = signed/unsigned) for all attached areas must be the same. This way the PKLSA and the ASEs produced for each area match, and there is no proliferation of versions of LSAs.
また、ASBRがABRであるに違いないなら、すべての付属領域へのセキュリティ設定(Trusted Entity、環境=が署名されるか、または未署名であることを公認する主要な署名アルゴリズム)は同じであるに違いありません。 PKLSAとASEsが各領域に生産したこのように、合ってください。そうすれば、LSAsのバージョンの増殖が全くありません。
7. LSA formats
7. LSA形式
7.1. Router Public Key LSA (PKLSA)
7.1. ルータ公開鍵LSA(PKLSA)
This LSA is the vehicle for distribution of a router public key. The PKLSA is sent by one router, and stored by all the other routers in the flooding scope. The PKLSA contains the public key that other routers will use to verify the signatures created by this router. A Router PKLSA will be communicated in the usual database exchange and via flooding mechanisms. The regular period for sending this LSA is LSRefreshTime. The Router PKLSA will also be sent when there is a new key, or a key to be flushed from the system.
このLSAはルータ公開鍵の分配のための手段です。 PKLSAは1つのルータによって送られて、氾濫範囲の他のすべてのルータによって保存されます。 PKLSAは他のルータがこのルータによって作成された署名について確かめるのに使用する公開鍵を含んでいます。 Router PKLSAは普通のデータベース交換と氾濫メカニズムで伝えられるでしょう。このLSAを送るための通常の期間はLSRefreshTimeです。 また、システムから洗い流されるために新しいキー、またはキーがあるとき、Router PKLSAを送るでしょう。
The flooding scope of a PKLSA is the area, except in the case of ASBRs. The flooding scope of an ASBR's PKLSA is the same as that of the ASEs. The "role" of the router (RTR, ABR, ASBR, ABR-ASBR) is stored in the PKLSA inside the certificate, and can be checked during flooding.
PKLSAの氾濫範囲はASBRsに関するケース以外の領域です。 ASBRのPKLSAの氾濫範囲はASEsのものと同じです。 ルータ(RTR、ABR、ASBR、ABR-ASBR)の「役割」を証明書におけるPKLSAに保存して、氾濫の間、チェックできます。
Murphy, et. al. Experimental [Page 18] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[18ページ]RFC2154OSPF
ROUTER PUBLIC KEY LSA
ルータ公開鍵LSA
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Age | Options | LS Type |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Certificate (format in 7.2) /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Signature /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Cert Length | Sign Length |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | LS時代| オプション| LSはタイプします。| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | 証明書(7.2における形式)/++++++++*+++++++*+++++++*++++++++| 署名/++++++++*+++++++*+++++++*++++++++| 本命の長さ| サインの長さ| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
LS AGE Defined in OSPF RFC [3].
OSPF RFC[3]で定義されたLS時代。
OPTIONS Defined in OSPF RFC [3].
OSPF RFC[3]で定義されたオプション。
LS TYPE 16 for Router Public Key LSA.
First bit set to indicate a signed LSA.
LSはルータ公開鍵LSAのために16をタイプします。 最初のビットは、署名しているLSAを示すためにセットしました。
LINK STATE ID Contains the Advertising Router Id (see next field).
LINK STATE ID Contains Advertising Router Id(次の分野を見ます)。
ADVERTISING ROUTER Defined in OSPF RFC [3].
OSPF RFC[3]で定義されたルータの広告を出します。
LS SEQUENCE NUMBER Defined in OSPF RFC [3].
OSPF RFC[3]で定義されたLS一連番号。
LS CHECKSUM Defined in OSPF RFC [3].
Checksum does not cover the signature.
OSPF RFC[3]で定義されたLSチェックサム。 チェックサムは署名をカバーしていません。
LENGTH Defined in OSPF RFC [3]. Length does include the
Signature field, Cert Length and Sign Length.
OSPF RFC[3]で定義された長さ。 長さはSignature分野、Cert Length、およびSign Lengthを含んでいます。
CERTIFICATE Format in section 7.2.
セクション7.2のCERTIFICATE Format。
Murphy, et. al. Experimental [Page 19] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[19ページ]RFC2154OSPF
SIGNATURE The advertising router's signature of this LSA. This
can be verified using the enclosed Router Public Key.
The signature covers the LSA header and message
starting with the LSA header options field and ending
with the Trusted Entity certification field. For
sign and verify, the last two fields (Cert Length and
Sign Length) are appended immediately after the
Certificate. When complete, the signature is
inserted between the Certification and the Cert
Length. There are two exceptions to this coverage:
SIGNATURE、広告ルータのこのLSAの署名。 同封のRouter Public Keyを使用することでこれについて確かめることができます。 署名はTrusted Entity証明分野でLSAヘッダーオプション野原と結末から始まるLSAヘッダーとメッセージを含んでいます。 署名して、検証、Certificate直後最後の2つの野原(本命LengthとSign Length)を追加します。 完全であるときに、署名はCertificationとCert Lengthの間に挿入されます。 この適用範囲への2つの例外があります:
1) If the LSA was generated with an age=MaxAge, then
the signature begins with the age field (see section
3.3).
1) LSAが時代=MaxAgeと共に生成されたなら、署名は時代分野で始まります(セクション3.3を見てください)。
2) The checksum in the LSA Header is set to zero for
the computation of the signature.
2) LSA Headerのチェックサムは署名の計算のためにゼロに設定されます。
A pad is added to the end of the signature field to
allow the next field to begin on a (4 byte) word
boundary.
パッドは次の分野が(4バイト)の語境界で始まらせるのを許容する署名分野の端に加えられます。
The format used for an RSA-MD5 signature is defined
in section 4.1.2 of RFC2065 [10].
RSA-MD5署名に使用される書式は.2セクション4.1RFC2065[10]で定義されます。
CERT LENGTH The length in bytes of the Certification inside the
Certificate.
Does not include pad that may follow Certification.
CERT LENGTH、Certificateの中のCertificationのバイトで表現される長さ。 Certificationに続くかもしれないパッドを含んでいません。
SIGN LENGTH The length in bytes of the Signature.
Does not include pad that may follow Signature.
SIGN LENGTH、Signatureのバイトで表現される長さ。 Signatureに続くかもしれないパッドを含んでいません。
7.2. Router Public Key Certificate
7.2. ルータ公開鍵証明書
A router public key certificate is a package of data signed by a Trusted Entity. This certificate is included in the router PKLSA and in the router configuration information. To change any of the values in the certificate, a new certificate must be obtained from a TE.
ルータ公開鍵証明書はTrusted Entityによって署名されたデータのパッケージです。 この証明書はルータPKLSAとルータ設定情報に含まれています。 証明書の値のどれかを変えるために、TEから新しい証明書を入手しなければなりません。
Murphy, et. al. Experimental [Page 20] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[20ページ]RFC2154OSPF
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Router Id |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| TE Id | TE Key Id | Rtr Key Id | Sig Alg |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Create Time |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Key Field Length | Router Role | #Net Ranges |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Address Mask |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| IP Address/Address Mask for each Net Range ... /
| ... /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Router Public Key |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Certification /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | ルータイド| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | Teイド| Teの主要なイド| Rtrの主要なイド| Sig Alg| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | 時間を作成してください。| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | キーフィールドの長さ| ルータの役割| #ネットは及びます。| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | IPアドレス| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | アドレスマスク| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | それぞれのネットRangeのためのIP Address/アドレスMask… / | ... / +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | ルータ公開鍵| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | 証明/++++++++*+++++++*+++++++*++++++++
ROUTER ID Advertising Router.
ルータID広告ルータ。
TE ID TE Id must uniquely identify one TE in the AS.
A number between 1-250. 0 reserved for null.
251-255 reserved for future needs.
TE ID TE Idは唯一ASの1TEを特定しなければなりません。 1-250の間の数。 0 ヌルのために、予約されます。 将来の必要性のために予約された251-255。
TE KEY ID Must uniquely identify a particular key for a given
TE at any given time. A TE Key Id may be re-used
after all references to it are gone from the AS. A
number between 1-250. 0 reserved for null. 251-255
reserved for future needs.
TE KEY ID Mustはその時々で与えられたTEのために唯一特定のキーを特定します。 それのすべての参照がASからなくなった後にTE Key Idは再使用されるかもしれません。 1-250の間の数。 0 ヌルのために、予約されます。 将来の必要性のために予約された251-255。
RTR KEY ID Must be unique for the TE and Router at any given
time. The combination of (TE Id, Rtr Id, Rtr Key Id)
uniquely identifies a particular router key at a
given time. A Rtr Key Id may be re-used after all
references to it are gone from the AS. Create Time
resolves any conflict that could be caused by
replaying old keys. A number between 1-250. 0
reserved for null. 251-255 reserved for future
needs.
RTR KEY ID Must、TEとRouterにおいて、その時々でユニークであってください。 組み合わせ、(TE Id、Rtr Id、Rtr Key Id)は一時に唯一特定のルータキーを特定します。 それのすべての参照がASからなくなった後にRtr Key Idは再使用されるかもしれません。 Timeを作成してください。再演の古いキーによって引き起こされる場合があったどんな闘争も解決します。 1-250の間の数。 0 ヌルのために、予約されます。 将来の必要性のために予約された251-255。
Murphy, et. al. Experimental [Page 21] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[21ページ]RFC2154OSPF
SIG ALG The signature algorithm for the Router Public Key.
The signature algorithm encompasses the hash
algorithm used as well. Currently defined value =
RSA-MD5(1). Values 2-252 are available for future
definition. Values 0 and 253-255 are reserved. The
Sig Alg value is registered with IANA. Future
signature algorithms will have to be defined or
referenced in this document, and registered with
IANA.
SIG ALG、Router Public Keyのための署名アルゴリズム。 署名アルゴリズムはまた、使用されるハッシュアルゴリズムを包含します。 現在定義された値はRSA-MD5(1)と等しいです。 値2-252は今後の定義に利用可能です。 値0と253-255は予約されています。 Sig Alg値はIANAに示されます。 将来の署名アルゴリズムは、本書では定義されるか、または参照をつけられて、IANAに登録されなければならないでしょう。
CREATE TIME Timestamp set by the TE. An unsigned number of
seconds since the start of January 1, 1970, GMT,
ignoring leap seconds. Used to compare two
certificates and determine which is more recent.
Requires that time synchronization for TEs, but not
for routers.
CREATE TIME TimestampはTEでセットしました。 飛躍秒を無視することでの1970年1月1日のグリニッジ標準時の始まり以来の秒の符号のない数。 2通の証明書を比較して、どちらが、より最近であるかを決定するのにおいて、使用されています。 TEsのためにその時間同期化を必要としますが、ルータに必要であるというわけではありません。
KEY FIELD LENGTH The length in bytes of the Router Public Key.
Does not include pad that may follow Router Public
Key field.
KEY FIELD LENGTH、Router Public Keyのバイトで表現される長さ。 Router Public Key野原に続くかもしれないパッドを含んでいません。
ROUTER ROLE Router (R=1), Area Border Router (ABR=2), Autonomous
System Border Router (ASBR=4), ABR and ASBR (ABR-
ASBR=6).
ルータ役割のルータ(R=1)、境界ルータ(ABR=2)、自律システム境界ルータ(ASBR=4)、ABR、およびASBR(ABR- ASBR=6)。
#NET RANGES The number of network ranges that follow. A network
range is defined to be an IP Address and an Address
Mask. This list of ranges defines the addresses that
the Router is permitted to advertise in its Router
Links LSA. Valid values are 0-255. If there are 0
ranges the router cannot advertise anything. This is
not generally useful. One range with address=0 and
mask=0 will allow a router to advertise any address.
#NET RANGES、続くネットワーク範囲の数。 ネットワーク範囲は、IP AddressとAddress Maskになるように定義されます。 範囲のこのリストはRouterがRouterリンクスLSAに広告を出すことが許可されているアドレスを定義します。 有効値は0-255です。 0つの範囲があれば、ルータは何も広告を出すことができません。 一般に、これは役に立ちません。 アドレス=0とマスク=0がある1つの範囲が、どんなアドレスも広告を出すためにルータを許容するでしょう。
IP ADDRESS & ADDRESS MASK
Define a range of addresses that this router may
advertise. Each is a 32 bit value. One range with
address=0 and mask=0 will allow a router to advertise
any address.
このルータが広告を出すかもしれないアドレスのIP ADDRESS&ADDRESS MASK Define a範囲。 それぞれが32ビットの値です。 アドレス=0とマスク=0がある1つの範囲が、どんなアドレスも広告を出すためにルータを許容するでしょう。
Murphy, et. al. Experimental [Page 22] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[22ページ]RFC2154OSPF
ROUTER PUBLIC KEY A key that can be used to verify the signatures
produced by this router. The internal format for the
Router Public Key is signature algorithm dependent.
署名について確かめるのに使用できるROUTER PUBLIC KEY Aキーはこのルータによって生産されました。 Router Public Keyのための内部の形式は署名アルゴリズムに依存しています。
A pad is added to the end of the Router Public Key
field to allow the next field to begin on a (4 byte)
word boundary.
パッドは次の分野が(4バイト)の語境界で始まらせるのを許容するRouter Public Key分野の端に加えられます。
The format used for an RSA-MD5 public key is defined
in section 3.5 of RFC2065 [10].
RSA-MD5公開鍵に使用される書式はRFC2065[10]のセクション3.5で定義されます。
CERTIFICATION The Trusted Entity's signature of the certified data.
This signature can be verified with the TE public key
identified by TE Id and TE Key Id given in this
packet. The length of the certification depends on
the key size, and is stored in the PKLSA Cert Length
field. A pad is added to the end of the
Certification to allow the next field to begin on a
(4 byte) word boundary.
CERTIFICATION Trusted Entityの公認されたデータの署名。 TE IdがTE公開鍵を特定して、このパケットでTE Key Idを与えていてこの署名について確かめることができます。 証明の長さは、主要なサイズに依存して、PKLSA Cert Length分野に保存されます。 パッドは次の分野が(4バイト)の語境界で始まらせるのを許容するCertificationの端に加えられます。
The format used for an RSA-MD5 signature is defined
in section 4.1.2 of RFC2065 [10].
RSA-MD5署名に使用される書式は.2セクション4.1RFC2065[10]で定義されます。
7.3 Signed LSA
7.3 署名しているLSA
A signed LSA is an OSPF LSA with signature data and a digital signature attached. The first bit of the LSA Type field is set to indicate the presence of a signature. The signature follows the LSA Data. Signature length and id fields are positioned at the end of the signed LSA.
署名しているLSAは署名データがあるOSPF LSAと添付のデジタル署名です。 LSA Type分野の最初のビットが署名の存在を示すように設定されます。 署名はLSA Dataに続きます。 署名の長さとイド野原は署名しているLSAの端に置かれます。
Murphy, et. al. Experimental [Page 23] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[23ページ]RFC2154OSPF
ANY SIGNED LSA
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Age | Options | LS Type |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| LSA Data /
/ ... /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Signature /
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
| Rtr Key Id | TE Id | Sign Length |
+-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
ANY SIGNED LSA 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | LS時代| オプション| LSはタイプします。| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | LSAデータ//… / +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | 署名/++++++++*+++++++*+++++++*++++++++| Rtrの主要なイド| Teイド| サインの長さ| +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
LS AGE Defined in OSPF RFC [3].
OSPF RFC[3]で定義されたLS時代。
OPTIONS Defined in OSPF RFC [3].
OSPF RFC[3]で定義されたオプション。
LS TYPE Standard LSA Type with the first bit set to indicate
the presence of security data and a signature. This
creates a new signed LSA type for each existing type.
最初のビットがあるLS TYPE Standard LSA Typeは、セキュリティー・データと署名の存在を示すためにセットしました。 これはそれぞれの既存のタイプのための新しい署名しているLSAタイプを創造します。
LINK STATE ID Defined in OSPF RFC [3].
OSPF RFC[3]で定義された州のIDをリンクしてください。
ADVERTISING ROUTER Defined in OSPF RFC [3].
OSPF RFC[3]で定義されたルータの広告を出します。
LS SEQUENCE NUMBER Defined in OSPF RFC [3].
OSPF RFC[3]で定義されたLS一連番号。
LS CHECKSUM Defined in OSPF RFC [3].
Checksum does not cover the signature.
OSPF RFC[3]で定義されたLSチェックサム。 チェックサムは署名をカバーしていません。
LENGTH Defined in OSPF RFC [3].
Length does include the Signature and security
related fields at the end of the LSA.
OSPF RFC[3]で定義された長さ。 長さはLSAの端にSignatureとセキュリティ関連分野を含んでいます。
Murphy, et. al. Experimental [Page 24] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[24ページ]RFC2154OSPF
SIGNATURE The advertising router's signature of this LSA. The
signature covers the LSA header and data starting
with the LSA header options field and ending with the
Trusted Entity certification field. For sign and
verify, the last three fields (Rtr Key Id, TE Id,
Sign Length) are appended to the Certificate. When
complete, the signature is inserted between the
Certification and the Rtr Key Id. There are two
exceptions to this coverage:
SIGNATURE、広告ルータのこのLSAの署名。 署名はTrusted Entity証明分野でLSAヘッダーオプション野原と結末から始まるLSAヘッダーとデータを含んでいます。 署名して、検証、最後の3つの野原(Rtr Key Id、TE Id、Sign Length)をCertificateに追加します。 完全であるときに、署名はCertificationとRtr Keyアイダホ州の間に挿入されます。 この適用範囲への2つの例外があります:
1) If the LSA was generated with an age=MaxAge, then
the signature begins with the age field (see section
3.3).
1) LSAが時代=MaxAgeと共に生成されたなら、署名は時代分野で始まります(セクション3.3を見てください)。
2) The checksum in the LSA Header is set to zero for
the computation & verification of the signature.
2) LSA Headerのチェックサムは署名の計算と検証のためにゼロに設定されます。
A pad is added to the end of the signature to allow
the next field to begin on a (4 byte) word boundary.
パッドは次の分野が(4バイト)の語境界で始まらせるのを許容する署名の終わりに加えられます。
The format used for an RSA-MD5 signature is defined
in section 4.1.2 of RFC2065 [10].
RSA-MD5署名に使用される書式は.2セクション4.1RFC2065[10]で定義されます。
RTR KEY ID Used to identify the router key used to sign this
LSA. The combination of (TE Id, Rtr Id, Rtr Key Id)
uniquely identifies a particular router key at a
given time, and can be used to look up the PKLSA for
the router key needed to verify this Signed LSA. A
number between 1-250. 0 reserved for null. 251-255
reserved for future needs.
ルータキーを特定するRTR KEY ID Usedは以前はよくこのLSAに署名していました。 組み合わせ、(TE Id、Rtr Id、Rtr Key Id)は、一時に唯一特定のルータキーを特定して、このSigned LSAについて確かめるのに必要であるルータキーのためにPKLSAを見上げるのに使用できます。 1-250の間の数。 0 ヌルのために、予約されます。 将来の必要性のために予約された251-255。
TE ID The id of the Trusted Entity that produced the
certificate. TE Id must uniquely identify one TE in
the AS. A number between 1-250. 0 reserved for
null. 251-255 reserved for future needs.
TE ID、証明書を製作したTrusted Entityのイド。 TE Idは唯一ASの1TEを特定しなければなりません。 1-250の間の数。 0 ヌルのために、予約されます。 将来の必要性のために予約された251-255。
SIGN LENGTH The length in bytes of the Signature.
Does not include pad that may follow Signature.
SIGN LENGTH、Signatureのバイトで表現される長さ。 Signatureに続くかもしれないパッドを含んでいません。
Murphy, et. al. Experimental [Page 25] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[25ページ]RFC2154OSPF
8. Configuration Information
8. 設定情報
Trusted Entity Information Set: (one per Trusted Entity used by this router)
信じられた実体情報はセットしました: (1このルータによって使用されるTrusted Entityあたり1つ)
Trusted Entity ID - TE Id
Identifies the Trusted Entity within the AS (defined in 7.2).
Trusted Entity Key Id - TE Key Id
Identifies the particular key for this Trusted Entity
(defined in 7.2).
Trusted Entity Public Key
A public key for this Trusted Entity.
The format used for an RSA-MD5 public key is defined in
section 3.5 of RFC2065 [10].
Signature Algorithm < and optional parameters >
The signature algorithm for the public key (defined in 7.2).
信じられた実体、イドが信じられた実体を特定するID--Te、(定義されたコネ7.2)として。 信じられたEntity Key Id--このTrusted Entity(7.2では、定義される)に、主要な特定のTE Key Id Identifies。 このTrusted EntityのためにEntity Public Key A公開鍵を信じました。 RSA-MD5公開鍵に使用される書式はRFC2065[10]のセクション3.5で定義されます。 署名Algorithm<、任意のパラメタ>は公開鍵(中では、7.2を定義する)のための署名アルゴリズムをそうします。
Router Information Set: (at least one for the router)
ルータ情報はセットしました: (ルータのための少なくとももの)
Router Private Key
The router's private key that goes with the public key in the
certificate following. The format used for the private key
depends on the crypto package used by your implementation.
This key is not transmitted as part of this design. Our
implementation uses the private key format compatible with
RSAREF [9].
Router Certificate (format in 7.2).
Router兵士のKey、証明書の公開鍵が続いていて行くルータの秘密鍵。 秘密鍵に使用される形式はあなたの実装によって使用される暗号パッケージに依存します。 このキーはこのデザインの一部として送られません。 私たちの実装はRSAREF[9]とのコンパチブル秘密鍵形式を使用します。 ルータ証明書(7.2における形式)。
Timing Intervals:
タイミング間隔:
Trusted Entity Key Distribution Interval (TE_KEY_DIST_INT)
The period of time, in seconds, needed to get a TE public key
installed on all the routers in the TE's scope.
Maximum Transit Delay (MAX_TRANSIT_DELAY)
The maximum period of time, in seconds, that it should take
for an LSA to reach all the routers in the AS.
TE公開鍵を得るのに必要である秒の期間の間の信じられたEntity Key Distribution Interval(TE_KEY_DIST_INT)はTEの範囲のすべてのルータにインストールしました。 LSAがASですべてのルータに達するように、最大のTransit Delay(マックス_TRANSIT_DELAY)は秒のそれがそうするべきである最大の期間に取ります。
Router Information per attached Area:
付属Areaあたりのルータ情報:
Environment flag
Signed=1, Unsigned=0
環境旗のSigned=1、Unsigned=0
9. Remaining Vulnerabilities
9. 脆弱性のままで、残っています。
Note that with this mechanism, one router can still distribute incorrect data in the information for which it itself is responsible. Consequently, an autonomous system employing digital signatures with this mechanism will not be completely invulnerable to routing
このメカニズムで、1つのルータがまだそれ自体は責任がある情報の間違ったデータを分配できることに注意してください。 その結果このメカニズムによるデジタル署名を使うのが完全に発送するのに傷つけられなくなるというわけではない自律システム
Murphy, et. al. Experimental [Page 26] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[26ページ]RFC2154OSPF
disruptions from a single router. For example, the area border routers and autonomous system border routers will still be able to inject incorrect routing information. Also, any single internal router can be incorrect in the routing information it originates about its own links.
ただ一つのルータからの分裂。 例えば、境界ルータと自律システム境界ルータはまだ不正確なルーティング情報を注入できるでしょう。 また、どんなただ一つの内部のルータもそれがそれ自身のリンクに関して溯源するルーティング情報で不正確である場合があります。
9.1. Area Border Routers
9.1. 境界ルータ
Even with the design proposed here, the area border routers can inject incorrect routing information into their attached areas about the backbone and the other areas in Summary LSA's. They can also inject incorrect routing information into the backbone about their attached area.
デザインさえここで提案されている状態で、境界ルータはバックボーンに関するそれらの付属領域とSummary LSAのところの他の領域に不正確なルーティング情報を注ぐことができます。 また、彼らはそれらの付属領域に関するバックボーンに不正確なルーティング情報を注ぐことができます。
Because all the area border routers in one area work from the same database of LSA's received in their common area, it would be possible for the area border routers to corroborate each other. Any area border router for an area could double check the Summary LSA's received over the backbone from other ABR's from the area, and could double check the Summary LSA's flooded through the area from the other area border routers. The other routers in the area or backbone should be warned of a failure of this check. The warning could be a signed message from the area border router detecting the failure, flooded in the usual mechanism.
LSAに関する同じデータベースからの1つの領域の仕事におけるすべての境界ルータがそれらの一般的な領域で受信されたので、境界ルータが互いを確証するのは、可能でしょう。 領域へのどんな境界ルータも、領域からSummary LSAがバックボーンの上で他のABRから受けたチェックを倍にすることができて、他の境界ルータからSummary LSAが領域を通ってあふれさせたチェックを倍にするかもしれません。 領域かバックボーンにおける他のルータはこのチェックの失敗について警告されるべきです。 警告は失敗であって、普通のメカニズムで水につかっている境界ルータ検出からの署名しているメッセージであるかもしれません。
Another possibility would be that the area border routers in an area could originate multiple sets of Summary LSA's -- one for itself containing its own information and one for each of the area border routers in the area containing the information each of them should originate. Each router in the area or backbone could then determine for itself whether the area border routers agreed. This distribution of information but coordination of processing is in keeping with the paradigm of link state protocols, where information and processing is duplicated in each router.
別の可能性は領域の境界ルータはSummary LSAの複数のセットを溯源するかもしれません--それぞれのそれらが溯源するべきである情報を含む領域のそれ自体のためのそれ自身の情報を含む1つとそれぞれの境界ルータのためのものということでしょう。 そして、領域かバックボーンにおける各ルータは、それ自体のために境界ルータが同意したかどうか決定するかもしれません。 情報のこの分配にもかかわらず、処理のコーディネートはリンク州のプロトコルのパラダイムに従っています。(そこでは、情報と処理が各ルータでコピーされます)。
Both alternatives mean much additional processing and additional message transmission, over and above the additional processing required for signature generation and verification. Because the vulnerability is isolated to a few points in each area, because the source of incorrect information is detectable (in those situations where the incorrect information is spotted) and because the protection is costly, we have not added this protection to this design.
両方の代替手段は、処理と、そして、追加処理を超えた多くの追加処理と追加メッセージ送信が署名世代と検証に必要であることを意味します。 脆弱性は各領域の数ポイントに隔離されます、不正確な情報の源が検出可能であるので(不正確な情報がそうであるそれらの状況、ぶち、)、保護が高価であるので、私たちはこの保護をこのデザインに追加していません。
9.2. Internal Routers
9.2. 内部のルータ
The internal routers can be incorrect about information they themselves originate.
内部のルータはそれら自体が溯源する情報に関して不正確である場合があります。
Murphy, et. al. Experimental [Page 27] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[27ページ]RFC2154OSPF
A router could announce an incorrect metric for a valid link. There is no way to guard against this, but the damage would be small and localized even if the router is announcing that the link is up when it is down or vice versa.
ルータが発表できた、不正確である、有効なリンクにおいて、メートル法です。 これに用心する方法が全くありませんが、ルータが、それが下がっているか、逆もまた同様ですときに、リンクが上がっていると発表していても、損害は、わずかでローカライズされるでしょう。
A router could announce a connection that does not in fact exist. If a router announces a non-existent connection to a transit network, the OSPF Dijkstra computation will not consider the connection without a similar announcement from another router at the other "end". Therefore, no damage would result (above network impact to transmit and store the incorrect information) without the cooperation of another router. A router could also announce a connection to a stub network or a host route that does not exist. The Dijkstra computation can not perform the same check for a similar announcement from the other "end", because no other end exists. This is a vulnerability.
ルータは事実上、存在しない接続を発表するかもしれません。 ルータが実在しない接続をトランジットネットワークに発表すると、OSPFダイクストラの計算はもう片方の「終わり」の別のルータから同様の発表なしで接続を考えないでしょう。 したがって、損害は全く別のルータの協力なしで結果として生じないでしょう(不正確な情報を伝えて、保存するネットワーク影響を超えて)。 また、ルータは存在しないスタッブネットワークかホストルートに接続を発表するかもしれません。 ダイクストラの計算は同様の発表のためにもう片方の「終わり」から同じチェックを実行できません、他の終わりが全く存在していないので。 これは脆弱性です。
A faulty router announcing a nonexistent connection to a stub network or host could result in the faulty router receiving IP packets bound for that network or host. Unless the faulty router then forwarded the packets to the correct destination by source routing, the failure of packet delivery could expose the incorrect routing. To exploit the vulnerability deliberately, the faulty router would have to be able to handle and pass on the received traffic for the incorrectly announced destination. Furthermore, if the incorrect routing were discovered, the signatures on the routing information would identify the faulty router as the source of the incorrect information. Finally, this design checks router advertisements against allowed address ranges certified by a trusted entity. A faulty router could announce nonexistent host or stub network routes, but only to addresses within its allowed ranges.
スタッブネットワークかホストに実在しない接続を発表する不完全なルータはそのネットワークかホストに向かっているIPパケットを受ける不完全なルータをもたらすかもしれません。 次に、不完全なルータがソースルーティングで正しい目的地にパケットを送らない場合、パケット配信の失敗は不正確なルーティングを暴露するかもしれないでしょうに。 不完全なルータは、不当に発表された目的地に、容認されたトラフィックを扱って、故意に脆弱性を利用するために、伝えることができなければならないでしょう。 その上、不正確なルーティングが発見されるなら、ルーティング情報における署名は不正確な情報の源として不完全なルータを特定するでしょうに。 最終的に、このデザインは信じられた実体によって公認された許容アドレスの範囲に対してルータ通知をチェックします。 実在しないホストかスタッブネットワークルートを発表しますが、不完全なルータは許容範囲の中のアドレスだけにそうすることができました。
9.3. Autonomous System Border Routers
9.3. 自律システム境界ルータ
The autonomous system boundary routers can produce incorrect routing information in the external routes information they originate. There is no way to double check or corroborate this information, as there is with area border routers. No authority within an autonomous system exists to authorize the networks an autonomous system boundary router could announce, as is the case for the internal networks an internal router could announce. Consequently, the autonomous system boundary routers remain a unprotected vulnerability. With this in mind, special care should be taken to protect the autonomous system boundary routers with other means.
自律システム境界ルータはそれらが溯源する外部経路情報の不正確なルーティング情報を作り出すことができます。 境界ルータが領域と共にあるとき、チェックを倍にするか、またはこの情報を確証する方法が全くありません。 自律システムの中の権威は全く自律システム境界ルータが発表できたネットワークを認可するために存在していません、内部のルータが発表できた内部のネットワークのためのケースのように。 その結果、自律システム境界ルータは保護のない脆弱性のままで残っています。 これが念頭にある場合、特別な注意は、他の手段で自律システム境界ルータを保護するために払われるべきです。
10. Security Considerations
10. セキュリティ問題
This entire memo is about security considerations.
この全体のメモはセキュリティ問題に関するものです。
Murphy, et. al. Experimental [Page 28] RFC 2154 OSPF with Digital Signatures June 1997
etマーフィー、アル。 デジタル化した署名1997年6月がある実験的な[28ページ]RFC2154OSPF
11. References
11. 参照
[1] Finn, Gregory G., "Reducing the Vulnerability of Dynamic Computer
Networks," ISI Research Report ISI/RR-88-201, University of
Southern California Information Sciences Institute,
Marina del Rey, California, June 1988.
[1] フィンランド人、グレゴリーG.、「ダイナミックなコンピュータネットワークの脆弱性を減少させます」、ISI Research Report ISI/RR-88-201、南カリフォルニア大学情報Sciences Institute、マリナデルレイ、カリフォルニア(1988年6月)。
[2] Kumar,B and Crowcroft,J., "Integrating Security in Inter-Domain
Routing Protocols", Computer Communications Review, Vol 23,
No. 5, October 1993.
[2] J. クマーとBとクロウクロフト、「相互ドメインルーティング・プロトコルにおけるセキュリティを統合すること」でのコンピュータコミュニケーションはVol23、1993年10月No.日5に再検討されます。
[3] Moy, J., "OSPF Version 2," RFC 1583, Proteon, Inc., March 1994.
[3]Moy、J.、「OSPFバージョン2」、RFC1583、Proteon Inc.、1994年3月。
[4] Perlman, R., "Network Layer Protocols with Byzantine Robustness",
Ph.D. Thesis, Department of Electrical Engineering and Computer
Science, MIT, August 1988.
[4] パールマンとR.と「込み入った丈夫さがあるネットワーク層プロトコル」と博士Thesisと電気工学の部とコンピュータサイエンス、MIT(1988年8月)。
[5] Perlman, R., "Interconnections: Bridges and Routers",
Addison-Wesley, Reading, Mass., 1992.
[5] パールマン、R.、「インタコネクト:」 アディソン-ウエスリーの、そして、閲読している「ブリッジとルータ」マサチューセッツ州、1992
[6] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
Source Code in C," John Wiley & Sons, Inc., New York, 1994.
[6] シュナイアー、B.、「適用された暗号:」 「C」とジョン・ワイリーと息子Inc.、ニューヨーク、1994年のプロトコル、アルゴリズム、およびソースコード
[7] Steenstrup, M., "Inter-Domain Policy Routing Protocol
Specification: Version 1", RFC 1479, BBN Systems and
Technologies, July 1993.
[7] ステーンストルプ、M.、「相互ドメイン方針ルート設定は仕様を議定書の中で述べます」。 バージョン1インチとRFC1479とBBNシステムと技術、1993年7月。
[9] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., June
1991, Version 1.4.
[9]PKCS#1: 標準のRSA暗号化RSA Data Security Inc.、1991年6月、バージョン1.4。
[10] Eastlake D. & Kaufman C., "Domain Name System Security
Extensions", RFC2065, January 1997.
[10]イーストレークD.とコーフマンC.、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月。
[11] Moy J., "OSPF Version 2", Cascade Communications Corp,
Work In Progress.
[11]Moy J.、「2インチ(カスケードコミュニケーションCorp)が進行中で扱うOSPFバージョン。」
12. Authors' Addresses
12. 作者のアドレス
Sandra Murphy murphy@tis.com Madelyn Badger mrb@tis.com Brian Wellington bwelling@tis.com
サンドラマーフィー murphy@tis.com Madelynムジナ mrb@tis.com ブライアンウェリントン bwelling@tis.com
Trusted Information Systems 3060 Washington Road Glenwood, MD 21738
信じられた情報システム3060ワシントン道路グレンウッド、MD 21738
Murphy, et. al. Experimental [Page 29]
etマーフィー、アル。 実験的[29ページ]
一覧
スポンサーリンク
