[要約] RFC 9303 は、LISP-SEC と呼ばれるセキュリティメカニズムを定義し、LISPのEID-to-RLOCマッピングデータの認証、整合性、およびアンチリプレイ保護を提供することを目的としています。また、LISP-SEC は、Map-Reply メッセージ内の EID-Prefix クレームの認証を可能にします。
Internet Engineering Task Force (IETF) F. Maino
Request for Comments: 9303 Cisco Systems
Category: Standards Track V. Ermagan
ISSN: 2070-1721 Google, Inc.
A. Cabellos
Universitat Politecnica de Catalunya
D. Saucez
Inria
October 2022
Locator/ID Separation Protocol Security (LISP-SEC)
ロケーター/ID分離プロトコルセキュリティ（LISP-SEC）
Abstract
概要
This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages.
このメモは、LISPのEndpoint-IDからRouting-locator（EID-to-Rlocに起源認証、整合性、およびレプレイ防止を提供する一連のセキュリティメカニズムであるロケーター/ID分離プロトコルセキュリティ（LISP-SEC）を指定します。）マッピングルックアッププロセスを介して伝えられるマッピングデータ。LISP-SECは、MAP-ReplyメッセージのEID-Prefixクレームに関する承認の検証も可能にします。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9303.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9303で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Requirements Notation
3. Definitions of Terms
4. LISP-SEC Threat Model
5. Protocol Operations
6. LISP-SEC Control Messages Details
6.1. Encapsulated Control Message LISP-SEC Extensions
6.2. Map-Reply LISP-SEC Extensions
6.3. Map-Register LISP-SEC Extensions
6.4. ITR Processing: Generating a Map-Request
6.5. Encrypting and Decrypting an OTK
6.5.1. Unencrypted OTK
6.6. Map-Resolver Processing
6.7. Map-Server Processing
6.7.1. Generating a LISP-SEC-Protected Encapsulated
Map-Request
6.7.2. Generating a Proxy Map-Reply
6.8. ETR Processing
6.9. ITR Processing: Receiving a Map-Reply
6.9.1. Map-Reply Record Validation
7. Security Considerations
7.1. Mapping System Security
7.2. Random Number Generation
7.3. Map-Server and ETR Colocation
7.4. Deploying LISP-SEC
7.5. Shared Keys Provisioning
7.6. Replay Attacks
7.7. Message Privacy
7.8. Denial-of-Service and Distributed Denial-of-Service Attacks
8. IANA Considerations
8.1. ECM AD Type Registry
8.2. Map-Reply AD Types Registry
8.3. HMAC Functions
8.4. Key Wrap Functions
8.5. Key Derivation Functions
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
The Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301] is a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). EID-to-RLOC mappings are stored in a database and the LISP Mapping System, and they are made available via the Map-Request/Map-Reply lookup process. If these EID-to-RLOC mappings, carried through Map-Reply messages, are transmitted without integrity protection, an adversary can manipulate them and hijack the communication, impersonate the requested EID, or mount Denial-of-Service (DoS) or Distributed Denial-of-Service (DDoS) attacks. Also, if the Map-Reply message is transported unauthenticated, an adversarial LISP entity can overclaim an EID-Prefix and maliciously redirect traffic. The LISP-SEC threat model, described in Section 4, is built on top of the LISP threat model defined in [RFC7835], which includes a detailed description of an "overclaiming" attack.
ロケーター/ID分離プロトコル（LISP）[RFC9300] [RFC9301]は、IPアドレスを2つの新しい番号付けスペースに分離できるネットワーク層ベースのプロトコルです：エンドポイント識別子（EID）とルーティングロケーター（RLOC）。Eid-to-RLOCマッピングは、データベースとLISPマッピングシステムに保存され、Map-Request/Map-Reply Lookupプロセスを介して利用可能になります。MAP-REPLYメッセージを通じて伝達されるこれらのEid-to-RLOCマッピングが整合性保護なしに送信される場合、敵はそれらを操作してコミュニケーションをハイジャックしたり、要求されたEIDに違反したり、敬意を表したり、拒否をマウントしたり、拒否されたりすることができます。-of-service（DDOS）攻撃。また、Map-Replyメッセージが無許可に輸送される場合、敵対的なLISPエンティティはEid-Prefixをオーバルし、悪意のあるトラフィックをリダイレクトすることができます。セクション4で説明されているLISP-SECの脅威モデルは、[RFC7835]で定義されたLISP脅威モデルの上に構築されており、「オーバーレイブル」攻撃の詳細な説明が含まれています。
This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages, ensuring that the sender of a Map-Reply that provides the location for a given EID-Prefix is entitled to do so according to the EID-Prefix registered in the associated Map-Server. Map-Register/Map-Notify security, including the right for a LISP entity to register an EID-Prefix or to claim presence at an RLOC, is out of the scope of LISP-SEC, as those protocols are protected by the security mechanisms specified in [RFC9301]. However, LISP-SEC extends the Map-Register message to allow an Ingress Tunnel Router (ITR) to downgrade to non-LISP-SEC Map-Requests. Additional security considerations are described in Section 7.
このメモは、Mapping Lookupプロセスを介して伝えられるLISPのEIDからRLOCへのマッピングデータに対して、Origin Authentication、Integrity、およびAnti Replay保護を提供する一連のセキュリティメカニズムであるLISP-SECを指定します。LISP-SECは、MAP-ReplyメッセージのEID-Prefixクレームに関する承認の検証も可能にし、特定のEid-Prefixの場所を提供するMAP-Replyの送信者が、登録されているEID-Prefixに従って行う権利があることを確認することができます関連するマップサーバーで。LISPエンティティがEID-PREFIXを登録したりRLOCで存在を請求する権利を含むMAP-Register/Map-Notifyセキュリティは、それらのプロトコルは指定されたセキュリティメカニズムによって保護されているため、LISP-SECの範囲外です。[RFC9301]で。ただし、LISP-SECはマップ登録メッセージを拡張して、イングレストンネルルーター（ITR）を非リスプSECマップレクエストにダウングレードできるようにします。追加のセキュリティ上の考慮事項については、セクション7で説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
One-Time Key (OTK): An ephemeral randomly generated key that must be used for a single Map-Request/Map-Reply exchange.
ワンタイムキー（OTK）：単一のMap-Request/Map Reply Exchangeに使用する必要があるはかないランダムに生成されたキー。
ITR One-Time Key (ITR-OTK): The One-Time Key generated at the Ingress Tunnel Router (ITR).
ITRワンタイムキー（ITR-OTK）：イングレストンネルルーター（ITR）で生成された1回限りのキー。
MS One-Time Key (MS-OTK): The One-Time Key generated at the Map-Server.
MS One-Time Key（MS-OTK）：Map-Serverで生成された1回限りのキー。
Authentication Data (AD): Metadata that is included either in a LISP Encapsulated Control Message (ECM) header as defined in [RFC9301], or in a Map-Reply message to support confidentiality, integrity protection, and verification of EID-Prefix authorization.
認証データ（AD）：[RFC9301]で定義されているLISPカプセル化コントロールメッセージ（ECM）ヘッダー、またはEID-PREFIX認証の秘密、整合性保護、および検証をサポートするためのMAP Replyメッセージのいずれかに含まれるメタデータ。
OTK Authentication Data (OTK-AD): The portion of ECM Authentication Data that contains a One-Time Key.
OTK認証データ（OTK-AD）：1回限りのキーを含むECM認証データの部分。
EID Authentication Data (EID-AD): The portion of ECM and Map-Reply Authentication Data used for verification of EID-Prefix authorization.
EID認証データ（EID-AD）：EID-Prefix認証の検証に使用されるECMおよびMAP-Reply認証データの部分。
Packet Authentication Data (PKT-AD): The portion of Map-Reply Authentication Data used to protect the integrity of the Map-Reply message.
パケット認証データ（PKT-AD）：MAP-Replyメッセージの整合性を保護するために使用されるMAP-Reply認証データの部分。
For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), and Map-Resolver (MR), please consult the LISP specification [RFC9301].
他の用語の定義、特にMap-Request、Map-Reply、Ingress Tunnelルーター（ITR）、出口トンネルルーター（ETR）、マップサーバー（MS）、およびMap-Resolver（MR）については、LISP仕様を参照してください[RFC9301]。
LISP-SEC addresses the control plane threats, described in Sections 3.7 and 3.8 of [RFC7835], that target EID-to-RLOC mappings, including manipulations of Map-Request and Map-Reply messages and malicious ETR EID-Prefix overclaiming. LISP-SEC makes two main assumptions: (1) the LISP Mapping System is expected to deliver a Map-Request message to their intended destination ETR as identified by the EID, and (2) no on-path attack can be mounted within the LISP Mapping System. How the Mapping System is protected from on-path attacks depends on the particular Mapping System used and is out of the scope of this memo. Furthermore, while LISP-SEC enables detection of EID-Prefix overclaiming attacks, it assumes that Map-Servers can verify the EID-Prefix authorization at registration time.
LISP-SECは、[RFC7835]のセクション3.7および3.8で説明されているコントロールプレーンの脅威に対処します。これは、マップリケストおよびマップリクエストの操作、悪意のあるETR EID-PREFIXのオーバークレームを含むEIDからRLOCへのマッピングをターゲットにしています。LISP-SECは2つの主な仮定を作成します。（1）LISPマッピングシステムは、EIDによって識別されたように、意図した宛先ETRにマップリクエストメッセージを配信することが期待されています。マッピングシステム。マッピングシステムがオンパス攻撃から保護される方法は、使用される特定のマッピングシステムに依存し、このメモの範囲外です。さらに、LISP-SECはEID-Prefixオーバークレイジング攻撃の検出を可能にしますが、MAPサーバーは登録時にEID-Prefixの承認を検証できることを前提としています。
According to the threat model described in [RFC7835], LISP-SEC assumes that any kind of attack, including on-path attacks, can be mounted outside of the boundaries of the LISP Mapping System. An on-path attacker outside of the LISP Mapping System can, for example, hijack Map-Request and Map-Reply messages, spoofing the identity of a LISP node. Another example of an on-path attack, called an overclaiming attack, can be mounted by a malicious ETR by overclaiming the EID-Prefixes for which it is authoritative. In this way, the ETR can maliciously redirect traffic.
[RFC7835]に記載されている脅威モデルによると、LISP-SECは、パス上の攻撃を含むあらゆる種類の攻撃をLISPマッピングシステムの境界の外側に取り付けることができると想定しています。LISPマッピングシステムの外側のパス攻撃者は、たとえば、Hijack Map-RequestおよびMap Replyメッセージをハイジャックして、LISPノードのアイデンティティをスプーフィングできます。オーバーレイビング攻撃と呼ばれるパス上の攻撃の別の例は、それが権威あるEID-PREFIXをオーバーレイートすることにより、悪意のあるETRによって取り付けることができます。このようにして、ETRはトラフィックを悪意を持ってリダイレクトできます。
The goal of the security mechanisms defined in [RFC9301] is to prevent unauthorized insertion of mapping data by providing origin authentication and integrity protection for the Map-Register and by using the nonce to detect an unsolicited Map-Reply sent by off-path attackers.
[RFC9301]で定義されているセキュリティメカニズムの目標は、MAP-Registerのオリジン認証と整合性保護を提供し、NONCEを使用してオフパス攻撃者から送信された未承諾のMAP-Replyを検出することにより、マッピングデータの不正な挿入を防ぐことです。
LISP-SEC builds on top of the security mechanisms defined in [RFC9301] to address the threats described in Section 4 by leveraging the trust relationships existing among the LISP entities [RFC9301] participating in the exchange of the Map-Request/Map-Reply messages. Those trust relationships (see also Section 7 and [RFC9301]) are used to securely distribute, as described in Section 8.4, a per-message One-Time Key (OTK) that provides origin authentication, integrity, and anti-replay protection to mapping data conveyed via the mapping lookup process and that effectively prevents overclaiming attacks. The processing of security parameters during the Map-Request/Map-Reply exchange is as follows:
LISP-SECは、[RFC9301]で定義されているセキュリティメカニズムの上に構築され、MAP-Request/Map-Replyメッセージの交換に参加するLISPエンティティ[RFC9301]の間に存在する信頼関係を活用することにより、セクション4に記載されている脅威に対処します。。これらの信頼関係（セクション7および[RFC9301]も参照）を使用して、セクション8.4で説明されているように、マッピングに起源認証、整合性、およびレプレイ防止防止を提供する1回限りの1回限りのキー（OTK）で使用されます。マッピングルックアッププロセスを介して伝えられたデータは、オーバーリレーティング攻撃を効果的に防止します。Map-Request/Map-Reply Exchangeでのセキュリティパラメーターの処理は次のとおりです。
* Per each Map-Request message, a new ITR-OTK is generated and stored at the ITR and is securely transported to the Map-Server.
* 各MAP-Requestメッセージに従って、新しいITR-OTKが生成およびITRに保存され、マップサーバーにしっかりと輸送されます。
* The Map-Server uses the ITR-OTK to compute a Hashed Message Authentication Code (HMAC) [RFC2104] that protects the integrity of the mapping data known to the Map-Server to prevent overclaiming attacks. The Map-Server also derives a new OTK, the MS-OTK, that is passed to the ETR by applying a Key Derivation Function (KDF) (e.g., [RFC5869]) to the ITR-OTK.
* MAP-SERVERは、ITR-OTKを使用して、ハッシュされたメッセージ認証コード（HMAC）[RFC2104]を計算し、マップサーバーに知られているマッピングデータの整合性を保護して、オーバーレイブル攻撃を防ぎます。マップサーバーは、キー誘導関数（KDF）（例えば[RFC5869]）をITR-OTKに適用することにより、ETRに渡される新しいOTKであるMS-OTKを導き出します。
* The ETR uses the MS-OTK to compute an HMAC that protects the integrity of the Map-Reply sent to the ITR.
* ETRは、MS-OTKを使用して、ITRに送信されたマップ応答の整合性を保護するHMACを計算します。
* Finally, the ITR uses the stored ITR-OTK to verify the integrity of the mapping data provided by both the Map-Server and the ETR, and to verify that no overclaiming attacks were mounted along the path between the Map-Server and the ITR.
* 最後に、ITRは保存されているITR-OTKを使用して、MAP-ServerとETRの両方が提供するマッピングデータの整合性を検証し、Map-ServerとITRの間のパスに沿ってオーバークレーム攻撃がマウントされていないことを確認します。
Section 6 provides the detailed description of the LISP-SEC control messages and their processing, while the rest of this section describes the flow of LISP protocol operations at each entity involved in the Map-Request/Map-Reply exchange:
セクション6では、LISP-SEC制御メッセージとその処理の詳細な説明を提供しますが、このセクションの残りの部分では、MAP-Request/Map-Reply Exchangeに関与する各エンティティでのLISPプロトコル操作のフローについて説明します。
1. The ITR, upon needing to transmit a Map-Request message, generates and stores an OTK (ITR-OTK). This ITR-OTK is encrypted and included into the Encapsulated Control Message (ECM) that contains the Map-Request sent to the Map-Resolver.
1. ITRは、Map-Requestメッセージを送信する必要があるため、OTK（ITR-OTK）を生成および保存します。このITR-OTKは暗号化されており、MAP-Resolverに送信されたMAP-Requestを含むカプセル化コントロールメッセージ（ECM）に含まれています。
2. The Map-Resolver decapsulates the ECM, decrypts the ITR-OTK (if needed), and forwards through the Mapping System the received Map-Request and the ITR-OTK, as part of a new ECM. The LISP Mapping System delivers the ECM to the appropriate Map-Server, as identified by the EID destination address of the Map-Request.
2. MAP-ResolverはECMを脱カプセル化し、ITR-OTK（必要に応じて）を復号化し、新しいECMの一部として、受信したMap-RequestとITR-OTKをマッピングシステムから転送します。LISPマッピングシステムは、MAP-RequestのEID宛先アドレスで識別されるように、ECMを適切なマップサーバーに配信します。
3. The Map-Server is configured with the location mappings and policy information for the ETR responsible for the EID destination address. Using this preconfigured information, the Map-Server, after the decapsulation of the ECM, finds the longest-match EID-Prefix that covers the requested EID in the received Map-Request. The Map-Server adds this EID-Prefix, together with an HMAC computed using the ITR-OTK, to a new ECM that contains the received Map-Request.
3. Map-Serverは、EID宛先アドレスを担当するETRのロケーションマッピングとポリシー情報で構成されています。この事前に設定された情報を使用して、MAPサーバーは、ECMの脱カプセル化後、受信したMAP-Requestで要求されたEIDをカバーする最も長い試合のEID-Prefixを見つけます。Map-Serverは、このEid-Prefixを追加し、ITR-OTKを使用して計算されたHMACを、受信したMAP-Requestを含む新しいECMに追加します。
4. The Map-Server derives a new OTK, the MS-OTK, by applying a KDF to the ITR-OTK. This MS-OTK is included in the ECM that the Map-Server uses to forward the Map-Request to the ETR.
4. Map-Serverは、KDFをITR-OTKに適用することにより、新しいOTKであるMS-OTKを導き出します。このMS-OTKは、Map-ServerがMap-RequestをETRに転送するために使用するECMに含まれています。
5. If the Map-Server is acting in proxy mode, as specified in [RFC9301], the ETR is not involved in the generation of the Map-Reply and steps 6 and 7 are skipped. In this case, the Map-Server generates the Map-Reply on behalf of the ETR, as described in Section 6.7.2.
5. [RFC9301]で指定されているように、マップサーバーがプロキシモードで作用している場合、ETRはマップレプリーの生成に関与しておらず、ステップ6と7がスキップされます。この場合、セクション6.7.2で説明されているように、MAPサーバーはETRに代わってMAP-Replyを生成します。
6. The ETR, upon receiving the ECM-Encapsulated Map-Request from the Map-Server, decrypts the MS-OTK (if needed), and originates a Map-Reply that contains the EID-to-RLOC mapping information as specified in [RFC9301].
6. ETRは、Map-ServerからECMカプセル化されたMAP-Requestを受信すると、MS-OTK（必要に応じて）を復号化し、[RFC9301]で指定されているEIDからRLOCへのマッピング情報を含むマップ応答を発信します。。
7. The ETR computes an HMAC over the Map-Reply, keyed with MS-OTK to protect the integrity of the whole Map-Reply. The ETR also copies the EID-Prefix authorization data that the Map-Server included in the ECM-Encapsulated Map-Request into the Map-Reply message. The ETR then sends the complete Map-Reply message to the requesting ITR.
7. ETRは、MS-OTKを使用してMAP-Reply全体の完全性を保護するために、MS-OTKを使用してMAP-Replyを介してHMACを計算します。ETRは、ECMでカプセル化されたMAP-REQUESTにMAP-Replyメッセージに含まれるMAP-SERVERが含まれるEid-Prefix認証データもコピーします。その後、ETRは完全なマップ対応メッセージを要求ITRに送信します。
8. The ITR, upon receiving the Map-Reply, uses the locally stored ITR-OTK to verify the integrity of the EID-Prefix authorization data included in the Map-Reply by the Map-Server. The ITR computes the MS-OTK by applying the same KDF (as specified in the ECM-Encapsulated Map-Reply) used by the Map-Server and verifies the integrity of the Map-Reply.
8. ITRは、MAP-Replyを受信すると、ローカルに保存されたITR-OTKを使用して、MAP-ServerがMAP-Replyに含まれるEID-Prefix認証データの整合性を確認します。ITRは、MAP-Serverが使用する同じKDF（ECMカプセル化されたMAP-Replyで指定）を適用してMS-OTKを計算し、MAP Replyの完全性を検証します。
LISP-SEC metadata associated with a Map-Request is transported within the Encapsulated Control Message that contains the Map-Request.
Map-Requestに関連付けられたLISP-SECメタデータは、MAP-Requestを含むカプセル化されたコントロールメッセージ内で輸送されます。
LISP-SEC metadata associated with the Map-Reply is transported within the Map-Reply itself.
MAP Replyに関連付けられたLISP-SECメタデータは、マップ応答自体内で輸送されます。
These specifications use an HMAC in various places (as described in the following). The HMAC function AUTH-HMAC-SHA-256-128 [RFC6234] MUST be supported in LISP-SEC implementations. LISP-SEC deployments SHOULD use the AUTH-HMAC-SHA-256-128 HMAC function, except when communicating with older implementations that only support AUTH-HMAC-SHA-1-96 [RFC2104].
これらの仕様は、さまざまな場所でHMACを使用しています（以下で説明されています）。HMAC関数AUTH-HMAC-SHA-256-128 [RFC6234]は、LISP-SEC実装でサポートする必要があります。LISP-SECの展開は、Auth-HMAC-SHA-1-96 [RFC2104]のみをサポートする古い実装と通信する場合を除き、Auth-HMAC-SHA-256-128 HMAC関数を使用する必要があります。
LISP-SEC uses the ECM defined in [RFC9301] with the S-bit set to 1 to indicate that the LISP header includes Authentication Data (AD). The format of the LISP-SEC ECM AD is defined in Figure 1. OTK-AD stands for One-Time Key Authentication Data and EID-AD stands for EID Authentication Data.
LISP-SECは、[RFC9301]で定義されたECMを使用して、Sビットが1に設定されており、LISPヘッダーに認証データ（AD）が含まれていることを示します。LISP-SEC ECM ADの形式は、図1に定義されています。OTK-ADは、1回限りのキー認証データを表し、EID-ADはEID認証データの略です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECM AD Type | Unassigned | Requested HMAC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| OTK Length | Key ID | OTK Wrap. ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| One-Time-Key Preamble ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD
| ... One-Time-Key Preamble | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ One-Time Key (128 bits) ~/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
| EID-AD Length | KDF ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Record Count |E| Unassigned | EID HMAC ID |EID-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |
| Unassigned | EID mask-len | EID-AFI | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
~ EID-Prefix ... ~ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ |
~ EID HMAC ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
Figure 1: LISP-SEC ECM Authentication Data
図1：LISP-SEC ECM認証データ
ECM AD Type: 1 (LISP-SEC Authentication Data). See Section 8.
ECM ADタイプ：1（LISP-SEC認証データ）。セクション8を参照してください。
Unassigned: Set to 0 on transmission and ignored on receipt.
未割り当て：送信時に0に設定され、受領時に無視されます。
Requested HMAC ID: The HMAC algorithm, which will be used to protect the mappings, requested by the ITR. Permitted values are registered in the LISP-SEC Authentication Data HMAC ID (see Section 8.3). Refer to Section 6.4 for more details.
要求されたHMAC ID：ITRが要求するマッピングの保護に使用されるHMACアルゴリズム。許可された値は、LISP-SEC認証データHMAC IDに登録されています（セクション8.3を参照）。詳細については、セクション6.4を参照してください。
OTK Length: The length (in bytes) of the OTK Authentication Data (OTK-AD), which contains the OTK Preamble and the OTK.
OTK長：OTK認証データ（OTK-AD）の長さ（バイト単位）には、OTKプリアンブルとOTKが含まれています。
Key ID: The identifier of the pre-shared secret shared by an ITR and the Map-Resolver, and by the Map-Server and an ETR. Per-message keys are derived from the pre-shared secret to encrypt, authenticate the origin, and protect the integrity of the OTK. The Key ID allows to rotate between multiple pre-shared secrets in a nondisruptive way.
キーID：ITRとMAP-Resolver、およびMap-ServerとETRが共有する事前に共有された秘密の識別子。メッセージごとのキーは、オリジンを暗号化し、認証し、OTKの完全性を保護するための、恥ずかしさの秘密から派生しています。キーIDを使用すると、複数の事前に共有された秘密の間を破壊的な方法で回転させることができます。
OTK Wrapping ID (OTK Wrap. ID): The identifier of the Key Derivation Function and of the key wrapping algorithm used to encrypt the One-Time-Key. Permitted values are registered in the LISP-SEC Authentication Data Key Wrap ID (see Section 8.4). Refer to Section 6.5 for more details.
OTKラッピングID（OTKwrap。ID）：キー派生関数と、1回限りのキーを暗号化するために使用されるキーラッピングアルゴリズムの識別子。許可された値は、LISP-SEC認証データキーラップIDに登録されています（セクション8.4を参照）。詳細については、セクション6.5を参照してください。
One-Time-Key Preamble: Set to 0 if the OTK is not encrypted. When the OTK is encrypted, this field MAY carry additional metadata resulting from the key wrapping operation. When a 128-bit OTK is sent unencrypted by a Map-Resolver, the OTK Preamble is set to 0x0000000000000000 (64 bits). See Section 6.5.1 for details.
One-Time-Key Preamble：OTKが暗号化されていない場合は0に設定します。OTKが暗号化されると、このフィールドは、キーラッピング操作から生じる追加のメタデータを運ぶ場合があります。128ビットのOTKがマップ分解器によって暗号化されていない送信されると、OTKプリアンブルは0x000000000000000000（64ビット）に設定されます。詳細については、セクション6.5.1を参照してください。
One-Time-Key: The OTK wrapped as specified by OTK Wrapping ID. See Section 6.5 for details.
ワンタイムキー：OTKラッピングIDで指定されているように、OTKラップ。詳細については、セクション6.5を参照してください。
EID-AD Length: Length (in bytes) of the EID Authentication Data (EID-AD). The ITR MUST set the EID-AD Length to 4 bytes, as it only fills the 'KDF ID' field, and all the remaining fields part of the EID-AD are not present. An EID-AD MAY contain multiple EID-Records. Each EID-Record is 4 bytes long, plus the length of the AFI-encoded EID-Prefix.
EID-ADの長さ：EID認証データ（EID-AD）の長さ（バイト単位）。ITRは、eid-adの長さを4バイトに設定する必要があります。これは、「KDF ID」フィールドのみを埋めるため、Eid-ADの残りのすべてのフィールドが存在しないためです。EID-ADには、複数のEid-Recordが含まれる場合があります。各Eid-Recordの長さは4バイトで、Af-Encoded Eid-Prefixの長さです。
KDF ID: Identifier of the Key Derivation Function used to derive the MS-OTK. Permitted values are registered in the LISP-SEC Authentication Data Key Derivation Function ID (see Section 8.5). Refer to Section 6.7 for more details.
KDF ID：MS-OTKの導出に使用されるキー導出関数の識別子。許可された値は、LISP-SEC認証データキー派生関数IDに登録されています（セクション8.5を参照）。詳細については、セクション6.7を参照してください。
Record Count: As defined in Section 5.2 of [RFC9301].
記録数：[RFC9301]のセクション5.2で定義されています。
E: ETR-Cant-Sign bit. If this bit is set to 1, it signals to the ITR that at least one of the ETRs that is authoritative for the EID-Prefixes of this Map-Reply has not enabled LISP-SEC. Only a Map-Server can set this bit. See Section 6.7 for more details.
E：ETR-CANT-SIGN BIT。このビットが1に設定されている場合、このマップReplyのEID-PREFIXESの権威あるETRの少なくとも1つがLISP-secを有効にしていないことをITRに信号します。マップサーバーのみがこのビットを設定できます。詳細については、セクション6.7を参照してください。
Unassigned: Set to 0 on transmission and ignored on receipt.
未割り当て：送信時に0に設定され、受領時に無視されます。
EID HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the EID-AD. This field is filled by the Map-Server that computed the EID-Prefix HMAC. See Section 6.7.1 for more details.
EID HMAC ID：EID-ADの完全性を保護するために使用されるHMACアルゴリズムの識別子。このフィールドは、Eid-Prefix HMACを計算したマップサーバーによって満たされています。詳細については、セクション6.7.1を参照してください。
EID mask-len: As defined in Section 5.2 of [RFC9301].
Eid Mask-Len：[RFC9301]のセクション5.2で定義されています。
EID-AFI: As defined in Section 5.2 of [RFC9301].
EID-AFI：[RFC9301]のセクション5.2で定義されています。
EID-Prefix: As defined in Section 5.2 of [RFC9301].
EID-PREFIX：[RFC9301]のセクション5.2で定義されています。
EID HMAC: HMAC of the EID-AD computed and inserted by a Map-Server. See Section 6.7.1 for more details.
Eid HMAC：Map-Serverによって計算され、挿入されたEid-ADのHMAC。詳細については、セクション6.7.1を参照してください。
LISP-SEC uses the Map-Reply defined in [RFC9301], with Type set to 2 and S-bit set to 1 to indicate that the Map-Reply message includes Authentication Data (AD). The format of the LISP-SEC Map-Reply Authentication Data is defined in Figure 2. PKT-AD is the Packet Authentication Data that covers the Map-Reply payload.
LISP-SECは[RFC9301]で定義されたマップ応答を使用し、タイプは2に設定され、Sビットは1に設定されており、MAP-Replyメッセージに認証データ（AD）が含まれていることを示します。LISP-sec Map-Reply認証データの形式は、図2に定義されています。PKT-ADは、MAP-REPLYペイロードをカバーするパケット認証データです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MR AD Type | Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
| EID-AD Length | KDF ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Record Count | Unassigned | EID HMAC ID |EID-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |
| Unassigned | EID mask-len | EID-AFI | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
~ EID-Prefix ... ~ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ |
~ EID HMAC ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
| PKT-AD Length | PKT HMAC ID |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ PKT HMAC ~PKT-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
Figure 2: LISP-SEC Map-Reply Authentication Data
図2：LISP-secマップ繰り返し認証データ
MR AD Type: 1 (LISP-SEC Authentication Data). See Section 8.
MR ADタイプ：1（LISP-SEC認証データ）。セクション8を参照してください。
EID-AD Length: Length (in bytes) of the EID-AD (see Section 6.1).
EID-ADの長さ：EID-ADの長さ（バイト単位）（セクション6.1を参照）。
KDF ID: Identifier of the Key Derivation Function used to derive MS-OTK (see Section 6.1).
KDF ID：MS-OTKの導出に使用されるキー導出関数の識別子（セクション6.1を参照）。
Record Count: The number of records in this Map-Reply message (see Section 6.1).
レコードカウント：このマップ応答メッセージのレコード数（セクション6.1を参照）。
Unassigned: Set to 0 on transmission and ignored on receipt.
未割り当て：送信時に0に設定され、受領時に無視されます。
EID HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the EID-AD (see Section 6.1).
EID HMAC ID：EID-ADの完全性を保護するために使用されるHMACアルゴリズムの識別子（セクション6.1を参照）。
EID mask-len: Mask length for EID-Prefix (see Section 6.1).
Eid Mask-Len：Eid-Prefixのマスク長さ（セクション6.1を参照）。
EID-AFI: See Section 6.1.
EID-AFI：セクション6.1を参照してください。
EID-Prefix: See Section 6.1.
Eid-Prefix：セクション6.1を参照してください。
EID HMAC: See Section 6.1.
Eid HMAC：セクション6.1を参照してください。
PKT-AD Length: Length (in bytes) of the Packet Authentication Data (PKT-AD).
PKT-ADの長さ：パケット認証データ（PKT-AD）の長さ（バイト単位）。
PKT HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the Map-Reply (see Section 6.5).
PKT HMAC ID：MAP-Replyの整合性を保護するために使用されるHMACアルゴリズムの識別子（セクション6.5を参照）。
PKT HMAC: HMAC of the whole Map-Reply packet to protect its integrity, including the LISP-SEC Authentication Data (from the 'Map-Reply Type' field to the 'PKT HMAC' field), which allow message authentication.
PKT HMAC：メッセージ認証を可能にするLISP-SEC認証データ（「Map-Reply Type」フィールドから「PKT HMAC」フィールドまで）を含む、その整合性を保護するためのマップReplyパケット全体のHMAC。
The S-bit in the Map-Register message (see [RFC9301]) indicates to the Map-Server that the registering ETR is LISP-SEC enabled. An ETR that supports LISP-SEC MUST set the S-bit in its Map-Register messages.
Map-RegisterメッセージのSビット（[RFC9301]を参照）は、登録ETRがLISP-SEC有効であることをMAPサーバーに示します。LISP-SECをサポートするETRは、マップ登録メッセージにSビットを設定する必要があります。
Upon creating a Map-Request, the ITR generates a random ITR-OTK that is stored locally, until the corresponding Map-Reply is received (see Section 6.9), together with the nonce generated as specified in [RFC9301].
MAP-Requestを作成すると、ITRは、[RFC9301]で指定されているように生成されたNONCEとともに、対応するマップ応答が受信されるまで、ローカルに保存されるランダムITR-OTKを生成します。
The ITR MAY use the 'KDF ID' field to indicate the recommended KDF algorithm according to local policy. The Map-Server can overwrite the KDF ID if it does not support the KDF ID recommended by the ITR (see Section 6.7). A KDF value of NOPREF (0) may be used to specify that the ITR has no preferred KDF ID.
ITRは、「KDF ID」フィールドを使用して、ローカルポリシーに従って推奨されるKDFアルゴリズムを示す場合があります。Map-Serverは、ITRが推奨するKDF IDをサポートしていない場合、KDF IDを上書きできます（セクション6.7を参照）。nopref（0）のKDF値を使用して、ITRに優先KDF IDがないことを指定できます。
ITR-OTK confidentiality and integrity protection MUST be provided in the path between the ITR and the Map-Resolver. This can be achieved either by encrypting the ITR-OTK with the pre-shared secret known to the ITR and the Map-Resolver (see Section 6.5) or by enabling DTLS [RFC9147] between the ITR and the Map-Resolver.
ITR-OTKの機密性と整合性保護は、ITRとMAP-Resolverの間のパスで提供する必要があります。これは、ITRとMAP-Resolver（セクション6.5を参照）に知られている事前に共有された秘密を使用してITR-OTKを暗号化するか、ITRとMAP-Resolverの間でDTLS [RFC9147]を有効にすることによって達成できます。
The Map-Request (as defined in [RFC9301]) MUST be encapsulated as a LISP Control Message in an ECM, with the S-bit set to 1, to indicate the presence of Authentication Data. Such a message is also called a "Protected Map-Request" in this memo.
認証データの存在を示すために、MAP-Request（[RFC9301]で定義されている）は、Sビットが1に設定されたECMのLISPコントロールメッセージとしてカプセル化する必要があります。このようなメッセージは、このメモの「保護されたマップレクエスト」とも呼ばれます。
The ITR-OTK is wrapped with the algorithm specified by the 'OTK Wrapping ID' field. See Section 6.5 for further details on OTK encryption. If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is selected, and no other encryption mechanism (e.g., DTLS) is enabled in the path between the ITR and the Map-Resolver, the Map-Request MUST be dropped, and an appropriate log action SHOULD be taken. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.
ITR-OTKは、「OTKラッピングID」フィールドで指定されたアルゴリズムで包まれています。OTK暗号化の詳細については、セクション6.5を参照してください。null-key-wrap-128アルゴリズム（セクション8.4を参照）が選択されており、ITRとMAP-Resolverの間のパスで他の暗号化メカニズム（DTLなど）が有効になっていない場合、マップ再リケストを削除する必要があります。適切なログアクションを実行する必要があります。実装には、ログリソースの消耗攻撃を避けるためのメカニズム（このドキュメントの範囲を超えています）が含まれる場合があります。
The 'Requested HMAC ID' field contains the suggested HMAC algorithm to be used by the Map-Server and the ETR to protect the integrity of the ECM Authentication Data and of the Map-Reply. A HMAC ID value of NONE (0) MAY be used to specify that the ITR has no preferred HMAC ID.
「要求されたHMAC ID」フィールドには、ECM認証データとMAP-Replyの整合性を保護するために、MAPサーバーとETRが使用する提案されたHMACアルゴリズムが含まれています。（0）のHMAC ID値を使用して、ITRに優先HMAC IDがないことを指定できます。
The 'KDF ID' field specifies the suggested Key Derivation Function to be used by the Map-Server to derive the MS-OTK. A KDF value of NONE (0) may be used to specify that the ITR has no preferred KDF ID.
「KDF ID」フィールドは、MS-OTKを導出するためにマップサーバーによって使用される提案されたキー導出関数を指定します。none（0）のKDF値を使用して、ITRに優先KDF IDがないことを指定できます。
The EID-AD Length is set to 4 bytes, since the Authentication Data does not contain EID-Prefix Authentication Data, and the EID-AD contains only the 'KDF ID' field.
認証データにはEID-Prefix認証データが含まれておらず、EID-ADには「KDF ID」フィールドのみが含まれているため、EID-ADの長さは4バイトに設定されています。
If the ITR is directly connected to a Mapping System, such as LISP+ALT [RFC6836], it performs the functions of both the ITR and the Map-Resolver, forwarding the Protected Map-Request as described in Section 6.6.
ITRがLISP ALT [RFC6836]などのマッピングシステムに直接接続されている場合、ITRとMAP-Resolverの両方の関数を実行し、セクション6.6で説明したように保護されたマップリケストを転送します。
The processing performed by Proxy ITRs (PITRs) is equivalent to the processing of an ITR; hence, the procedure described above applies.
プロキシITR（PITR）によって実行される処理は、ITRの処理と同等です。したがって、上記の手順が適用されます。
MS-OTK confidentiality and integrity protection MUST be provided in the path between the Map-Server and the ETR. This can be achieved either by enabling DTLS between the Map-Server and the ETR or by encrypting the MS-OTK with the pre-shared secret known to the Map-Server and the ETR [RFC9301].
MS-OTKの機密性と整合性保護は、Map-ServerとETRの間のパスで提供する必要があります。これは、Map-ServerとETRの間のDTLを有効にするか、MS-OTKをMAP-SERVERとETR [RFC9301]に知られている事前共有秘密で暗号化することによって達成できます。
Similarly, ITR-OTK confidentiality and integrity protection MUST be provided in the path between the ITR and the Map-Resolver. This can be achieved either by enabling DTLS between the Map-Server and the ITR or by encrypting the ITR-OTK with the pre-shared secret known to the ITR and the Map-Resolver. The ITR/Map-Resolver pre-shared key is similar to the Map-Server/ETR pre-shared key.
同様に、ITR-OTKの機密性と整合性保護は、ITRとMAP-Resolverの間のパスで提供する必要があります。これは、Map-ServerとITRの間のDTLを有効にするか、ITR-OTKをITR-OTKをITRとMAP-Resolverに知られている事前に共有する秘密を暗号化することで実現できます。ITR/MAP-Resolver Pre-Sharedキーは、Map-Server/ETR Pre-Sharedキーに似ています。
This section describes OTK processing in the ITR/Map-Resolver path, as well as in the Map-Server/ETR path.
このセクションでは、ITR/MAP-ResolverパスとMAP-SERVER/ETRパスでのOTK処理について説明します。
It's important to note that, to prevent ETR's overclaiming attacks, the ITR/Map-Resolver pre-shared secret MUST be independent from the Map-Server/ETR pre-shared secret.
ETRのオーバークレイジング攻撃を防ぐために、ITR/Map-Resolver Pre-Shared Secretは、Map-Server/ETRの事前共有秘密から独立している必要があることに注意することが重要です。
The OTK is wrapped using the algorithm specified in the 'OTK Wrapping ID' field. This field identifies both the:
OTKは、「OTKラッピングID」フィールドで指定されたアルゴリズムを使用してラップされます。このフィールドは両方の識別を示します。
* Key Encryption Algorithm used to encrypt the wrapped OTK and
* ラップされたOTKを暗号化するために使用されるキー暗号化アルゴリズムと
* Key Derivation Function used to derive a per-message encryption key.
* キー派生関数は、暗号化ごとのキーを導出するために使用されます。
Implementations of this specification MUST support the OTK Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256, which specifies the use of the HKDF-SHA256 Key Derivation Function specified in [RFC5869] to derive a per-message encryption key (per-msg-key), as well as the AES-KEY-WRAP-128 key wrap algorithm used to encrypt a 128-bit OTK, according to [RFC3394].
この仕様の実装は、[RFC5869]で指定されたHKDF-SHA256キー派生関数の使用を指定するために、出没暗号化キーを導出するために[RFC5869]で指定されたHKDF-SHA256キー派生関数の使用を指定するOTKラッピングID AES-KEY-WRAP-128 HKDF-SHA256をサポートする必要があります。-Key）、および[RFC3394]によると、128ビットOTKを暗号化するために使用されるAES-Key-Wrap-128キーラップアルゴリズム。
Implementations of this specification MUST support OTK Wrapping NULL-KEY-WRAP-128. NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 64-bit preamble set to 0x0000000000000000 (64 bits).
この仕様の実装は、OTKラッピングNull-Key-Wrap-128をサポートする必要があります。null-key-wrap-128は、64ビットのプリアンブルが0x00000000000000000000（64ビット）に設定された、暗号化されていない128ビットOTKを運ぶために使用されます。
The key wrapping process for OTK Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256 is described below:
OTKラッピングID AES-KEY-WRAP-128 HKDF-SHA256の主要なラッピングプロセスを以下に説明します。
1. The KDF and key wrap algorithms are identified by the value of the 'OTK Wrapping ID' field. The initial values are documented in Table 5.
1. KDFおよびキーラップアルゴリズムは、「OTKラッピングID」フィールドの値によって識別されます。初期値を表5に文書化します。
2. If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is selected and DTLS is not enabled, the Map-Request MUST be dropped and an appropriate log action SHOULD be taken. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.
2. null-key-wrap-128アルゴリズム（セクション8.4を参照）が選択され、DTLSが有効になっていない場合、マップリケストを削除する必要があり、適切なログアクションを実行する必要があります。実装には、ログリソースの消耗攻撃を避けるためのメカニズム（このドキュメントの範囲を超えています）が含まれる場合があります。
3. The pre-shared secret used to derive the per-msg-key is represented by PSK[Key ID], which is the pre-shared secret identified by the 'Key ID'.
3. PSG-Keyを導き出すために使用される事前に共有された秘密は、PSK [キーID]で表されます。
4. The 128-bit-long per-message encryption key is computed as:
4. 128ビットの延長された1人あたりの暗号化キーは、次のように計算されます。
per-msg-key = KDF( nonce + s + PSK[Key ID] )
where the nonce is the value in the 'Nonce' field of the Map-Request, 's' is the string "OTK-Key-Wrap", and the operation'+' just indicates string concatenation.
NonceはMap-Requestの「NonCe」フィールドの値である場合、「S s」は「otk-key-wrap」であり、操作 ''は文字列の連結を示します。
5. The per-msg-key is then used to wrap the OTK with AES-KEY-WRAP-128, as specified in Section 2.2.1 of [RFC3394]. The AES Key Wrap Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). The output of the AES key wrap operation is 192 bits long. The most significant 64 bits are copied in the 'One-Time Key Preamble' field, while the 128 least significant bits are copied in the 'One-Time Key' field of the LISP-SEC Authentication Data.
5. 次に、[RFC3394]のセクション2.2.1で指定されているように、PER-MSG-KEYを使用して、AES-Key-Wrap-128でOTKをラップします。AESキーラップ初期化値は、0xA6A6A6A6A6A6A6A6（64ビット）に設定する必要があります。AESキーラップ操作の出力の長さは192ビットです。最も重要な64ビットは「1回限りのキープリアンブル」フィールドにコピーされ、128の最小重要なビットはLISP-SEC認証データの「1回限りのキー」フィールドにコピーされます。
When decrypting an encrypted OTK, the receiver MUST verify that the Initialization Value resulting from the AES key wrap decryption operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails, the receiver MUST discard the entire message.
暗号化されたOTKを復号化する場合、受信者は、AESキーラップ復号化操作から生じる初期化値が0xA6A6A6A6A6A6A6A6A6に等しいことを確認する必要があります。この検証が失敗した場合、受信者はメッセージ全体を破棄する必要があります。
However, when DTLS is enabled, the OTK MAY be sent unencrypted as transport layer security is providing confidentiality and integrity protection.
ただし、DTLSが有効になっている場合、輸送層のセキュリティが機密性と整合性の保護を提供しているため、OTKが暗号化されていないと送信される場合があります。
When a 128-bit OTK is sent unencrypted, the OTK Wrapping ID is set to NULL_KEY_WRAP_128, and the OTK Preamble is set to 0x0000000000000000 (64 bits).
128ビットOTKが暗号化されていない場合、OTKラッピングIDがnull_key_wrap_128に設定され、OTKプリアンブルは0x000000000000000000（64ビット）に設定されます。
Upon receiving a Protected Map-Request, the Map-Resolver decapsulates the ECM. The ITR-OTK, if encrypted, is decrypted as specified in Section 6.5.
保護されたマップリクエストを受信すると、MAP-ResolverはECMを脱カプセル化します。ITR-OTKは、暗号化されている場合、セクション6.5で指定されているように復号化されます。
Protecting the confidentiality of the ITR-OTK and, in general, the security of how the Map-Request is handed by the Map-Resolver to the Map-Server is specific to the particular Mapping System used and is outside of the scope of this memo.
ITR-OTKの機密性を保護し、一般に、マップリケストがマップリゾルバーによってどのように渡されるかのセキュリティをマップサーバーに保護します。。
In Mapping Systems where the Map-Server is compliant with [RFC9301], the Map-Resolver originates a new ECM header with the S-bit set, which contains the unencrypted ITR-OTK, as specified in Section 6.5, and the other data derived from the ECM Authentication Data of the received Encapsulated Map-Request.
マップサーバーが[RFC9301]に準拠しているマッピングシステムでは、MAP-Resolverは、セクション6.5で指定されているように、暗号化されていないITR-OTKを含むSビットセットを備えた新しいECMヘッダーを発信し、他のデータは派生した他のデータを含みます。受信したカプセル化されたMAP-RequestのECM認証データから。
The Map-Resolver then forwards to the Map-Server the received Map-Request, which is encapsulated in the new ECM header that includes the newly computed 'Authentication Data' fields.
その後、Map-Resolverは、受信したMap-Requestをマップサーバーに転送します。これは、新しく計算された「認証データ」フィールドを含む新しいECMヘッダーにカプセル化されています。
Upon receiving a Protected Map-Request, the Map-Server processes it according to the setting of the S-bit and the P-bit in the Map-Register received from the ETRs authoritative for that prefix, as described below.
保護されたマップリクエストを受信すると、MAPサーバーは、以下で説明するように、そのプレフィックスに対して権威あるETRSから受け取ったMAP-registerのSビットとPビットの設定に応じて処理します。
While processing the Map-Request, the Map-Server can overwrite the 'KDF ID' field if it does not support the KDF ID recommended by the ITR. Processing of the Map-Request MUST proceed in the order described in the table below, applying the process corresponding to the first rule that matches the conditions indicated in the first column:
Map-Requestの処理中、Map-Serverは、ITRが推奨するKDF IDをサポートしていない場合、「KDF ID」フィールドを上書きできます。Map-Requestの処理は、以下の表に記載されている順序で続行する必要があります。最初の列に示されている条件に一致する最初のルールに対応するプロセスを適用する必要があります。
+=================+==============================================+
| Matching | Processing |
| Condition | |
+=================+==============================================+
| 1. At least | The Map-Server MUST generate a LISP-SEC- |
| one of the ETRs | protected Map-Reply, as specified in |
| authoritative | Section 6.7.2. The ETR-Cant-Sign E-bit in |
| for the EID- | the EID Authentication Data (EID-AD) MUST be |
| Prefix included | set to 0. |
| in the Map- | |
| Request | |
| registered with | |
| the P-bit set | |
| to 1 | |
+-----------------+----------------------------------------------+
| 2. At least | The Map-Server MUST generate a LISP-SEC- |
| one of the ETRs | protected Encapsulated Map-Request (as |
| authoritative | specified in Section 6.7.1) to be sent to |
| for the EID- | one of the authoritative ETRs that |
| Prefix included | registered with the S-bit set to 1 (and the |
| in the Map- | P-bit set to 0). If there is at least one |
| Request | ETR that registered with the S-bit set to 0, |
| registered with | the ETR-Cant-Sign E-bit of the EID-AD MUST |
| the S-bit set | be set to 1 to signal the ITR that a non- |
| to 1 | LISP-SEC Map-Request might reach additional |
| | ETRs that have LISP-SEC disabled. |
+-----------------+----------------------------------------------+
| 3. All the | The Map-Server MUST send a Negative Map- |
| ETRs | Reply protected with LISP-SEC, as described |
| authoritative | in Section 6.7.2. The ETR-Cant-Sign E-bit |
| for the EID- | MUST be set to 1 to signal the ITR that a |
| Prefix included | non-LISP-SEC Map-Request might reach |
| in the Map- | additional ETRs that have LISP-SEC disabled. |
| Request | |
| registered with | |
| the S-bit set | |
| to 0 | |
+-----------------+----------------------------------------------+
Table 1: Map-Request Processing
表1：マップレクエスト処理
In this way, the ITR that sent a LISP-SEC-protected Map-Request always receives a LISP-SEC-protected Map-Reply. However, the ETR-Cant-Sign E-bit set to 1 specifies that a non-LISP-SEC Map-Request might reach additional ETRs that have LISP-SEC disabled. This mechanism allows the ITR to downgrade to non-LISP-SEC requests, which does not protect against threats described in Section 4.
このようにして、LISP-SECで保護されたMAP-Requestを送信したITRは、常にLISP-SECで保護されたMAP Replyを受信します。ただし、1に設定されたETR-CANT-SIGN EBITセットは、LISP-SECが無効になっている追加のETRに到達する可能性があることを指定しています。このメカニズムにより、ITRは、セクション4で説明されている脅威から保護しない非リスプSEC要求に格下げできます。
The Map-Server decapsulates the ECM and generates new ECM Authentication Data. The Authentication Data includes the OTK-AD and the EID-AD, which contains EID-Prefix authorization information that are eventually received by the requesting ITR.
Map-ServerはECMを脱カプセル化し、新しいECM認証データを生成します。認証データには、OTK-ADとEID-ADが含まれています。これには、最終的にRequirening ITRによって受信されるEID-Prefix認証情報が含まれています。
The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from the ITR-OTK received with the Map-Request. MS-OTK is derived by applying the Key Derivation Function specified in the 'KDF ID' field. If the algorithm specified in the 'KDF ID' field is not supported, the Map-Server uses a different algorithm to derive the key and updates the 'KDF ID' field accordingly.
MAP-SERVERは、MAP-Requestで受信したITR-OTKから新しいOTK（MS-OTK）を導出することにより、OTK-ADを更新します。MS-OTKは、「KDF ID」フィールドで指定されたキー導出関数を適用することにより導出されます。「KDF ID」フィールドで指定されたアルゴリズムがサポートされていない場合、MAPServerは別のアルゴリズムを使用してキーを導き出し、それに応じて「KDF ID」フィールドを更新します。
The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 1, to indicate the presence of Authentication Data.
認証データの存在を示すために、Sビットが1に設定されたECMでMAP-Requestをカプセル化する必要があります。
MS-OTK is wrapped with the algorithm specified by the 'OTK Wrapping ID' field. See Section 6.5 for further details on OTK encryption. If the NULL-KEY-WRAP-128 algorithm is selected and DTLS is not enabled in the path between the Map-Server and the ETR, the Map-Request MUST be dropped and an appropriate log action SHOULD be taken.
MS-OTKは、「OTKラッピングID」フィールドで指定されたアルゴリズムで包まれています。OTK暗号化の詳細については、セクション6.5を参照してください。null-key-wrap-128アルゴリズムが選択され、MAP-SERVERとETRの間のパスでDTLSが有効になっていない場合、MAP-Requestをドロップし、適切なログアクションを実行する必要があります。
In the EID-AD, the Map-Server includes in the EID-AD the longest-match-registered EID-Prefix for the destination EID and an HMAC of this EID-Prefix. The HMAC is keyed with the ITR-OTK contained in the received ECM Authentication Data, and the HMAC algorithm is chosen according to the 'Requested HMAC ID' field. If the Map-Server does not support this algorithm, the Map-Server uses a different algorithm and specifies it in the 'EID HMAC ID' field. The scope of the HMAC operation MUST cover the entire EID-AD, from the 'EID-AD Length' field to the 'EID HMAC' field, which MUST be set to 0 before the computation.
EID-ADでは、Map-Serverには、EID-ADに、宛先EIDの最長登録されたEid-PrefixとこのEid-PrefixのHMACが含まれています。HMACは、受信したECM認証データに含まれるITR-OTKでキー化されており、HMACアルゴリズムは「要求されたHMAC ID」フィールドに従って選択されます。Map-Serverがこのアルゴリズムをサポートしていない場合、Map-Serverは別のアルゴリズムを使用し、「Eid HMAC ID」フィールドで指定します。HMAC操作の範囲は、「EID-ADの長さ」フィールドから「Eid HMAC」フィールドまで、計算前に0に設定する必要がある「Eid-ADの長さ」フィールド全体をカバーする必要があります。
The Map-Server then forwards the updated ECM-Encapsulated Map-Request, which contains the OTK-AD, the EID-AD, and the received Map-Request to an authoritative ETR as specified in [RFC9301].
MAPサーバーは、[RFC9301]で指定されているように、OTK-AD、EID-AD、および受信したMAP-REQUESTを信頼できるETRに含む、更新されたECMカプセル化されたMap-Requestを転送します。
A LISP-SEC proxy Map-Reply is generated according to [RFC9301], with the Map-Reply S-bit set to 1. The Map-Reply includes the Authentication Data that contains the EID-AD computed as specified in Section 6.7.1, as well as the PKT-AD computed as specified in Section 6.8.
LISP-SECプロキシマップReplyは、[RFC9301]に従って生成され、MAP-Reply S-Bitは1に設定されています。マップReplyには、セクション6.7.1で指定されているように計算されたEID-ADを含む認証データが含まれています。、およびセクション6.8で指定されているように計算されたPKT-AD。
Upon receiving an ECM-Encapsulated Map-Request with the S-bit set, the ETR decapsulates the ECM. The 'OTK' field, if encrypted, is decrypted as specified in Section 6.5 to obtain the unencrypted MS-OTK.
Sビットセットを使用してECMカプセル化MAP-Requestを受信すると、ETRはECMを脱カプセル化します。「OTK」フィールドは、暗号化されている場合は、暗号化されていないMS-OTKを取得するためにセクション6.5で指定されているように復号化されます。
The ETR then generates a Map-Reply as specified in [RFC9301] and includes the Authentication Data that contains the EID-AD, as received in the Encapsulated Map-Request, as well as the PKT-AD.
次に、ETRは[RFC9301]で指定されているようにMAP-Replyを生成し、カプセル化されたMAP-Requestで受信したように、PKT-ADで受信したEID-ADを含む認証データを含みます。
The EID-AD is copied from the Authentication Data of the received Encapsulated Map-Request.
EID-ADは、受信したカプセル化されたMAP-Requestの認証データからコピーされます。
The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed with the MS-OTK and computed using the HMAC algorithm specified in the 'Requested HMAC ID' field of the received Encapsulated Map-Request. If the ETR does not support the Requested HMAC ID, it uses a different algorithm and updates the 'PKT HMAC ID' field accordingly. The HMAC operation MUST cover the entire Map-Reply, where the 'PKT HMAC' field MUST be set to 0 before the computation.
PKT-ADには、MS-OTKでキーを付け、受信したカプセル化されたMAP-Requestの「要求されたHMAC ID」フィールドで指定されたHMACアルゴリズムを使用して計算されたマップReplyパケット全体のHMACが含まれています。ETRが要求されたHMAC IDをサポートしていない場合、異なるアルゴリズムを使用し、それに応じて「PKT HMAC ID」フィールドを更新します。HMAC操作は、MAP Reply全体をカバーする必要があります。この場合、「PKT HMAC」フィールドは計算前に0に設定する必要があります。
Finally, the ETR sends the Map-Reply to the requesting ITR as specified in [RFC9301].
最後に、ETRは[RFC9301]で指定されているように、マップ応答を要求ITRに送信します。
In response to a Protected Map-Request, an ITR expects a Map-Reply with the S-bit set to 1, including an EID-AD and a PKT-AD. The ITR MUST discard the Map-Reply otherwise.
保護されたMAP-Requestに応じて、ITRは、EID-ADとPKT-ADを含むSビットセットが1に設定されたマップ応答を期待しています。ITRは、それ以外の場合はマップ応答を破棄する必要があります。
Upon receiving a Map-Reply, the ITR must verify the integrity of both the EID-AD and the PKT-AD and MUST discard the Map-Reply if one of the integrity checks fails. After processing the Map-Reply, the ITR MUST discard the <nonce,ITR-OTK> pair associated to the Map-Reply.
MAP-Replyを受信すると、ITRはEID-ADとPKT-ADの両方の整合性を検証し、整合性チェックのいずれかが失敗した場合にMAP Replyを破棄する必要があります。MAP-Replyを処理した後、ITRはマップ応答に関連付けられた<nonce、itr-otk>ペアを破棄する必要があります。
The integrity of the EID-AD is verified using the ITR-OTK (stored locally for the duration of this exchange) to recompute the HMAC of the EID-AD using the algorithm specified in the 'EID HMAC ID' field. If the ITR did indicate a Requested HMAC ID in the Map-Request and the PKT HAMC ID in the corresponding Map-Reply is different, or if the ITR did not indicate a Requested HMAC ID in the Map-Request and the PKT HMAC ID in the corresponding Map-Reply is not supported, then the ITR MUST discard the Map-Reply and send, according to rate-limitation policies defined in [RFC9301], a new Map-Request with a different 'Requested HMAC ID' field, according to ITR's local policy. The scope of the HMAC operation covers the entire EID-AD, from the 'EID-AD Length' field to the 'EID HMAC' field.
EID-ADの整合性は、ITR-OTK（この交換の期間中に局所的に保存されている）を使用して検証され、「EID HMAC ID」フィールドで指定されたアルゴリズムを使用してEID-ADのHMACを再計算します。ITRがMAP-Requestで要求されたHMAC IDを示し、対応するマップリプのPKT HAMC IDが異なる場合、またはITRがMAP-Requestで要求されたHMAC IDを示していない場合対応するマップ応答はサポートされていません。その後、ITRは、[RFC9301]で定義されたレートリミテーションポリシーに従って、マップ応答を破棄して送信する必要があります。ITRのローカルポリシー。HMAC操作の範囲は、「Eid-ADの長さ」フィールドから「Eid HMAC」フィールドまで、Eid-AD全体をカバーしています。
ITR MUST set the 'EID HMAC ID' field to 0 before computing the HMAC.
ITRは、HMACを計算する前に、「Eid HMAC ID」フィールドを0に設定する必要があります。
To verify the integrity of the PKT-AD, first the MS-OTK is derived from the locally stored ITR-OTK using the algorithm specified in the 'KDF ID' field. This is because the PKT-AD is generated by the ETR using the MS-OTK. If the ITR did indicate a recommended KDF ID in the Map-Request and the KDF ID in the corresponding Map-Reply is different or if the ITR did not indicate a recommended KDF ID in the Map-Request and the KDF ID in the corresponding Map-Reply is not supported, then the ITR MUST discard the Map-Reply and send, according to rate-limitation policies defined in [RFC9301], a new Map-Request with a different KDF ID, according to ITR's local policy. The Key Derivation Function HKDF-SHA256 MUST be supported in LISP-SEC implementations. LISP-SEC deployments SHOULD use the HKDF-SHA256 HKDF function, unless older implementations using HKDF-SHA1-128 are present in the same deployment. Without consistent configuration of involved entities, extra delays may be experienced. However, since HKDF-SHA1-128 and HKDF-SHA256 are supported, the process will eventually converge.
PKT-ADの整合性を検証するために、最初にMS-OTKは、「KDF ID」フィールドで指定されたアルゴリズムを使用して、ローカルに保存されたITR-OTKから派生します。これは、PKT-ADがMS-OTKを使用してETRによって生成されるためです。 ITRがMAP-Requestで推奨されるKDF IDを示し、対応するマップリプリーのKDF IDが異なる場合、またはITRがMAP-Requestで推奨されるKDF IDを示していない場合、対応するマップでKDF ID -Replyはサポートされていません。ITRは、[RFC9301]で定義されているレートリミテーションポリシーに従って、MAP-Replyを破棄して送信する必要があります。ITRのローカルポリシーによると、異なるKDF IDを含む新しいMAP-Requestがあります。キー導出関数HKDF-SHA256は、LISP-SEC実装でサポートする必要があります。 LISP-SECの展開は、HKDF-SHA1-128を使用した古い実装が同じ展開に存在しない限り、HKDF-SHA256 HKDF関数を使用する必要があります。関係するエンティティの一貫した構成がなければ、追加の遅延が発生する場合があります。ただし、HKDF-SHA1-128およびHKDF-SHA256がサポートされているため、プロセスは最終的に収束します。
The derived MS-OTK is then used to recompute the HMAC of the PKT-AD using the algorithm specified in the 'PKT HMAC ID' field. If the 'PKT HMAC ID' field does not match the Requested HMAC ID, the ITR MUST discard the Map-Reply and send, according to rate-limitation policies defined in [RFC9301], a new Map-Request with a different Requested HMAC ID, according to ITR's local policy or until all HMAC IDs supported by the ITR have been attempted. When the 'PKT HMAC ID' field does not match the Requested HMAC ID, it is not possible to validate the Map-Reply.
次に、派生したMS-OTKを使用して、「PKT HMAC ID」フィールドで指定されたアルゴリズムを使用してPKT-ADのHMACを再計算します。「PKT HMAC ID」フィールドが要求されたHMAC IDと一致しない場合、ITRは[RFC9301]で定義されているレートリミテーションポリシーに従って、MAP-Replyを破棄して送信する必要があります。、ITRのローカルポリシーによると、またはITRによってサポートされているすべてのHMAC IDが試行されるまで。「PKT HMAC ID」フィールドが要求されたHMAC IDと一致しない場合、MAP Replyを検証することはできません。
Each individual Map-Reply EID-Record is considered valid only if: (1) both EID-AD and PKT-AD are valid and (2) the intersection of the EID-Prefix in the Map-Reply EID-Record with one of the EID-Prefixes contained in the EID-AD is not empty. After identifying the Map-Reply record as valid, the ITR sets the EID-Prefix in the Map-Reply record to the value of the intersection set computed before and adds the Map-Reply EID-Record to its EID-to-RLOC Map-Cache, as described in [RFC9301]. An example of Map-Reply record validation is provided in Section 6.9.1.
個々のMAP-REPLY EID-RECORDは、次の場合にのみ有効と見なされます。（1）EID-ADとPKT-ADの両方が有効であり、（2）MAP Reply Eid-RecordのEID-PREFIXの交差点とEID-ADに含まれるEid-Prefixesは空ではありません。Map-Reply Recordを有効であると特定した後、ITRはMAP-ReplyレコードのEid-Prefixを前に計算した交差点セットの値に設定し、Eid-to-RLOCマップにマップのReply Eid-Recordを追加します - [RFC9301]で説明されているように、キャッシュ。MAP-Reply Record検証の例は、セクション6.9.1に記載されています。
[RFC9301] allows ETRs to send Solicit-Map-Requests (SMRs) directly to the ITR. The corresponding SMR-invoked Map-Request will be sent through the Mapping System, hence, secured with the specifications of this memo if in use. If an ITR accepts Map-Replies piggybacked in Map-Requests and its content is not already present in its EID-to-RLOC Map-Cache, it MUST send a Map-Request over the Mapping System in order to verify its content with a secured Map-Reply before using the content.
[RFC9301]により、ETRはSolict-Map-Requests（SMRS）をITRに直接送信できます。対応するSMRに誘惑されるMap-Requestは、マッピングシステムを介して送信されるため、使用中にこのメモの仕様で固定されます。ITRがMAP-Requestsでピギーバックされたマップレプリーを受け入れ、そのコンテンツがEIDからRLOCへのマップキャッシュにまだ存在していない場合、セキュリティでコンテンツを確認するためにマッピングシステムにマップリケストを送信する必要があります。コンテンツを使用する前にマップ応答。
The payload of a Map-Reply may contain multiple EID-Records. The whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide integrity protection and origin authentication to the EID-Prefix records claimed by the ETR. The 'Authentication Data' field of a Map-Reply may contain multiple EID-Records in the EID-AD. The EID-AD is signed by the Map-Server, with the EID HMAC, to provide integrity protection and origin authentication to the EID-Prefix records inserted by the Map-Server.
Map-Replyのペイロードには、複数のEid-Recordが含まれる場合があります。Map Reply全体がETRによって署名され、PKT HMACと署名され、ETRが主張するEid-Prefixレコードに整合性保護と原点認証を提供します。MAP-Replyの「認証データ」フィールドには、EID-ADに複数のEIDレコードが含まれる場合があります。EID-ADは、Map-Serverが挿入したEID-Prefixレコードに整合性保護と原点認証を提供するために、EID HMACとマップサーバーによって署名されています。
Upon receiving a Map-Reply with the S-bit set, the ITR first checks the validity of both the EID HMAC and of the PKT-AD HMAC. If either one of the HMACs is not valid, a log action SHOULD be taken and the Map-Reply MUST NOT be processed any further. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks. If both HMACs are valid, the ITR proceeds with validating each individual EID-Record claimed by the ETR by computing the intersection of each one of the EID-Prefixes contained in the payload of the Map-Reply, with each one of the EID-Prefixes contained in the EID-AD. An EID-Record is valid only if at least one of the intersections is not the empty set; otherwise, a log action MUST be taken and the EID-Record MUST be discarded. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.
S-BITセットでMAP-Replyを受信すると、ITRは最初にEid HMACとPKT-AD HMACの両方の有効性をチェックします。HMACSのいずれかが有効でない場合は、ログアクションを実行する必要があり、マップ応答をさらに処理してはなりません。実装には、ログリソースの消耗攻撃を避けるためのメカニズム（このドキュメントの範囲を超えています）が含まれる場合があります。両方のHMACが有効である場合、ITRは、ETRが請求される各EID記録を検証し、MAP-Replyのペイロードに含まれるEid-Prefixesのそれぞれの交差点を計算し、それぞれがEid-Prefixesのそれぞれを計算します。Eid-Adに含まれています。Eid-Recordは、交差点の少なくとも1つが空のセットではない場合にのみ有効です。それ以外の場合、ログアクションを実行する必要があり、Eid-Recordを破棄する必要があります。実装には、ログリソースの消耗攻撃を避けるためのメカニズム（このドキュメントの範囲を超えています）が含まれる場合があります。
For instance, the Map-Reply payload contains 3 mapping record EID-Prefixes:
たとえば、Map-Replyペイロードには、3つのマッピングレコードEid-Prefixesが含まれています。
2001:db8:102::/48
2001:db8:103::/48
2001:db8:200::/40
The EID-AD contains two EID-Prefixes:
EID-ADには2つのEID-PREFIXが含まれています。
2001:db8:103::/48
2001:db8:203::/48
The EID-Record with EID-Prefix 2001:db8:102::/48 is not eligible to be used by the ITR, since it is not included in any of the EID-ADs signed by the Map-Server. A log action MUST be taken, and the EID-Record MUST be discarded. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.
Eid-Prefix 2001のEid-Record：DB8：102 ::/48は、Map-Serverが署名したEID-ADのいずれにも含まれていないため、ITRが使用する資格がありません。ログアクションを実行する必要があり、Eid-Recordを破棄する必要があります。実装には、ログリソースの消耗攻撃を避けるためのメカニズム（このドキュメントの範囲を超えています）が含まれる場合があります。
The EID-Record with EID-Prefix 2001:db8:103::/48 is eligible to be used by the ITR because it matches the second EID-Prefix contained in the EID-AD.
Eid-Prefix 2001のEid-Record：DB8：103 ::/48は、EID-ADに含まれる2番目のEid-Prefixと一致するため、ITRが使用する資格があります。
The EID-Record with EID-Prefix 2001:db8:200::/40 is not eligible to be used by the ITR, since it is not included in any of the EID-ADs signed by the Map-Server. A log action MUST be taken and the EID-Record MUST be discarded. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks. In this last example, the ETR is trying to over claim the EID-Prefix 2001:db8:200::/40, but the Map-Server authorized only 2001:db8:203::/48; hence, the EID-Record is discarded.
Eid-Prefix 2001のEid-Record：DB8：200 ::/40は、Map-Serverが署名したEid-ADのいずれにも含まれていないため、ITRが使用する資格がありません。ログアクションを実行する必要があり、Eid-Recordを破棄する必要があります。実装には、ログリソースの消耗攻撃を避けるためのメカニズム（このドキュメントの範囲を超えています）が含まれる場合があります。この最後の例では、ETRはEid-Prefix 2001：db8：200 ::/40を過剰に主張しようとしていますが、Map-Serverは2001年のみを承認しました：DB8：203 ::/48;したがって、Eid-Recordは破棄されます。
This document extends the LISP control plane defined in [RFC9301]; hence, its security considerations apply to this document as well.
このドキュメントは、[RFC9301]で定義されているLISP制御プレーンを拡張します。したがって、そのセキュリティ上の考慮事項は、このドキュメントにも当てはまります。
The LISP-SEC threat model described in Section 4 assumes that the LISP Mapping System is working properly and delivers Map-Request messages to a Map-Server that is authoritative for the requested EID.
セクション4で説明されているLISP-SECの脅威モデルは、LISPマッピングシステムが適切に機能していることを前提としており、要求されたEIDに対して権威ある地図販売者にMap-Requestメッセージを配信します。
It is assumed that the Mapping System ensures the confidentiality of the OTK and the integrity of the Map-Reply data. However, how the LISP Mapping System is secured is out of the scope of this document.
マッピングシステムは、OTKの機密性とマップ応答データの整合性を保証すると想定されています。ただし、LISPマッピングシステムの保護方法は、このドキュメントの範囲外です。
Similarly, Map-Register security, including the right for a LISP entity to register an EID-Prefix or to claim presence at an RLOC, is out of the scope of LISP-SEC.
同様に、LISPエンティティがEID-Prefixを登録したり、RLOCで存在を請求する権利を含むマップ登録セキュリティは、LISP-SECの範囲外です。
The ITR-OTK MUST be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security-sensitive random data.
ITR-OTKは、適切にシードされた擬似ランダム（または強力なランダム）ソースによって生成される必要があります。セキュリティに敏感なランダムデータの生成に関するアドバイスについては、[RFC4086]を参照してください。
If the Map-Server and the ETR are colocated, LISP-SEC does not provide protection from overclaiming attacks mounted by the ETR. However, in this particular case, since the ETR is within the trust boundaries of the Map-Server, ETR's overclaiming attacks are not included in the threat model.
MAP-SERVERとETRがコロッキングされている場合、LISP-SECはETRによって取り付けられたオーバークレイジング攻撃からの保護を提供しません。ただし、この特定のケースでは、ETRはMap-Serverの信頼境界内にあるため、ETRのオーバーレイティング攻撃は脅威モデルに含まれていません。
Those deploying LISP-SEC according to this memo should carefully weigh how the LISP-SEC threat model applies to their particular use case or deployment. If they decide to ignore a particular recommendation, they should make sure the risk associated with the corresponding threats is well understood.
このメモに従ってLISP-SECを展開する人は、LISP-SECの脅威モデルが特定のユースケースまたは展開にどのように適用されるかを慎重に検討する必要があります。特定の推奨事項を無視することにした場合、対応する脅威に関連するリスクがよく理解されていることを確認する必要があります。
As an example, in certain other deployments, attackers may be very sophisticated and force the deployers to enforce very strict policies in terms of HMAC algorithms accepted by an ITR.
例として、特定の他の展開では、攻撃者は非常に洗練されており、展開者にITRが受け入れたHMACアルゴリズムの観点から非常に厳格なポリシーを強制せざるを得ません。
Similar considerations apply to the entire LISP-SEC threat model and should guide the deployers and implementors whenever they encounter the key word SHOULD across this memo.
同様の考慮事項は、LISP-SECの脅威モデル全体に適用され、このメモ全体でキーワードが遭遇する場合はいつでも、展開者と実装者をガイドする必要があります。
Provisioning of the keys shared between ITR and Map-Resolver pairs as well as between ETR and Map-Server pairs should be performed via an orchestration infrastructure, and is out of the scope of this memo. It is recommended that both shared keys be refreshed at periodical intervals to address key aging or attackers gaining unauthorized access to the shared keys. Shared keys should be unpredictable random values.
ITRとMAP-Resolverペアの間で共有されるキーのプロビジョニング、およびETRとMAP-SERVERペアの間では、オーケストレーションインフラストラクチャを介して実行する必要があり、このメモの範囲外です。両方の共有キーを定期的な間隔で更新して、キーの老化に対処するか、共有キーへの不正アクセスを得る攻撃者に対処することをお勧めします。共有キーは、予測不可能なランダム値である必要があります。
An attacker can capture a valid Map-Request and/or Map-Reply and replay it; however, once the ITR receives the original Map-Reply, the <nonce,ITR-OTK> pair stored at the ITR will be discarded. If a replayed Map-Reply arrives at the ITR, there is no <nonce,ITR-OTK> that matches the incoming Map-Reply and the replayed Map-Reply will be discarded.
攻撃者は、有効なMAP-Requestおよび/またはMap Replyをキャプチャして再生できます。ただし、ITRが元のMap-Replyを受信すると、ITRに保存されている<Nonce、ITR-OTK>ペアが破棄されます。リプレイされたMAP-ReplyがITRに到着した場合、着信マップの繰り返しに一致する<nonce、itr-otk>はありません。
In the case of a replayed Map-Request, the Map-Server, Map-Resolver, and ETR will have to do a LISP-SEC computation. This is equivalent, in terms of resources, to a valid LISP-SEC computation and, beyond a risk of DoS attack, an attacker does not obtain any additional effect, since the corresponding Map-Reply is discarded as previously explained.
再生されたMAP-Requestの場合、MAPサーバー、MAP-Resolver、およびETRは、LISP-SEC計算を行う必要があります。これは、リソースの観点から有効なLISP-SEC計算に相当し、DOS攻撃のリスクを超えて、攻撃者は追加の効果を得られません。
DTLS [RFC9147] SHOULD be used (conforming to [RFC7525]) to provide communication privacy and to prevent eavesdropping, tampering, or message forgery to the messages exchanged between the ITR, Map-Resolver, Map-Server, and ETR, unless the OTK is encrypted in another way, e.g., using a pre-shared secret. DTLS has the responder be verified by the initiator, which enables an ITR to authenticate the Map-Resolver and the Map-Server to authenticate the responding ETR.
DTLS [RFC9147]を使用して（[RFC7525]、[RFC7525]に準拠している）、コミュニケーションのプライバシーを提供し、otkを除き、ITR、Map-Resolver、Map-Server、およびETRの間で交換されるメッセージに盗聴、改ざん、またはメッセージの偽造を防止する必要があります。別の方法で暗号化されます。たとえば、事前に共有された秘密を使用しています。DTLSは、イニシエーターによってレスポンダーを検証しているため、ITRはMAP-ResolverとMap-Serverを認証して応答性のあるETRを認証できます。
LISP-SEC mitigates the risks of DoS and DDoS attacks by protecting the integrity and authenticating the origin of the Map-Request/Map-Reply messages and by preventing malicious ETRs from overclaiming EID-Prefixes that could redirect traffic directed to a potentially large number of hosts.
LISP-SECは、整合性を保護し、MAP-Request/Map-Replyメッセージの起源を認証し、悪意のあるETRが潜在的に多数のトラフィックに向けられたトラフィックをリダイレクトできるEID-PREFIXEをオーバークレームするのを防ぐことにより、DOSおよびDDOS攻撃のリスクを軽減します。ホスト。
IANA has created the subregistries listed in the following sections in the "Locator/ID Separation Protocol (LISP) Parameters" registry.
IANAは、「ロケーター/ID分離プロトコル（LISP）パラメーター」レジストリに次のセクションにリストされているサブレジストリを作成しました。
For all of the subregistries, new values are assigned according to the Specification Required policy defined in [RFC8126]. Expert Review should assess the security properties of newly added functions so that encryption robustness remains strong. For instance, at the time of this writing, the use of SHA-256-based functions is considered to provide sufficient protection. Consultation with security experts may be needed.
すべてのサブレジストリについて、[RFC8126]で定義されている仕様が必要な仕様に従って新しい値が割り当てられます。エキスパートレビューは、暗号化の堅牢性が強いままであるように、新しく追加された関数のセキュリティプロパティを評価する必要があります。たとえば、この執筆時点では、SHA-256ベースの機能の使用は、十分な保護を提供すると考えられています。セキュリティの専門家との協議が必要になる場合があります。
IANA has created the "LISP ECM Authentication Data Types" registry with values 0-255 for use in the ECM LISP-SEC extensions (see Section 6.1). Initial allocations are shown in Table 2.
IANAは、ECM LISP-SEC拡張機能で使用するために値0-255を持つ「LISP ECM認証データ型」レジストリを作成しました（セクション6.1を参照）。初期割り当てを表2に示します。
+==================+========+============+
| Name | Number | Defined in |
+==================+========+============+
| Reserved | 0 | RFC 9303 |
+------------------+--------+------------+
| LISP-SEC-ECM-EXT | 1 | RFC 9303 |
+------------------+--------+------------+
Table 2: LISP ECM Authentication Data Types
表2：LISP ECM認証データ型
Values 2-255 are unassigned.
値2-255は割り当てられていません。
IANA has created the "LISP Map-Reply Authentication Data Types" registry with values 0-255 for use in the Map-Reply LISP-SEC extensions (see Section 6.2). Initial allocations are shown in Table 3.
IANAは、Map Reply Lisp-SEC拡張機能で使用するために、値0-255を持つ「LISP Map Map Reply認証データ型」レジストリを作成しました（セクション6.2を参照）。初期割り当てを表3に示します。
+=================+========+============+
| Name | Number | Defined in |
+=================+========+============+
| Reserved | 0 | RFC 9303 |
+-----------------+--------+------------+
| LISP-SEC-MR-EXT | 1 | RFC 9303 |
+-----------------+--------+------------+
Table 3: Map-Reply Authentication Data Types
表3：マップ対応認証データ型
Values 2-255 are unassigned.
値2-255は割り当てられていません。
IANA is requested to create the "LISP-SEC Preferred Authentication Data HMAC IDs" registry with values 0-65535 for use as Requested HMAC IDs, EID HMAC IDs, and PKT HMAC IDs in the LISP-SEC Authentication Data. Initial allocations are shown in Table 4.
IANAは、LISP-SEC認証データに要求されたHMAC ID、EID HMAC ID、およびPKT HMAC IDSとして使用するために、値0-65535の「LISP-SEC優先認証データHMAC IDS」レジストリを作成するように要求されます。初期割り当てを表4に示します。
+=======================+========+============+
| Name | Number | Defined in |
+=======================+========+============+
| NOPREF | 0 | RFC 9303 |
+-----------------------+--------+------------+
| AUTH-HMAC-SHA-1-96 | 1 | [RFC2104] |
+-----------------------+--------+------------+
| AUTH-HMAC-SHA-256-128 | 2 | [RFC6234] |
+-----------------------+--------+------------+
Table 4: LISP-SEC Preferred Authentication Data HMAC IDs
表4：LISP-SEC優先認証データHMAC IDS
Values 3-65535 are unassigned.
値3-65535は割り当てられていません。
IANA has created the "LISP-SEC Authentication Data Key Wrap IDs" registry with values 0-65535 for use as OTK key wrap algorithm IDs in the LISP-SEC Authentication Data. Initial allocations are shown in Table 5.
IANAは、LISP-SEC認証データでOTKキーラップアルゴリズムIDとして使用するために、値0-65535を持つ「LISP-SEC認証データキーラップIDS」レジストリを作成しました。初期割り当てを表5に示します。
+==============================+======+=========+=========+=========+
| Name |Number|Key Wrap |KDF |Reference|
+==============================+======+=========+=========+=========+
| Reserved | 0 |None |None |RFC 9303 |
+------------------------------+------+---------+---------+---------+
| NULL-KEY-WRAP-128 | 1 |RFC 9303 |None |RFC 9303 |
+------------------------------+------+---------+---------+---------+
| AES-KEY-WRAP-128+HKDF-SHA256 | 2 |[RFC3394]|[RFC4868]|RFC 9303 |
+------------------------------+------+---------+---------+---------+
Table 5: LISP-SEC Authentication Data Key Wrap IDs
表5：LISP-SEC認証データキーラップID
Values 3-65535 are unassigned.
値3-65535は割り当てられていません。
IANA has created the "LISP-SEC Authentication Data Key Derivation Function IDs" registry with values 0-65535 for use as KDF IDs. Initial allocations are shown in Table 6.
IANAは、KDF IDSとして使用するために値0-65535を持つ「LISP-SEC認証データキー派生関数IDS」レジストリを作成しました。初期割り当てを表6に示します。
+===============+========+===========+
| Name | Number | Reference |
+===============+========+===========+
| NOPREF | 0 | RFC 9303 |
+---------------+--------+-----------+
| HKDF-SHA1-128 | 1 | [RFC5869] |
+---------------+--------+-----------+
| HKDF-SHA256 | 2 | [RFC5869] |
+---------------+--------+-----------+
Table 6: LISP-SEC Authentication Data Key Derivation Function IDs
表6：LISP-SEC認証データキー派生関数IDS
Values 3-65535 are unassigned.
値3-65535は割り当てられていません。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、DOI 10.17487/RFC2104、1997年2月、<https：//www.rfc-editor.org/info/rfc2104>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[RFC3394] Schaad、J。and R. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、DOI 10.17487/RFC3394、2002年9月、<https://www.rfc-editor.org/info/RFC3394>。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
[RFC4868] Kelly、S。and S. Frankel、「HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512を使用してIPSECを使用して」、RFC 4868、DOI 10.17487/RFC4868、2007年5月、<HTTPS：//www.rfc-editor.org/info/rfc4868>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー誘導関数（HKDF）」、RFC 5869、DOI 10.17487/RFC5869、2010年5月、<https：//ww.rfc-editor.org/info/rfc5869>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234] EastLake 3rd、D。およびT. Hansen、「米国安全なハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487/RFC6234、2011年5月、<https：//ww.rfc-editor.org/info/rfc6234>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「輸送層セキュリティ（TLS）およびデータグラム輸送層セキュリティ（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487/RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.
[RFC7835] Saucez、D.、Iannone、L。、およびO. Bonaventure、「ロケーター/ID分離プロトコル（LISP）脅威分析」、RFC 7835、DOI 10.17487/RFC7835、2016年4月、<https：//ww.rfc-editor.org/info/rfc7835>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.
[RFC9300] Farinacci、D.、Fuller、V.、Meyer、D.、Lewis、D.、およびA. Cabellos、ed。、「ロケーター/ID分離プロトコル（LISP）」、RFC 9300、DOI 10.17487/RFC9300、2022年10月、<https://www.rfc-editor.org/info/rfc9300>。
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.
[RFC9301] Farinacci、D.、Maino、F.、Fuller、V。、およびA. Cabellos、ed。、「Locator/ID分離プロトコル（LISP）コントロールプレーン」、RFC 9301、DOI 10.17487/RFC9301、10月2022年、<https://www.rfc-editor.org/info/rfc9301>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487/RFC4086、2005年6月、<https：//www.rfc-editor.org/info/rfc4086>。
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[RFC6836] Fuller、V.、Farinacci、D.、Meyer、D。、およびD. Lewis、「ロケーター/ID分離プロトコル代替論理トポロジ（LISP ALT）」、RFC 6836、DOI 10.17487/RFC6836、2013年1月、<<<<https://www.rfc-editor.org/info/rfc6836>。
Acknowledgments
謝辞
The authors would like to acknowledge Luigi Iannone, Pere Monclus, Dave Meyer, Dino Farinacci, Brian Weis, David McGrew, Darrel Lewis, and Landon Curt Noll for their valuable suggestions provided during the preparation of this document.
著者は、この文書の準備中に提供された貴重な提案について、Luigi Iannone、Pere Monclus、Dave Meyer、Dino Farinacci、Brian Weis、David McGrew、Darrel Lewis、Landon Curt Nollに感謝します。
Authors' Addresses
著者のアドレス
Fabio Maino Cisco Systems San Jose, CA United States of America Email: fmaino@cisco.com
Fabio Maino Cisco Systems San Jose、CA Neciment States of America Email：fmaino@cisco.com
Vina Ermagan Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: ermagan@gmail.com
Vina Ermagan Google、Inc。1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国電子メール：ermagan@gmail.com
Albert Cabellos Universitat Politecnica de Catalunya c/ Jordi Girona s/n 08034 Barcelona Spain Email: acabello@ac.upc.edu
Albert Cabellos Universitat Politecnica de Catalunya C/ Jordi Girona S/ N 08034バルセロナスペインメール：acabello@ac.upc.edu
Damien Saucez Inria 2004 route des Lucioles - BP 93 Sophia Antipolis France Email: damien.saucez@inria.fr
Damien Saucez Inria 2004 Route Des Lucioles -BP 93 Sophia Antipolis France Email：damien.saucez@inria.fr