[要約] RFC 8061は、LISPデータプレーンの機密性に関するプロトコルであり、LISPトラフィックの暗号化とセキュリティを提供することを目的としています。
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 8061 lispers.net
Category: Experimental B. Weis
ISSN: 2070-1721 Cisco Systems
February 2017
Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality
ロケータ/ ID分離プロトコル（LISP）データプレーンの機密性
Abstract
概要
This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.
このドキュメントでは、Locator / ID Separation Protocol（LISP）を使用してカプセル化されたトラフィックを暗号化するメカニズムについて説明します。この設計では、既存のLISPコントロールプレーンメカニズムを使用してキー交換を実現する方法と、サードパーティの監視攻撃からLISPデータプレーンを保護する方法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc8061.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8061で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Definition of Terms .............................................4
4. Overview ........................................................4
5. Diffie-Hellman Key Exchange .....................................5
6. Encoding and Transmitting Key Material ..........................6
7. Shared Keys Used for the Data Plane .............................8
8. Data-Plane Operation ...........................................10
9. Procedures for Encryption and Decryption .......................11
10. Dynamic Rekeying ..............................................12
11. Future Work ...................................................13
12. Security Considerations .......................................14
12.1. SAAG Support .............................................14
12.2. LISP-Crypto Security Threats .............................14
13. IANA Considerations ...........................................15
14. References ....................................................16
14.1. Normative References .....................................16
14.2. Informative References ...................................17
Acknowledgments ...................................................18
Authors' Addresses ................................................18
This document describes a mechanism for encrypting LISP-encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.
このドキュメントでは、LISPカプセル化トラフィックを暗号化するメカニズムについて説明します。この設計では、既存のLISPコントロールプレーンメカニズムを使用してキー交換を実現する方法と、サードパーティの監視攻撃からLISPデータプレーンを保護する方法について説明します。
The Locator/ID Separation Protocol [RFC6830] defines a set of functions for routers to exchange information used to map from non-routable Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). LISP Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs) and Re-encapsulating Tunnel Routers (RTRs). Packets that arrive at the ITR or PITR may not be encrypted, which means no protection or privacy of the data is added. When the source host encrypts the data stream, encapsulated packets do not need to be encrypted by LISP. However, when plaintext packets are sent by hosts, this design can encrypt the user payload to maintain privacy on the path between the encapsulator (the ITR or PITR) to a decapsulator (ETR or RTR). The encrypted payload is unidirectional. However, return traffic uses the same procedures but with different key values by the same xTRs or potentially different xTRs when the paths between LISP sites are asymmetric.
ロケーター/ ID分離プロトコル[RFC6830]は、ルーターがルーティング不可能なエンドポイント識別子（EID）からルーティング可能なルーティングロケーター（RLOC）へのマッピングに使用される情報を交換するための一連の関数を定義します。 LISP入力トンネルルーター（ITR）およびプロキシ入力トンネルルーター（PITR）は、出力トンネルルーター（ETR）および再カプセル化トンネルルーター（RTR）へのパケットをカプセル化します。 ITRまたはPITRに到着するパケットは暗号化されない場合があります。つまり、データの保護やプライバシーは追加されません。ソースホストがデータストリームを暗号化する場合、カプセル化されたパケットをLISPで暗号化する必要はありません。ただし、プレーンテキストパケットがホストによって送信される場合、この設計では、ユーザーペイロードを暗号化して、カプセル化装置（ITRまたはPITR）からカプセル開放装置（ETRまたはRTR）までのパスのプライバシーを維持できます。暗号化されたペイロードは単方向です。ただし、LISPサイト間のパスが非対称である場合、リターントラフィックは同じ手順を使用しますが、同じxTRまたは異なるxTRによる異なるキー値を使用します。
This document has the following requirements (as well as the general requirements from [RFC6973]) for the solution space:
このドキュメントには、ソリューションスペースに関する以下の要件（および[RFC6973]の一般的な要件）があります。
o Do not require a separate Public Key Infrastructure (PKI) that is out of scope of the LISP control-plane architecture.
o LISPコントロールプレーンアーキテクチャの範囲外の個別の公開キー基盤（PKI）を必要としないでください。
o The budget for key exchange MUST be one round-trip time. That is, only a two-packet exchange can occur.
o 鍵交換の予算は、1回の往復時間でなければなりません。つまり、2パケット交換のみが発生します。
o Use symmetric keying so faster cryptography can be performed in the LISP data plane.
o 対称キーイングを使用して、LISPデータプレーンでより高速な暗号化を実行できるようにします。
o Avoid a third-party trust anchor if possible.
o 可能であれば、サードパーティのトラストアンカーを使用しないでください。
o Provide for rekeying when secret keys are compromised.
o 秘密鍵が危険にさらされたときに鍵の再生成を提供します。
o Support Authenticated Encryption with packet integrity checks.
o パケットの整合性チェックで認証暗号化をサポートします。
o Support multiple Cipher Suites so new crypto algorithms can be easily introduced.
o 複数の暗号スイートをサポートするため、新しい暗号アルゴリズムを簡単に導入できます。
Satisfying the above requirements provides the following benefits:
上記の要件を満たすことにより、次の利点が得られます。
o Avoiding a PKI reduces the operational cost of managing a secure network. Key management is distributed and independent from any other infrastructure.
o PKIを回避することで、安全なネットワークを管理する運用コストを削減できます。キー管理は分散され、他のインフラストラクチャから独立しています。
o Packet transport is optimized due to fewer packet headers. Packet loss is reduced by a more efficient key exchange.
o パケットヘッダーが少ないため、パケット転送が最適化されます。パケット損失は、より効率的な鍵交換によって削減されます。
o Authentication and privacy are provided with a single mechanism thereby providing less per-packet overhead and therefore more resource efficiency.
o 認証とプライバシーは単一のメカニズムで提供されるため、パケットごとのオーバーヘッドが少なくなり、リソース効率が向上します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
AEAD: Authenticated Encryption with Associated Data [RFC5116]
AEAD：関連データを使用した認証済み暗号化[RFC5116]
ICV: Integrity Check Value
ICV：整合性チェック値
LCAF: LISP Canonical Address Format [RFC8060]
LCAF：LISP Canonical Address Format [RFC8060]
xTR: A general reference to ITRs, ETRs, RTRs, and PxTRs
xTR：ITR、ETR、RTR、およびPxTRへの一般的な参照
The approach proposed in this document is NOT to rely on the LISP mapping system (or any other key-infrastructure system) to store security keys. This will provide for a simpler and more secure mechanism. Secret shared keys will be negotiated between the ITR and the ETR in Map-Request and Map-Reply messages. Therefore, when an ITR needs to obtain the RLOC of an ETR, it will get security material to compute a shared secret with the ETR.
このドキュメントで提案されているアプローチは、セキュリティキーを格納するためにLISPマッピングシステム（またはその他のキーインフラストラクチャシステム）に依存するものではありません。これにより、よりシンプルで安全なメカニズムが提供されます。シークレット共有キーは、Map-RequestおよびMap-ReplyメッセージでITRとETRの間でネゴシエートされます。したがって、ITRがETRのRLOCを取得する必要がある場合、ITRとの共有秘密を計算するためのセキュリティ資料を取得します。
The ITR can compute three shared secrets per ETR the ITR is encapsulating to. When the ITR encrypts a packet before encapsulation, it will identify the key it used for the crypto calculation so the ETR knows which key to use for decrypting the packet after decapsulation. By using key-ids in the LISP header, we can also get fast rekeying functionality.
ITRは、ITRがカプセル化しているETRごとに3つの共有秘密を計算できます。カプセル化の前にITRがパケットを暗号化すると、暗号化の計算に使用されたキーがITRによって識別されるため、ETRは、カプセル化解除後にパケットの復号化に使用するキーを認識します。 LISPヘッダーでキーIDを使用することで、高速なキー再生成機能も利用できます。
The key management described in this document is unidirectional from the ITR (the encapsulator) to the ETR (the decapsultor).
このドキュメントで説明するキー管理は、ITR（カプセル化装置）からETR（デカプセル化装置）への一方向です。
LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and computation for computing a shared secret. The Diffie-Hellman parameters will be passed via Cipher Suite code-points in Map-Request and Map-Reply messages.
LISPはDiffie-Hellman [RFC2631]鍵交換シーケンスと計算を使用して、共有秘密を計算します。 Diffie-Hellmanパラメータは、Map-RequestおよびMap-ReplyメッセージのCipher Suiteコードポイントを介して渡されます。
Here is a brief description how Diffie-Hellman works:
Diffie-Hellmanの仕組みを簡単に説明します。
+----------------------------+---------+----------------------------+
| ITR | | ETR |
+------+--------+------------+---------+------------+---------------+
|Secret| Public | Calculates | Sends | Calculates | Public |Secret|
+------|--------|------------|---------|------------|--------|------+
| i | p,g | | p,g --> | | | e |
+------|--------|------------|---------|------------|--------|------+
| i | p,g,I |g^i mod p=I | I --> | | p,g,I | e |
+------|--------|------------|---------|------------|--------|------+
| i | p,g,I | | <-- E |g^e mod p=E | p,g | e |
+------|--------|------------|---------|------------|--------|------+
| i,s |p,g,I,E |E^i mod p=s | |I^e mod p=s |p,g,I,E | e,s |
+------|--------|------------|---------|------------|--------|------+
Public-Key Exchange for Computing a Shared Private Key [DH]
共有秘密キーを計算するための公開キー交換[DH]
Diffie-Hellman parameters 'p' and 'g' must be the same values used by the ITR and ETR. The ITR computes public key 'I' and transmits 'I' in a Map-Request packet. When the ETR receives the Map-Request, it uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The ETR transmits 'E' in a Map-Reply message. At this point, the ETR has enough information to compute 's', the shared secret, by using 'I' as the base and the ETR's private key 'e' as the exponent. When the ITR receives the Map-Reply, it uses the ETR's public key 'E' with the ITR's private key 'i' to compute the same 's' shared secret the ETR computed. The value 'p' is used as a modulus to create the width of the shared secret 's' (see Section 6).
Diffie-Hellmanパラメータ「p」および「g」は、ITRおよびETRで使用されるものと同じ値である必要があります。 ITRは公開鍵「I」を計算し、Map-Requestパケットで「I」を送信します。 ETRはMap-Requestを受信すると、パラメーター「p」と「g」を使用して、ETRの公開鍵「E」を計算します。 ETRはMap-Replyメッセージで「E」を送信します。この時点で、ETRには、「I」をベースとして、ETRの秘密鍵「e」を指数として使用することにより、共有秘密である「s」を計算するのに十分な情報があります。 ITRはMap-Replyを受信すると、ETRの公開鍵「E」とITRの秘密鍵「i」を使用して、ETRが計算した同じ「s」の共有秘密を計算します。値 'p'は、共有秘密 's'の幅を作成するための係数として使用されます（セクション6を参照）。
The Diffie-Hellman key material is transmitted in Map-Request and Map-Reply messages. Diffie-Hellman parameters are encoded in the LISP Security Key LCAF Type [RFC8060].
Diffie-Hellmanキーマテリアルは、Map-RequestおよびMap-Replyメッセージで送信されます。 Diffie-Hellmanパラメータは、LISPセキュリティキーLCAFタイプ[RFC8060]でエンコードされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Rsvd2 | 6 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Count | Rsvd3 | Cipher Suite | Rsvd4 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Length | Public Key Material ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Public Key Material |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Locator Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cipher Suite Field Contains DH Key Exchange and Cipher/Hash Functions
暗号スイートフィールドには、DHキー交換と暗号/ハッシュ関数が含まれています
The Key Count field encodes the number of {'Key-Length', 'Key-Material'} fields included in the encoded LCAF. The maximum number of keys that can be encoded is three, each identified by key-id 1, followed by key-id 2, and finally key-id 3.
Key Countフィールドは、エンコードされたLCAFに含まれる{'Key-Length'、 'Key-Material'}フィールドの数をエンコードします。エンコードできるキーの最大数は3で、それぞれキーID 1、キーID 2、最後にキーID 3で識別されます。
The R bit is not used for this use case of the Security Key LCAF Type but is reserved for [LISP-DDT] security. Therefore, the R bit SHOULD be transmitted as 0 and MUST be ignored on receipt.
Rビットは、セキュリティキーLCAFタイプのこの使用例では使用されませんが、[LISP-DDT]セキュリティ用に予約されています。したがって、Rビットは0として送信する必要があり（SHOULD）、受信時に無視する必要があります。
Cipher Suite 0: Reserved
暗号スイート0：予約済み
Cipher Suite 1 (LISP_2048MODP_AES128_CBC_SHA256):
Diffie-Hellman Group: 2048-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC]
Integrity: Integrated with AEAD_AES_128_CBC_HMAC_SHA_256 [AES-CBC]
IV length: 16 bytes
KDF: HMAC-SHA-256
Cipher Suite 2 (LISP_EC25519_AES128_CBC_SHA256):
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: AES with 128-bit keys in CBC mode [AES-CBC]
Integrity: Integrated with AEAD_AES_128_CBC_HMAC_SHA_256 [AES-CBC]
IV length: 16 bytes
KDF: HMAC-SHA-256
Cipher Suite 3 (LISP_2048MODP_AES128_GCM):
Diffie-Hellman Group: 2048-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in GCM mode [RFC5116]
Integrity: Integrated with AEAD_AES_128_GCM [RFC5116]
IV length: 12 bytes
KDF: HMAC-SHA-256
Cipher Suite 4 (LISP_3072MODP_AES128_GCM):
Diffie-Hellman Group: 3072-bit MODP [RFC3526]
Encryption: AES with 128-bit keys in GCM mode [RFC5116]
Integrity: Integrated with AEAD_AES_128_GCM [RFC5116]
IV length: 12 bytes
KDF: HMAC-SHA-256
Cipher Suite 5 (LISP_256_EC25519_AES128_GCM):
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: AES with 128-bit keys in GCM mode [RFC5116]
Integrity: Integrated with AEAD_AES_128_GCM [RFC5116]
IV length: 12 bytes
KDF: HMAC-SHA-256
Cipher Suite 6 (LISP_256_EC25519_CHACHA20_POLY1305):
Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539]
Integrity: Integrated with AEAD_CHACHA20_POLY1305 [CHACHA-POLY]
IV length: 8 bytes
KDF: HMAC-SHA-256
The Public Key Material field contains the public key generated by one of the Cipher Suites defined above. The length of the key, in octets, is encoded in the Key Length field.
Public Key Materialフィールドには、上記で定義された暗号スイートの1つによって生成された公開キーが含まれています。オクテット単位のキーの長さは、[キーの長さ]フィールドでエンコードされます。
When an ITR, PITR, or RTR sends a Map-Request, they will encode their own RLOC in the Security Key LCAF Type format within the ITR-RLOCs field. When an ETR or RTR sends a Map-Reply, they will encode their RLOCs in Security Key LCAF Type format within the RLOC-record field of each EID-record supplied.
ITR、PITR、またはRTRがMap-Requestを送信すると、独自のRLOCをITR-RLOCsフィールド内のセキュリティキーLCAFタイプ形式でエンコードします。 ETRまたはRTRがMap-Replyを送信すると、提供された各EIDレコードのRLOCレコードフィールド内で、RLOCをセキュリティキーLCAFタイプ形式でエンコードします。
If an ITR, PITR, or RTR sends a Map-Request with the Security Key LCAF Type included and the ETR or RTR does not want to have encapsulated traffic encrypted, they will return a Map-Reply with no RLOC-records encoded with the Security Key LCAF Type. This signals to the ITR, PITR, or RTR not to encrypt traffic (it cannot encrypt traffic anyway since no ETR public key was returned).
ITR、PITR、またはRTRがセキュリティキーLCAFタイプを含むMap-Requestを送信し、ETRまたはRTRがカプセル化されたトラフィックを暗号化したくない場合、セキュリティでエンコードされたRLOCレコードのないMap-Replyを返します。主要なLCAFタイプ。これは、トラフィックを暗号化しないようにITR、PITR、またはRTRに通知します（ETR公開鍵が返されなかったため、とにかくトラフィックを暗号化できません）。
Likewise, if an ITR or PITR wishes to include multiple key-ids in the Map-Request, but the ETR or RTR wishes to use some but not all of the key-ids, it returns a Map-Reply only for those key-ids it wishes to use.
同様に、ITRまたはPITRが複数のキーIDをMap-Requestに含めたいが、ETRまたはRTRはすべてではなく一部のキーIDを使用したい場合、それらのキーIDに対してのみMap-Replyを返します。使用したいです。
When an ITR or PITR receives a Map-Reply accepting the Cipher Suite sent in the Map-Request, it is ready to create data-plane keys. The same process is followed by the ETR or RTR returning the Map-Reply.
ITRまたはPITRがMap-Requestで送信された暗号スイートを受け入れるMap-Replyを受信すると、データプレーンキーを作成する準備が整います。同じプロセスの後に、ETRまたはRTRがMap-Replyを返します。
The first step is to create a shared secret, using the peer's shared Diffie-Hellman Public Key Material combined with the device's own private keying material, as described in Section 5. The Diffie-Hellman parameters used are defined in the Cipher Suite sent in the Map-Request and copied into the Map-Reply.
最初のステップは、セクション5で説明されているように、ピアの共有Diffie-Hellman公開鍵マテリアルをデバイス独自の秘密鍵マテリアルと組み合わせて使用して、共有秘密を作成することです。使用されるDiffie-Hellmanパラメータは、 Map-RequestとMap-Replyにコピーされます。
The resulting shared secret is used to compute an AEAD-key for the algorithms specified in the Cipher Suite. A Key Derivation Function (KDF) in counter mode, as specified by [NIST-SP800-108], is used to generate the data-plane keys. The amount of keying material that is derived depends on the algorithms in the Cipher Suite.
結果の共有秘密は、暗号スイートで指定されたアルゴリズムのAEADキーを計算するために使用されます。 [NIST-SP800-108]で指定されている、カウンターモードのキー派生関数（KDF）は、データプレーンキーの生成に使用されます。導出される鍵情報の量は、暗号スイートのアルゴリズムによって異なります。
The inputs to the KDF are as follows:
KDFへの入力は次のとおりです。
o KDF function. This is HMAC-SHA-256 in this document, but generally specified in each Cipher Suite definition.
o KDF関数。これは、このドキュメントではHMAC-SHA-256ですが、通常、各暗号スイートの定義で指定されています。
o A key for the KDF function. This is the computed Diffie-Hellman shared secret.
o KDF機能のキー。これは、計算されたDiffie-Hellman共有秘密です。
o Context that binds the use of the data-plane keys to this session. The context is made up of the following fields, which are concatenated and provided as the data to be acted upon by the KDF function. A Context is made up of the following components:
o データプレーンキーの使用をこのセッションにバインドするコンテキスト。コンテキストは次のフィールドで構成されます。これらのフィールドは連結され、KDF関数によって処理されるデータとして提供されます。コンテキストは、次のコンポーネントで構成されています。
* A counter, represented as a two-octet value in network byte order.
* ネットワークバイト順の2オクテット値として表されるカウンター。
* The null-terminated string "lisp-crypto".
* nullで終了する文字列「lisp-crypto」。
* The ITR's nonce from the Map-Request the Cipher Suite was included in.
* Map-Request the Cipher SuiteからのITRのナンスが含まれていました。
* The number of bits of keying material required (L), represented as a two-octet value in network byte order.
* 必要なキー情報のビット数（L）。ネットワークバイトオーダーの2オクテット値として表されます。
The counter value in the context is first set to 1. When the amount of keying material exceeds the number of bits returned by the KDF function, then the KDF function is called again with the same inputs except that the counter increments for each call. When enough keying material is returned, it is concatenated and used to create keys.
コンテキスト内のカウンター値は最初に1に設定されます。キーイングマテリアルの量がKDF関数によって返されるビット数を超えると、カウンターが各呼び出しでインクリメントすることを除いて、同じ入力でKDF関数が再度呼び出されます。十分なキー情報が返されると、それが連結されてキーの作成に使用されます。
For example, AES with 128-bit keys requires 16 octets (128 bits) of keying material, and HMAC-SHA1-96 requires another 16 octets (128 bits) of keying material in order to maintain a consistent 128 bits of security. Since 32 octets (256 bits) of keying material are required, and the KDF function HMAC-SHA-256 outputs 256 bits, only one call is required. The inputs are as follows:
たとえば、128ビットキーを使用するAESには、16オクテット（128ビット）のキー素材が必要です。HMAC-SHA1-96には、一貫した128ビットのセキュリティを維持するために、さらに16オクテット（128ビット）のキー素材が必要です。 32オクテット（256ビット）の鍵情報が必要であり、KDF関数HMAC-SHA-256は256ビットを出力するため、1回の呼び出しで済みます。入力は次のとおりです。
key-material = HMAC-SHA-256(dh-shared-secret, context)
キーマテリアル= HMAC-SHA-256（dh-shared-secret、context）
where: context = 0x0001 || "lisp-crypto" || <itr-nonce> || 0x0100
In contrast, a Cipher Suite specifying AES with 256-bit keys requires 32 octets (256 bits) of keying material, and HMAC-SHA256-128 requires another 32 octets (256 bits) of keying material in order to maintain a consistent 256 bits of security. Since 64 octets (512 bits) of keying material are required, and the KDF function HMAC-SHA-256 outputs 256 bits, two calls are required.
対照的に、256ビットキーでAESを指定する暗号スイートでは、32オクテット（256ビット）のキー素材が必要です。セキュリティ。 64オクテット（512ビット）のキー情報が必要であり、KDF関数HMAC-SHA-256は256ビットを出力するため、2つの呼び出しが必要です。
key-material-1 = HMAC-SHA-256(dh-shared-secret, context)
key-material-1 = HMAC-SHA-256（dh-shared-secret、context）
where: context = 0x0001 || "lisp-crypto" || <itr-nonce> || 0x0200
key-material-2 = HMAC-SHA-256(dh-shared-secret, context)
key-material-2 = HMAC-SHA-256（dh-shared-secret、context）
where: context = 0x0002 || "lisp-crypto" || <itr-nonce> || 0x0200
key-material = key-material-1 || key-material-2
key-material = key-material-1 ||キーマテリアル-2
If the key-material is longer than the required number of bits (L), then only the most significant L bits are used.
キーマテリアルが必要なビット数（L）より長い場合、最上位のLビットのみが使用されます。
From the derived key-material, the most significant 256 bits are used for the AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided into a 128-bit encryption key and a 128-bit integrity check key internal to the cipher used by the ITR.
派生したキーマテリアルから、最上位の256ビットがAEAD暗号によるAEADキーに使用されます。 256ビットのAEADキーは、128ビットの暗号化キーと、ITRが使用する暗号の内部にある128ビットの整合性チェックキーに分かれています。
The LISP encapsulation header [RFC6830] requires changes to encode the key-id for the key being used for encryption.
LISPカプセル化ヘッダー[RFC6830]では、暗号化に使用されているキーのキーIDをエンコードするための変更が必要です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L / |N|L|E|V|I|R|K|K| Nonce/Map-Version |\ \
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A
S \ | Instance ID/Locator-Status-Bits | |D
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |/
| Initialization Vector (IV) | I
E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C
n / | | V
c | | |
r | Packet Payload with EID Header ... | |
y | | |
p \ | |/
t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K-bits Indicate When a Packet Is Encrypted and Which Key Is Used
Kビットは、パケットがいつ暗号化され、どのキーが使用されるかを示します
When the KK bits are 00, the encapsulated packet is not encrypted. When the value of the KK bits is 1, 2, or 3, it encodes the key-id of the secret keys computed during the Diffie-Hellman Map-Request/Map-Reply exchange. When the KK bits are not 0, the payload is prepended with an Initialization Vector (IV). The length of the IV field is based on the Cipher Suite used. Since all Cipher Suites defined in this document do Authenticated Encryption with Associated Data (AEAD), an ICV field does not need to be present in the packet since it is included in the ciphertext. The Additional Data (AD) used for the ICV is shown above and includes the LISP header, the IV field, and the packet payload.
KKビットが00の場合、カプセル化されたパケットは暗号化されません。 KKビットの値が1、2、または3の場合、Diffie-Hellman Map-Request / Map-Reply交換中に計算された秘密鍵のkey-idをエンコードします。 KKビットが0でない場合、ペイロードの前に初期化ベクトル（IV）が付加されます。 IVフィールドの長さは、使用される暗号スイートに基づいています。このドキュメントで定義されているすべての暗号スイートは、関連データを使用した認証暗号化（AEAD）を行うため、ICVフィールドは暗号文に含まれているため、パケットに存在する必要はありません。 ICVに使用される追加データ（AD）は上に示され、LISPヘッダー、IVフィールド、およびパケットペイロードが含まれています。
When an ITR or PITR receives a packet to be encapsulated, the device will first decide what key to use, encode the key-id into the LISP header, and use that key to encrypt all packet data that follows the LISP header. Therefore, the outer header, UDP header, and LISP header travel as plaintext.
ITRまたはPITRがカプセル化するパケットを受信すると、デバイスはまず使用するキーを決定し、キーIDをLISPヘッダーにエンコードし、そのキーを使用してLISPヘッダーに続くすべてのパケットデータを暗号化します。したがって、外部ヘッダー、UDPヘッダー、およびLISPヘッダーはプレーンテキストとして移動します。
At the time of writing, there is an open working group item to discuss if the data encapsulation header needs change for encryption or any new applications. This document proposes changes to the existing header so experimentation can continue without making large changes to the data plane at this time. This document allocates two bits of the previously unused three flag bits (note the R-bit above is still a reserved flag bit, as documented in [RFC6830]) for the KK bits.
執筆時点では、暗号化または新しいアプリケーションのためにデータカプセル化ヘッダーを変更する必要があるかどうかを議論するためのオープンなワーキンググループ項目があります。このドキュメントでは、既存のヘッダーの変更を提案しているため、現時点でデータプレーンに大きな変更を加えることなく実験を続けることができます。このドキュメントは、KKビットに以前使用されていなかった3つのフラグビットの2ビットを割り当てます（[RC6830]で文書化されているように、上記のRビットはまだ予約済みフラグビットです）。
When an ITR, PITR, or RTR encapsulates a packet and has already computed an AEAD-key (detailed in Section 7) that is associated with a destination RLOC, the following encryption and encapsulation procedures are performed:
ITR、PITR、またはRTRがパケットをカプセル化し、宛先RLOCに関連付けられているAEADキー（セクション7で詳しく説明）をすでに計算している場合、次の暗号化およびカプセル化手順が実行されます。
1. The encapsulator creates an IV and prepends the IV value to the packet being encapsulated. For GCM and ChaCha20 Cipher Suites, the IV is incremented for every packet (beginning with a value of 1 in the first packet) and sent to the destination RLOC. For CBC Cipher Suites, the IV is a new random number for every packet sent to the destination RLOC. For the ChaCha20 Cipher Suite, the IV is an 8-byte random value that is appended to a 4-byte counter that is incremented for every packet (beginning with a value of 1 in the first packet).
1. カプセル化装置はIVを作成し、カプセル化されるパケットにIV値を付加します。 GCMおよびChaCha20暗号スイートの場合、IVはパケットごとに増分され（最初のパケットの値が1で始まる）、宛先RLOCに送信されます。 CBC暗号スイートの場合、IVは宛先RLOCに送信されるすべてのパケットの新しい乱数です。 ChaCha20暗号スイートの場合、IVは8バイトのランダムな値で、4バイトのカウンターに追加され、パケットごとに増分されます（最初のパケットの値が1から始まります）。
2. Next encrypt with cipher function AES or ChaCha20 using the AEAD-key over the packet payload following the AEAD specification referenced in the Cipher Suite definition. This does not include the IV. The IV must be transmitted as plaintext so the decrypter can use it as input to the decryption cipher. The payload should be padded to an integral number of bytes a block cipher may require. The result of the AEAD operation may contain an ICV, the size of which is defined by the referenced AEAD specification. Note that the AD (i.e., the LISP header exactly as will be prepended in the next step and the IV) must be given to the AEAD encryption function as the "associated data" argument.
2.次に、暗号スイート定義で参照されているAEAD仕様に従って、パケットペイロード上でAEADキーを使用して、暗号化機能AESまたはChaCha20で暗号化します。これにはIVは含まれません。 IVは平文として送信する必要があるため、復号化機能はIVを復号化暗号への入力として使用できます。ペイロードには、ブロック暗号が必要とする可能性のある整数バイト数までパディングする必要があります。 AEAD操作の結果にはICVが含まれる場合があり、そのサイズは参照されているAEAD仕様で定義されています。 AD（つまり、次のステップで追加されるLISPヘッダーとIV）は、「関連データ」引数としてAEAD暗号化関数に渡される必要があることに注意してください。
3. Prepend the LISP header. The key-id field of the LISP header is set to the key-id value that corresponds to key-pair used for the encryption cipher.
3. LISPヘッダーを付加します。 LISPヘッダーのkey-idフィールドは、暗号化暗号に使用されるキーペアに対応するkey-id値に設定されます。
4. Lastly, prepend the UDP header and outer IP header onto the encrypted packet and send packet to destination RLOC.
4. 最後に、UDPヘッダーと外部IPヘッダーを暗号化されたパケットに付加し、パケットを宛先RLOCに送信します。
When an ETR, PETR, or RTR receives an encapsulated packet, the following decapsulation and decryption procedures are performed:
ETR、PETR、またはRTRがカプセル化されたパケットを受信すると、次のカプセル化解除と復号化の手順が実行されます。
1. The outer IP header, UDP header, LISP header, and IV field are stripped from the start of the packet. The LISP header and IV are retained and given to the AEAD decryption operation as the "associated data" argument.
1. 外部IPヘッダー、UDPヘッダー、LISPヘッダー、およびIVフィールドは、パケットの先頭から削除されます。 LISPヘッダーとIVは保持され、「関連データ」引数としてAEAD復号化操作に渡されます。
2. The packet is decrypted using the AEAD-key and the IV from the packet. The AEAD-key is obtained from a local-cache associated with the key-id value from the LISP header. The result of the decryption function is a plaintext packet payload if the cipher returned a verified ICV. Otherwise, the packet is invalid and is discarded. If the AEAD specification included an ICV, the AEAD decryption function will locate the ICV in the ciphertext and compare it to a version of the ICV that the AEAD decryption function computes. If the computed ICV is different than the ICV located in the ciphertext, then it will be considered tampered.
2. パケットは、AEADキーとパケットからのIVを使用して復号化されます。 AEADキーは、LISPヘッダーのキーID値に関連付けられたローカルキャッシュから取得されます。暗号が検証済みのICVを返した場合、復号化関数の結果は平文パケットのペイロードになります。そうでない場合、パケットは無効であり、廃棄されます。 AEAD仕様にICVが含まれている場合、AEAD復号化関数はICVを暗号文で見つけ、それをAEAD復号化関数が計算するICVのバージョンと比較します。計算されたICVが暗号文にあるICVと異なる場合、改ざんされたと見なされます。
3. If the packet was not tampered with, the decrypted packet is forwarded to the destination EID.
3. パケットが改ざんされていない場合、復号化されたパケットは宛先EIDに転送されます。
Since multiple keys can be encoded in both control and data messages, an ITR can encapsulate and encrypt with a specific key while it is negotiating other keys with the same ETR. As soon as an ETR or RTR returns a Map-Reply, it should be prepared to decapsulate and decrypt using the new keys computed with the new Diffie-Hellman parameters received in the Map-Request and returned in the Map-Reply.
複数のキーは制御メッセージとデータメッセージの両方でエンコードできるため、ITRは同じETRで他のキーをネゴシエートしながら、特定のキーでカプセル化および暗号化できます。 ETRまたはRTRがMap-Replyを返すとすぐに、Map-Requestで受け取ってMap-Replyで返された新しいDiffie-Hellmanパラメータで計算された新しいキーを使用して、カプセル化を解除して復号化する準備をする必要があります。
RLOC-probing can be used to change keys or Cipher Suites by the ITR at any time. And when an initial Map-Request is sent to populate the ITR's map-cache, the Map-Request flows across the mapping system where a single ETR from the Map-Reply RLOC-set will respond. If the ITR decides to use the other RLOCs in the RLOC-set, it MUST send a Map-Request directly to negotiate security parameters with the ETR. This process may be used to test reachability from an ITR to an ETR initially when a map-cache entry is added for the first time, so an ITR can get both reachability status and keys negotiated with one Map-Request/Map-Reply exchange.
RLOCプローブは、ITRによっていつでもキーまたは暗号スイートを変更するために使用できます。そして、最初のMap-Requestが送信されてITRのマップキャッシュに入力されると、Map-Requestはマッピングシステム全体に流れ、そこでMap-Reply RLOCセットからの単一のETRが応答します。 ITRがRLOCセット内の他のRLOCを使用することを決定した場合、ITRとセキュリティパラメーターをネゴシエートするために、Map-Requestを直接送信する必要があります。このプロセスは、マップキャッシュエントリが初めて追加されたときに、最初にITRからETRへの到達可能性をテストするために使用できます。そのため、ITRは到達可能性ステータスと1つのMap-Request / Map-Reply交換でネゴシエートされたキーの両方を取得できます。
A rekeying event is defined to be when an ITR or PITR changes the Cipher Suite or public key in the Map-Request. The ETR or RTR compares the Cipher Suite and public key it last received from the ITR for the key-id, and if any value has changed, it computes a new public key and Cipher Suite requested by the ITR from the Map-Request and returns it in the Map-Reply. Now a new shared secret is computed and can be used for the key-id for encryption by the ITR and decryption by the ETR. When the ITR or PITR starts this process of negotiating a new key, it must not use the corresponding key-id in encapsulated packets until it receives a Map-Reply from the ETR with the same Cipher Suite value it expects (the values it sent in a Map-Request).
鍵再生成イベントは、ITRまたはPITRがMap-Requestの暗号スイートまたは公開鍵を変更するときに定義されます。 ETRまたはRTRは、ITRから最後に受信した暗号スイートと公開鍵を比較してkey-idを取得し、値が変更されている場合は、Map-RequestからITRによって要求された新しい公開鍵と暗号スイートを計算して返します。 Map-Replyにあります。これで、新しい共有シークレットが計算され、ITRによる暗号化とETRによる復号化のキーIDとして使用できます。 ITRまたはPITRが新しいキーをネゴシエートするこのプロセスを開始するとき、予期するものと同じ暗号スイート値（送信した値）を使用してETRからMap-Replyを受信するまで、カプセル化されたパケット内の対応するキーIDを使用しないでください。 Map-Request）。
Note when RLOC-probing continues to maintain RLOC reachability and rekeying is not desirable, the ITR or RTR can either not include the Security Key LCAF Type in the Map-Request or supply the same key material as it received from the last Map-Reply from the ETR or RTR. This approach signals to the ETR or RTR that no rekeying event is requested.
RLOCプローブがRLOCの到達可能性を維持し続け、鍵の再生成が望ましくない場合、ITRまたはRTRがMap-RequestにセキュリティキーLCAFタイプを含めないか、前回のMap-Replyから受け取ったものと同じキーマテリアルを提供できないことに注意してください。 ETRまたはRTR。このアプローチは、鍵再生成イベントが要求されていないことをETRまたはRTRに通知します。
For performance considerations, newer Elliptic-Curve Diffie-Hellman (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to reduce CPU cycles required to compute shared secret keys.
パフォーマンスを考慮して、[RFC4492]と[RFC6090]で指定されているように、新しいElliptic-Curve Diffie-Hellman（ECDH）グループを使用して、共有秘密鍵の計算に必要なCPUサイクルを削減できます。
For better security considerations as well as to be able to build faster software implementations, newer approaches to ciphers and authentication methods will be researched and tested. Some examples are ChaCha20 and Poly1305 [CHACHA-POLY] [RFC7539].
より良いセキュリティを考慮し、より高速なソフトウェア実装を構築できるようにするために、暗号と認証方法への新しいアプローチが研究され、テストされます。いくつかの例は、ChaCha20とPoly1305 [CHACHA-POLY] [RFC7539]です。
The LISP working group received security advice and guidance from the Security Area Advisory Group (SAAG). The SAAG has been involved early in the design process, and their input and reviews have been included in this document.
LISPワーキンググループは、セキュリティエリアアドバイザリーグループ（SAAG）からセキュリティのアドバイスとガイダンスを受けました。 SAAGは設計プロセスの早い段階で関与しており、その入力とレビューはこのドキュメントに含まれています。
Comments from the SAAG included:
SAAGからのコメント：
1. Do not use asymmetric ciphers in the data plane.
1. データプレーンでは非対称暗号を使用しないでください。
2. Consider adding ECDH early in the design.
2. 設計の早い段階でECDHを追加することを検討してください。
3. Add Cipher Suites because ciphers are created more frequently than protocols that use them.
3. 暗号は、暗号を使用するプロトコルよりも頻繁に作成されるため、暗号スイートを追加します。
4. Consider the newer AEAD technology so authentication comes with doing encryption.
4. 新しいAEADテクノロジを検討して、暗号化を行うときに認証が行われるようにします。
Since ITRs and ETRs participate in key exchange over a public non-secure network, a man in the middle (MITM) could circumvent the key exchange and compromise data-plane confidentiality. This can happen when the MITM is acting as a Map-Replier and provides its own public key so the ITR and the MITM generate a shared secret key between them. If the MITM is in the data path between the ITR and ETR, it can use the shared secret key to decrypt traffic from the ITR.
ITRとETRは、非セキュアなパブリックネットワークを介したキー交換に参加するため、中間者（MITM）がキー交換を回避し、データプレーンの機密性を危険にさらす可能性があります。これは、MITMがMap-Replierとして機能していて、ITRとMITMがそれらの間に共有秘密鍵を生成するように独自の公開鍵を提供している場合に発生する可能性があります。 MITMがITRとETR間のデータパスにある場合、MITMは共有秘密鍵を使用してITRからのトラフィックを復号化できます。
Since LISP can secure Map-Replies by the authentication process specified in [LISP-SEC], the ITR can detect when a MITM has signed a Map-Reply for an EID-prefix for which it is not authoritative. When an ITR determines that the signature verification fails, it discards and does not reuse the key exchange parameters, avoids using the ETR for encapsulation, and issues a severe log message to the network administrator. Optionally, the ITR can send RLOC-probes to the compromised RLOC to determine if the authoritative ETR is reachable. And when the ITR validates the signature of a Map-Reply, it can begin encrypting and encapsulating packets to the RLOC of ETR.
LISPは[LISP-SEC]で指定された認証プロセスによってMap-Repliesを保護できるため、ITRは、MITMが権限のないEIDプレフィックスのMap-Replyに署名したことを検出できます。 ITRは、署名検証が失敗したと判断すると、破棄して鍵交換パラメーターを再利用せず、カプセル化にETRを使用しないようにし、ネットワーク管理者に重大なログメッセージを発行します。オプションで、ITRはRLOCプローブを侵害されたRLOCに送信して、信頼できるETRに到達できるかどうかを判断できます。また、ITRがMap-Replyの署名を検証すると、ETRのRLOCへのパケットの暗号化とカプセル化を開始できます。
This document describes a mechanism for encrypting LISP-encapsulated packets based on Diffie-Hellman key exchange procedures. During the exchange, the devices have to agree on a Cipher Suite to be used (i.e., the cipher and hash functions used to encrypt/decrypt and to sign/verify packets). The 8-bit Cipher Suite field is reserved for such purpose in the security material section of the Map-Request and Map-Reply messages.
このドキュメントでは、Diffie-Hellmanキー交換手順に基づいてLISPカプセル化パケットを暗号化するメカニズムについて説明します。交換中、デバイスは、使用される暗号スイート（つまり、パケットの暗号化/復号化と署名/検証に使用される暗号およびハッシュ関数）に同意する必要があります。 8ビットの暗号スイートフィールドは、Map-RequestおよびMap-Replyメッセージのセキュリティマテリアルセクションでそのような目的のために予約されています。
IANA has created a new registry (as outlined in [RFC5226]) titled "LISP Crypto Cipher Suite". Initial values for the registry are provided below. Future assignments are to be made on a "First Come, First Served" basis [RFC5226].
IANAは（[RFC5226]で説明されているように）「LISP Crypto Cipher Suite」というタイトルの新しいレジストリを作成しました。レジストリの初期値を以下に示します。将来の割り当ては、「先着順」ベースで行われます[RFC5226]。
+-----+--------------------------------------------+------------+
|Value| Suite | Reference |
+-----+--------------------------------------------+------------+
| 0 | Reserved | Section 6 |
+-----+--------------------------------------------+------------+
| 1 | LISP_2048MODP_AES128_CBC_SHA256 | Section 6 |
+-----+--------------------------------------------+------------+
| 2 | LISP_EC25519_AES128_CBC_SHA256 | Section 6 |
+-----+--------------------------------------------+------------+
| 3 | LISP_2048MODP_AES128_GCM | Section 6 |
+-----+--------------------------------------------+------------+
| 4 | LISP_3072MODP_AES128_GCM | Section 6 |
+-----+--------------------------------------------+------------+
| 5 | LISP_256_EC25519_AES128_GCM | Section 6 |
+-----+--------------------------------------------+------------+
| 6 | LISP_256_EC25519_CHACHA20_POLY1305 | Section 6 |
+-----+--------------------------------------------+------------+
LISP Crypto Cipher Suites
LISP暗号暗号スイート
[NIST-SP800-108] National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication SP 800-108, DOI 10.6028/NIST.SP.800-108, October 2009.
[NIST-SP800-108]国立標準技術研究所、「疑似ランダム関数を使用した鍵導出の推奨」、NIST特別刊行物SP 800-108、DOI 10.6028 / NIST.SP.800-108、2009年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, <http://www.rfc-editor.org/info/rfc2631>.
[RFC2631] Rescorla、E。、「Diffie-Hellman Key Agreement Method」、RFC 2631、DOI 10.17487 / RFC2631、1999年6月、<http://www.rfc-editor.org/info/rfc2631>。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, <http://www.rfc-editor.org/info/rfc3526>.
[RFC3526] Kivinen、T。、およびM. Kojo、「インターネット鍵交換（IKE）用のModular Exponential（MODP）Diffie-Hellmanグループ」、RFC 3526、DOI 10.17487 / RFC3526、2003年5月、<http：// www。 rfc-editor.org/info/rfc3526>。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.
[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 4492 、DOI 10.17487 / RFC4492、2006年5月、<http://www.rfc-editor.org/info/rfc4492>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<http://www.rfc-editor.org/info/rfc5116>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、DOI 10.17487 / RFC6090、2011年2月、<http://www.rfc-editor.org/ info / rfc6090>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「The Locator / ID Separation Protocol（LISP）」、RFC 6830、DOI 10.17487 / RFC6830、2013年1月、<http：/ /www.rfc-editor.org/info/rfc6830>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, <http://www.rfc-editor.org/info/rfc7539>.
[RFC7539] Nir、Y。およびA. Langley、「IETFプロトコル用のChaCha20およびPoly1305」、RFC 7539、DOI 10.17487 / RFC7539、2015年5月、<http://www.rfc-editor.org/info/rfc7539>。
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, <http://www.rfc-editor.org/info/rfc8060>.
[RFC8060] Farinacci、D.、Meyer、D。、およびJ. Snijders、「LISP Canonical Address Format（LCAF）」、RFC 8060、DOI 10.17487 / RFC8060、2017年2月、<http：//www.rfc-editor。 org / info / rfc8060>。
[AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated Encryption with AES-CBC and HMAC-SHA", Work in Progress, draft-mcgrew-aead-aes-cbc-hmac-sha2-05, July 2014.
[AES-CBC] McGrew、D.、Foley、J。、およびK. Paterson、「AES-CBCおよびHMAC-SHAによる認証済み暗号化」、作業中、draft-mcgrew-aead-aes-cbc-hmac-sha2 -05、2014年7月。
[CHACHA-POLY] Langley, A. and W. Chang, "ChaCha20 and Poly1305 based Cipher Suites for TLS", Work in Progress, draft-agl-tls-chacha20poly1305-04, November 2013.
[CHACHA-POLY] Langley、A。およびW. Chang、「ChaCha20およびPoly1305ベースのTLS用暗号スイート」、作業中、draft-agl-tls-chacha20poly1305-04、2013年11月。
[CURVE25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed records", DOI 10.1007/11745853_14, <http://www.iacr.org/cryptodb/archive/2006/ PKC/3351/3351.pdf>.
[CURVE25519] Bernstein、D。、「Curve25519：new Diffie-Hellman speed records」、DOI 10.1007 / 11745853_14、<http://www.iacr.org/cryptodb/archive/2006/ PKC / 3351 / 3351.pdf>。
[DH] Wikipedia, "Diffie-Hellman key exchange", January 2017, <https://en.wikipedia.org/w/index.php?title=Diffie%E2%80%9 3Hellman_key_exchange&oldid=759611604>.
[DH]ウィキペディア、「Diffie-Hellman鍵交換」、2017年1月、<https://en.wikipedia.org/w/index.php?title=Diffie%E2%80%9 3Hellman_key_exchange＆oldid = 759611604>。
[LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", Work in Progress, draft-ietf-lisp-ddt-08, September 2016.
[LISP-DDT] Fuller、V.、Lewis、D.、Ermagan、V.、Jain、A。、およびA. Smirnov、「LISP Delegated Database Tree」、作業中、draft-ietf-lisp-ddt-08 、2016年9月。
[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-12, November 2016.
[LISP-SEC] Maino、F.、Ermagan、V.、Cabellos、A。、およびD. Saucez、「LISP-Security（LISP-SEC）」、Work in Progress、draft-ietf-lisp-sec-12、 2016年11月。
Acknowledgments
謝辞
The authors would like to thank Dan Harkins, Joel Halpern, Fabio Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest, suggestions, and discussions about LISP data-plane security. An individual thank you to LISP WG Chair Luigi Iannone for shepherding this document as well as contributing to the IANA Considerations section.
著者は、LISPデータプレーンセキュリティに関する関心、提案、および議論について、Dan Harkins、Joel Halpern、Fabio Maino、Ed Lopez、Roger Jorgensen、およびWatson Laddに感謝します。このドキュメントを提出し、IANAの考慮事項のセクションに貢献してくれたLISP WG議長のLuigi Iannoneに感謝します。
The authors would like to give a special thank you to Ilari Liusvaara for his extensive commentary and discussion. He has contributed his security expertise to make lisp-crypto as secure as the state of the art in cryptography.
作者は、Ilari Liusvaara氏の広範な解説と議論に感謝します。彼はセキュリティの専門知識を提供して、lisp-cryptoを最先端の暗号技術と同じくらい安全にしました。
In addition, the support and suggestions from the SAAG working group were helpful and appreciated.
さらに、SAAGワーキンググループからのサポートと提案は役に立ち、高く評価されました。
Authors' Addresses
著者のアドレス
Dino Farinacci lispers.net San Jose, California 95120 United States of America
Dino Farinacci lispers.netサンノゼ、カリフォルニア95120アメリカ合衆国
Phone: 408-718-2001 Email: farinacci@gmail.com
電話：408-718-2001メール：farinacci@gmail.com
Brian Weis Cisco Systems 170 West Tasman Drive San Jose, California 95124-1706 United States of America
Brian Weis Cisco Systems 170 West Tasman Drive San Jose、California 95124-1706 United States of America
Phone: 408-526-4796 Email: bew@cisco.com
電話：408-526-4796メール：bew@cisco.com