[要約] RFC 2520は、モバイルネットワークホストコントロール（NHC）を使用したNHRP（Next Hop Resolution Protocol）に関する仕様です。このRFCの目的は、モバイルデバイスのネットワーク接続を効率的に管理するためのプロトコルを提供することです。
Network Working Group J. Luciani
Request for Comments: 2520 Nortel Networks
Category: Experimental H. Suzuki
Cisco Systems
N. Doraswamy
Nortel Networks
D. Horton
CiTR Pty Ltd
February 1999
NHRP with Mobile NHCs
モバイルNHCを備えたNHRP
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティ向けの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
Abstract
概要
This document describes an extension to NHRP [1] which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner.
このドキュメントでは、モバイルNHCが認証された方法でホームLIで登録を実行し、NHSに接続できるようにするNHRP [1]の拡張機能について説明します。
As described in this document, Mobile NHCs are NHCs which are not configured with enough information to find a specific serving NHS in their home LIS, but which have a mechanism to find an NHS (which may or may not be a serving NHS) to which they will attach. As described in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism such as an anycast address. In this case, the NHC may use the surrogate NHS to send a NHRP Registration Request toward the NHC's home LIS where a serving NHS resides. However, as defined in [1], packet authentication is performed on a hop by hop basis. In the mobile NHC case, it is not practical for the mobile NHC be in a security relationship with every surrogate NHS, thus it is presumably desirable to have some form of end to end only authentication for the case of a mobile NHC's registration. This document describes an authentication extension for NHRP which has such end to end only semantics.
このドキュメントで説明されているように、モバイルNHCは、自宅のLIで特定のサービングNHSを見つけるのに十分な情報で構成されていないNHCですが、NHSを見つけるメカニズム（これはNHSになる場合とそうでない場合があります）があります。彼らは取り付けます。[1]で説明されているように、NHCは、Anycastアドレスなどのメカニズムを使用して「代理」NHSに付着する場合があります。この場合、NHCはサロゲートNHSを使用して、NHCのHomeLisにNHRP登録要求を送信する場合があります。ただし、[1]で定義されているように、パケット認証はホップごとにホップで実行されます。モバイルNHCの場合、モバイルNHCはすべての代理NHSとセキュリティ関係にあることは実用的ではないため、モバイルNHCの登録の場合に何らかの形のエンドツーエンド認証を持つことが望ましいと思われます。このドキュメントでは、セマンティクスのみが終了するようなエンドから終了するNHRPの認証拡張機能について説明しています。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [4].
キーワードは、このドキュメントに表示される場合、[4]で説明されているように解釈される場合、必要な、要求されてはなりません。
This document describes an extension for Mobile NHCs to use when they wish to register with their home LIS but initially connect to a non-serving NHS to do so. The reader is encouraged to read [1] for more details on the NHRP registration process.
このドキュメントでは、モバイルNHCがホームLISに登録したいときに使用する拡張機能について説明しますが、最初は非奉仕NHSに接続してそうすることです。NHRP登録プロセスの詳細については、読者を読むことをお勧めします[1]。
Compulsory = 1 Type = 10 (proposed) Length = variable
compururedory = 1 type = 10（提案）長さ=変数
The NHRP Mobile NHC Authentication Extension is carried in NHRP Registration packets to convey end to end authentication Information. This extension is defined in contrast to the NHRP Authentication Extension defined in [1] which has hop by hop semantics.
NHRPモバイルNHC認証拡張機能は、NHRP登録パケットに搭載されており、エンドツーエンド認証情報を伝達します。この拡張機能は、ホップセマンティクスによってホップがある[1]で定義されているNHRP認証拡張機能とは対照的に定義されています。
This new extension is used when a mobile NHC initially connects to an NHS which is not one of its serving NHSs and the mobile NHC and nonserving NHS are not in a security relationship. The mobile NHC does this in order to send an NHRP Registration Request, via normal routing and forwarding processes, to one of its serving NHSs with which it does have a security relationship. As defined in [1], a serving NHS is an NHS in the NHC's home LIS with which the NHC will register. Upon receiving such an NHRP Registration Request, the serving NHS will do the following: authenticate the sender NHC, set up a VC to the NHC, and then send an NHRP Resolution Reply in response on that new VC.
この新しい拡張機能は、モバイルNHCが最初にNHSを提供していないNHSに接続している場合に使用され、モバイルNHCと非廃止NHSがセキュリティ関係にない場合があります。モバイルNHCは、通常のルーティングと転送プロセスを介してNHRP登録リクエストを送信して、セキュリティ関係を持つNHSSのサービスを提供するためにこれを行います。[1]で定義されているように、サービングNHSは、NHCが登録するNHCのホームLISのNHSです。このようなNHRP登録リクエストを受信すると、サービングNHSは次のことを行います。送信者NHCを認証し、NHCにVCを設定し、その新しいVCに応じてNHRP解像度の返信を送信します。
Note that, as defined in [1], a transit NHS (such as the one to which the mobile NHC initially connects) must ignore an extension which it does not understand and that an NHS must not change the order of extensions in an NHRP packet. Thus, the end to end semantics of this extension are preserved without causing changes to existing implementations.
[1]で定義されているように、トランジットNHS（モバイルNHCが最初に接続するものなど）は、それが理解していない拡張機能を無視する必要があり、NHSはNHRPパケットの拡張順序を変更してはなりません。。したがって、この拡張機能のエンドツーエンドセマンティクスは、既存の実装に変更を引き起こすことなく保存されます。
If a serving NHS receives a packet which fails the hop by hop authentication test defined in [1] then the NHS MUST generate an Error Indication of type 'Authentication Failure' and discard the packet. However in the case where the NHRP Mobile NHC Authentication Extension is used as described above, sending an Error Indication is not possible since no route exists back toward the mobile NHC assuming a VC does not already exist between the mobile NHC and the
サービングNHSが[1]で定義されたホップ認証テストに失敗するパケットを受信した場合、NHSはタイプ「認証障害」のエラー表示を生成し、パケットを破棄する必要があります。ただし、NHRPモバイルNHC認証拡張が上記のように使用される場合、モバイルNHCとモバイルNHCの間にVCがまだ存在しないと仮定してモバイルNHCに戻るルートが存在しないため、エラー表示を送信することはできません。
serving NHS which received the NHRP Registration Request. In this case, the NHRP Registration Request is merely dropped.
NHRP登録要求を受け取ったNHSの提供。この場合、NHRP登録要求は単に削除されます。
The authentication header has the following format:
認証ヘッダーには次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a table that maintains the keys and other information such as a hash algorithm. Src and Dst communicate either offline using manual keying or online using a key management protocol to populate this table. The sending NHRP entity always allocates the SPI and the parameters associated with it.
セキュリティパラメーターインデックス（SPI）は、キーやハッシュアルゴリズムなどのその他の情報を維持するテーブルへのインデックスと考えることができます。SRCとDSTは、マニュアルキーイングを使用してオフラインまたはオンラインを使用して、主要な管理プロトコルを使用してオンラインで通信し、このテーブルを設定します。送信NHRPエンティティは、常にSPIとそれに関連するパラメーターを割り当てます。
The Src Addr field is a variable length field which contains the address assigned to the outgoing interface. The length of the field is obtained from the source protocol length field in the mandatory part of the NHRP header. The tuple <spi, src addr> uniquely identifies the key and the other parameters that are used in authentication.
SRC ADDRフィールドは、発信インターフェイスに割り当てられたアドレスを含む可変長さフィールドです。フィールドの長さは、NHRPヘッダーの必須部分のソースプロトコル長フィールドから取得されます。Tuple <SPI、SRC Addr>は、認証で使用されるキーとその他のパラメーターを一意に識別します。
The length of the authentication data field is dependent on the hash algorithm used. The Authentication Data field contains the keyed hash calculated over the following fields: fixed part (with hop count, packet size and checksum being treated as if set to zero), mandatory part, and extensions up to and including the Mobile NHC Authentication extension.
認証データフィールドの長さは、使用されるハッシュアルゴリズムに依存します。認証データフィールドには、次のフィールドに計算されたキー付きハッシュが含まれています。固定部品（ホップカウント、パケットサイズ、チェックサムがゼロに設定されているかのように扱われる）、必須部分、およびモバイルNHC認証拡張機能までの拡張。
Note that [1] defines an explicit ordering of extensions such that:
[1]は、次のような拡張機能の明示的な順序を定義していることに注意してください。
(a) If the Responder Address extension exists then it must appear before the Authentication Extension.
(a) 応答者のアドレス拡張が存在する場合、認証拡張前に表示する必要があります。
(b) Any extensions that may be modified in transit (e.g., Forward Transit Extension, Hop by Hop Authentication Extension) must appear after the Mobile NHC Authentication Extension.
(b) トランジットで変更される可能性のある拡張機能（例：フォワードトランジット拡張、ホップ認証拡張によるホップなど）は、モバイルNHC認証拡張後に表示する必要があります。
SPI's can be negotiated either manually or using an Internet Key Management protocol. Manual keying MUST be supported. The following parameters are associated with the tuple <SPI, src>- lifetime, Algorithm, Key. Lifetime indicates the duration in seconds for which the key is valid. In case of manual keying, this duration can be infinite. Also, in order to better support manual keying, there may be multiple tuples active at the same time (Dst being the same).
SPIは、手動またはインターネットキー管理プロトコルを使用して交渉することができます。手動キーをサポートする必要があります。次のパラメーターは、Tuple <SPI、src> -Lifetime、アルゴリズム、キーに関連付けられています。生涯は、キーが有効である秒単位の期間を示します。手動キーイングの場合、この期間は無限になる可能性があります。また、マニュアルキーイングをより適切にサポートするために、同時に複数のタプルがアクティブになる可能性があります（DSTは同じです）。
Algorithm specifies the hash algorithm agreed upon by the two entities. HMAC-MD5-128 [2] is the default algorithm and MUST be implemented. Other algorithms MAY be supported by defining new values. IANA will assign the numbers to identify the algorithm being used as described in [1].
アルゴリズムは、2つのエンティティによって合意されたハッシュアルゴリズムを指定します。HMAC-MD5-128 [2]はデフォルトのアルゴリズムであり、実装する必要があります。他のアルゴリズムは、新しい値を定義することでサポートされる場合があります。IANAは、[1]で説明されているように使用されているアルゴリズムを識別するために番号を割り当てます。
Any Internet standard key management protocol MAY so be used to negotiate the SPI and parameters.
インターネット標準のキー管理プロトコルを使用して、SPIとパラメーターをネゴシエートするために使用できます。
Unauthenticated 'Mobile' Registration Request processing proceeds as follows [1]:
認証されていない「モバイル」登録要求処理は、次のように進行します[1]：
- the NHC inserts the internetwork address of a serving NHS in the 'Destination Protocol Address' field; If the NHS address is unknown, then the NHC inserts its own internetwork address. A ' responder address' extension is optionally added. - the non-serving NHS forwards the packet along the routed path based on the contents of the 'Destination Protocol Address' field. - the serving NHS which receives the NHRP Registration Request will set up a direct VCC to NHC after authenticating the request - the serving NHS will then send the NHRP Registration Reply back to the NHC on that new VCC. Note that the NHS MUST wait some configured interval before doing this reply in order to prevent a race condition from occurring between the VC setup and sending the NHRP reply packet. - the NHC will subsequently send all NHRP traffic to the serving NHS on the direct VCC.
- NHCは、「宛先プロトコルアドレス」フィールドにサービングNHSのインターネットワークアドレスを挿入します。NHSアドレスが不明の場合、NHCは独自のインターネットワークアドレスを挿入します。「レスポンダーアドレス」拡張子がオプションで追加されます。 - 非販売NHSは、「宛先プロトコルアドレス」フィールドの内容に基づいて、ルーティングされたパスに沿ってパケットを転送します。-NHRP登録要求を受信するサービングNHSは、リクエストを認証した後、NHCに直接VCCを設定します - サービングNHSは、その新しいVCCのNHRP登録返信をNHCに送り返します。NHSは、VCセットアップとNHRP Replyパケットの送信の間にレース状態が発生しないようにするために、この返信を行う前に構成された間隔を待つ必要があることに注意してください。-NHCはその後、直接VCCのすべてのNHRPトラフィックをサービングNHSに送信します。
When the NHC adds the authentication extension header, it performs a table look up in order to fetch the SPI and the security parameters based on the outgoing interface address. If there are no entries in the table and if there is support for key management, the NHC initiates the key management protocol to fetch the necessary parameters. The NHC constructs the Authentication Extension payload and calculates the hash by zeroing out the authentication data field. The result is placed in the authentication data field. The src address field in the payload is the internetwork address assigned to the outgoing interface.
NHCが認証拡張ヘッダーを追加すると、発信インターフェイスアドレスに基づいてSPIとセキュリティパラメーターを取得するために、テーブルの検索を実行します。テーブルにエントリがなく、主要な管理のサポートがある場合、NHCは重要なパラメーターを取得するための主要な管理プロトコルを開始します。NHCは、認証拡張ペイロードを構築し、認証データフィールドをゼロにすることでハッシュを計算します。結果は認証データフィールドに配置されます。ペイロードのSRCアドレスフィールドは、発信インターフェイスに割り当てられたインターネットワークアドレスです。
If key management is not supported and authentication is mandatory, the packet is dropped and this information is logged.
キー管理がサポートされておらず、認証が必須である場合、パケットが削除され、この情報が記録されます。
On the receiving end, the serving NHS fetches the parameters based on the SPI and the internetwork address in the authentication extension payload. The authentication data field is extracted before being zeroed out in order to calculate the hash. It computes the hash on the entire payload and if the hash does not match, then an "abnormal event" has occurred.
受信側では、サービングNHSは、認証拡張ペイロードのSPIとインターネットワークアドレスに基づいてパラメーターを取得します。ハッシュを計算するために、認証データフィールドがゼロになってから抽出されます。ペイロード全体でハッシュを計算し、ハッシュが一致しない場合、「異常なイベント」が発生しました。
The keys used by the mobile NHC for communicating with the serving NHS in NHRP Registration Requests can be used in subsequent resolution and purge requests made directly to the serving NHS after receiving the NHRP Registration Reply. However, the authentication extension defined in [1] MUST be used when these keys are applied to resolution and purge packets.
NHRP登録リクエストでサービングNHSと通信するためにモバイルNHCが使用するキーは、NHRP登録返信を受信した後、その後の解像度およびパージリクエストをサービングNHSに直接パージリクエストで使用できます。ただし、[1]で定義されている認証拡張機能は、これらのキーが解像度パケットとパージパケットに適用される場合に使用する必要があります。
Hop by Hop Authentication[1] and End to End authentication MAY be used in combination to provide protection against both spoofing and denial of service attacks. If only an end-to-end Mobile NHC Authentication Extension is present, it MAY be the policy of each transit NHS to reject the NHRP Registration Request based on the requirement for having a Hop by Hop authentication present. Such a requirement is a local matter.
ホップによるホップ認証[1]およびエンドツーエンド認証を組み合わせて使用して、サービス攻撃と拒否攻撃の両方に対して保護することができます。エンドツーエンドのモバイルNHC認証拡張機能のみが存在する場合、ホップによるホップ認証によるホップによるホップによる登録要求に基づいて、NHRP登録要求を拒否する各トランジットNHSのポリシーである可能性があります。このような要件は地元の問題です。
It is important that the keys chosen are strong since the security of the entire system depends on the keys being chosen properly.
システム全体のセキュリティが適切に選択されるキーに依存するため、選択されたキーが強力であることが重要です。
End-to-end authentication counters spoofing attacks on the home subnet through not relying on the potentially compromised chain of trust. The use of end-end authentication is further described in [3].
エンドツーエンドの認証は、潜在的に侵害された信頼の連鎖に依存しないことにより、ホームサブネットのスプーフィング攻撃をカウンターします。エンドエンド認証の使用は、[3]でさらに説明されています。
Hop-by-hop authentication prevents denial of service attacks by introducing access control at the first point of contact to the NHRP infrastructure.
ホップバイホップ認証は、NHRPインフラストラクチャへの最初の接触時点でアクセス制御を導入することにより、サービス拒否攻撃を防ぎます。
The security of this extension is performed on an end to end basis. The data received can be trusted only so much as one trusts the end point entities in the path traversed. A chain of trust is established amongst NHRP entities in the path of the NHRP Message. If the security in an NHRP entity is compromised, then security in the entire NHRP domain is compromised.
この拡張機能のセキュリティは、エンドツーエンドベースで実行されます。受け取ったデータは、パスのエンドポイントエンティティを信頼しているのと同じくらい信頼できます。NHRPメッセージのパスにあるNHRPエンティティの間に、信頼のチェーンが確立されます。NHRPエンティティのセキュリティが侵害された場合、NHRPドメイン全体のセキュリティが損なわれます。
Data integrity covers the entire NHRP payload up to and including the Mobile NHC Authentication Extension. This guarantees that the data and extensions covered by this authentication hash were not modified and that the source is authenticated as well. If the authentication extension is not used or if the security is compromised, then NHRP entities are liable to both spoofing attacks, active attacks, and passive attacks.
データの整合性は、モバイルNHC認証拡張機能を含むNHRPペイロード全体をカバーします。これにより、この認証ハッシュの対象となるデータと拡張機能が変更されておらず、ソースも認証されていることが保証されます。認証拡張機能が使用されていない場合、またはセキュリティが侵害されている場合、NHRPエンティティは、攻撃、アクティブな攻撃、パッシブ攻撃の両方の責任を負います。
There is no mechanism to encrypt the messages. It is assumed that a standard layer 3 confidentiality mechanism will be used to encrypt and decrypt messages. It is recommended to use an Internet standard key management protocol to negotiate the keys between the neighbors. Transmitting the keys in clear text, if other methods of negotiation is used, compromises the security completely.
メッセージを暗号化するメカニズムはありません。標準のレイヤー3機密性メカニズムを使用して、メッセージを暗号化および復号化するために使用されると想定されています。インターネット標準のキー管理プロトコルを使用して、隣人間のキーをネゴシエートすることをお勧めします。他のネゴシエーション方法が使用されている場合、明確なテキストでキーを送信すると、セキュリティが完全に損なわれます。
References
参考文献
[1] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[1] Luciani、J.、Katz、D.、Piscitello、D.、Cole、B。and N. Doraswamy、「NBMA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
[2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[2] Krawczyk、H.、Bellare、M。and R. Canetti、「HMAC：メッセージ認証のためのキー付きハッシュ」、RFC 2104、1997年2月。
[3] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[3] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
James V. Luciani Nortel Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821
James V. Luciani Nortel Networks 3 Federal Street Mail Stop：Bl3-03 Billerica、MA 01821
Phone: +1 978 916 4734
EMail: luciani@baynetworks.com
Hiroshi Suzuki Cisco Systems 170 West Tasman Dr. San Jose, CA 96134
Suzuki Cisco Systems 170 West Tasman Dr. San Jose、CA 96134
Phone: +1 408 525 6006
EMail: hsuzuki@cisco.com
Naganand Doraswamy Nortel Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821
Naganand Doraswamy Nortel Networks 3 Federal Street Mail Stop：Bl3-03 Billerica、MA 01821
Phone: +1 978 916 4734
EMail: naganand@baynetworks.com
David Horton CiTR PTY Ltd Level 2 North Tower 339 Coronation Drive Milton, Australia 4064
David Horton Citr Pty Ltd Level 2 North Tower 339 Coronation Drive Milton、Australia 4064
Phone: +61 7 32592222
EMail: d.horton@citr.com.au
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明するか、その実装を支援する派生作品は、いかなる種類の制限なしに、準備、コピー、公開、配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。