[要約] RFC 5327は、Licklider Transmission Protocol（LTP）のセキュリティ拡張に関するものであり、LTPのセキュリティを向上させるための仕様を提供しています。このRFCの目的は、LTPのセキュリティを強化し、信頼性の高いデータ転送を実現することです。
Network Working Group S. Farrell
Request for Comments: 5327 Trinity College Dublin
Category: Experimental M. Ramadas
ISTRAC, ISRO
S. Burleigh
NASA/Jet Propulsion Laboratory
September 2008
Licklider Transmission Protocol - Security Extensions
Licklider送信プロトコル - セキュリティ拡張機能
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). It may be considered for standardization by the IETF in the future, but the IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. See RFC 3932 for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。これは、インターネット研究タスクフォース（IRTF）の遅延耐性ネットワーキング（DTN）研究グループのコンセンサスを表しています。将来のIETFによる標準化が検討される場合がありますが、IETFは、このRFCのフィットネスに関する知識をあらゆる目的で否認します。特に、公開する決定はセキュリティ、混雑などのIETFレビューに基づいていないことに注意してください。展開されたプロトコルとの制御、または不適切な相互作用。詳細については、RFC 3932を参照してください。
Abstract
概要
The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.
Licklider Transmission Protocol（LTP）は、シングルホップディープスペース無線周波数（RF）リンクを介した信頼できる収束層として機能することを目的としています。LTPは、Selective-cnowledmentの受信レポートを勧誘することにより、データ送信の自動リピートリクエスト（ARQ）を実行します。それはステートフルであり、交渉や握手はありません。このドキュメントは、LTPへのセキュリティ拡張機能について説明し、LTPを説明する一連の関連ドキュメントの一部です。
This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
このドキュメントは、遅延耐性ネットワーキング研究グループの製品であり、そのグループによってレビューされています。RFCとしての出版に対する異議は提起されませんでした。
Table of Contents
目次
1. Introduction ....................................................2
2. Security Extensions .............................................2
2.1. LTP Authentication .........................................3
2.2. A Cookie Mechanism .........................................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................7
5. Acknowledgments .................................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
This document describes extensions to the base LTP protocol [LTPSPEC]. The background to LTP is described in the "motivation" document [LTPMOTIVE]. All the extensions defined in this document provide additional security features for LTP.
このドキュメントでは、ベースLTPプロトコル[LTPSPEC]への拡張機能について説明します。LTPの背景については、「動機付け」ドキュメント[LTPMotive]で説明されています。このドキュメントで定義されているすべての拡張機能は、LTPの追加のセキュリティ機能を提供します。
LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but has applications in other environments as well.
LTPは、非常に長いメッセージラウンドトリップ時間（RTT）および/または接続の頻繁な中断を特徴とするリンクを介した再送信ベースの信頼性を提供するように設計されています。惑星間空間を横断する通信はこの種の環境の最も顕著な例であるため、LTPは主に惑星間空間での「長距離」信頼できる送信をサポートすることを目的としていますが、他の環境にも用途があります。
This document describes security extensions to LTP, and is part of a series of related documents describing LTP. Other documents in this series cover the motivation for LTP and the main protocol specification. We recommend reading all the documents in the series before writing code based on this document.
このドキュメントは、LTPへのセキュリティ拡張機能について説明し、LTPを説明する一連の関連ドキュメントの一部です。このシリーズの他のドキュメントは、LTPの動機とメインプロトコル仕様をカバーしています。このドキュメントに基づいてコードを書く前に、シリーズのすべてのドキュメントを読むことをお勧めします。
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 [B97].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[b97]で説明されているように解釈される。
The syntactical layout of the extensions are defined in Section 3.1.4 of the base protocol specification [LTPSPEC].
拡張機能の構文レイアウトは、ベースプロトコル仕様[LTPSPEC]のセクション3.1.4で定義されています。
Implementers should note that the LTP extension mechanism allows for multiple occurrences of any extension tag, in both (or either) the header or trailer. For example, the LTP authentication mechanism defined below requires both header and trailer extensions, which both use the same tag.
実装者は、LTP拡張メカニズムにより、ヘッダーまたはトレーラーの両方（またはどちらか）で任意の拡張タグの複数の発生を可能にすることに注意する必要があります。たとえば、以下に定義されているLTP認証メカニズムには、ヘッダーとトレーラーの両方の拡張機能が必要であり、どちらも同じタグを使用します。
This document defines new security extensions for LTP but does not address key management since key management in Delay-Tolerant Networking (DTN) remains an open research question.
このドキュメントは、LTPの新しいセキュリティ拡張機能を定義しますが、遅延耐性ネットワーキング（DTN）の主要な管理が未解決の研究の質問であるため、主要な管理に対処しません。
If LTP were deployed layered on top of UDP, it might be possible to use IPsec or other existing security mechanisms. However, in general DTN, IPsec's key exchange (IKE) cannot work (e.g., where link delays are measured in minutes).
LTPがUDPの上に層状に展開された場合、IPSECまたは他の既存のセキュリティメカニズムを使用することが可能かもしれません。ただし、一般にDTNでは、IPSECのキーエクスチェンジ（IKE）は機能しません（たとえば、リンクの遅延が議事録で測定されます）。
The LTP authentication mechanism provides cryptographic authentication of the segment.
LTP認証メカニズムは、セグメントの暗号化認証を提供します。
Implementations MAY support this extension field. If they do not support this header, then they MUST ignore it.
実装はこの拡張フィールドをサポートする場合があります。彼らがこのヘッダーをサポートしていない場合、彼らはそれを無視する必要があります。
The LTP authentication extension field has the extension tag value 0x00.
LTP認証拡張フィールドには、拡張タグ値0x00があります。
LTP authentication requires three new fields, the first two of which are carried as the value of the Extensions field of the LTP segment header, and the third of which is carried in the segment trailer.
LTP認証には3つの新しいフィールドが必要です。最初の2つは、LTPセグメントヘッダーの拡張フィールドの値として運ばれ、その3番目はセグメントトレーラーに運ばれます。
The fields that are carried in the header extensions field are catenated together to form the extension value (with the leftmost octet representing the ciphersuite and the remaining octets the KeyID). The KeyID field is optional, and is determined to be absent if the extension value consists of a single octet.
ヘッダーエクステンションフィールドに携帯されるフィールドは、拡張値を形成するために互いに誘導されます（左端のオクテットがciphersuiteを表し、残りのオクテットはkeyidを表します）。KeyIDフィールドはオプションであり、拡張値が単一のオクテットで構成されている場合、存在しないと判断されます。
Ciphersuite: an 8-bit integer value with values defined below.
Ciphersuite：以下に定義された値を持つ8ビット整数値。
KeyID: An optional key identifier, the interpretation of which is out of scope for this specification (that is, implementers MUST treat these KeyID fields as raw octets, even if they contained an ASN.1 DER encoding of an X.509 IssuerSerial construct [PKIXPROF], for example).
keyID：オプションのキー識別子であり、その解釈はこの仕様の範囲外です（つまり、実装者は、x.509発行担当コンストラクトのasn.1 derエンコーディングが含まれていたとしても、これらのkeyidフィールドを生のオクテットとして扱う必要があります[たとえば、pkixprof]。
The LTP-auth header extension MUST be present in the first segment from any LTP session that uses LTP authentication, but MAY be omitted from subsequent segments in that session. To guard against additional problems arising from lost segments, implementations SHOULD, where bandwidth allows, include these fields in a number of segments in the LTP session. If the first segment (or any part thereof) is retransmitted, then the LTP-auth header extension MUST be included in the retransmission.
LTP-Authヘッダー拡張機能は、LTP認証を使用するLTPセッションの最初のセグメントに存在する必要がありますが、そのセッションの後続のセグメントから省略される場合があります。失われたセグメントから生じる追加の問題を防ぐために、実装は、帯域幅が許可する場合、LTPセッションの多くのセグメントにこれらのフィールドを含める必要があります。最初のセグメント（またはその一部）が再送信された場合、LTP-Authヘッダー拡張機能を再送信に含める必要があります。
The field carried as a trailer extension is the AuthVal field. It contains the authentication value, which is either a message authentication code (MAC) or a digital signature. This is itself a structured field whose length and formatting depend on the ciphersuite.
トレーラー拡張機能として運ばれるフィールドは、AuthValフィールドです。メッセージ認証コード（MAC）またはデジタル署名のいずれかである認証値が含まれています。これ自体は、長さとフォーマットがciphersuiteに依存する構造化されたフィールドです。
If for some reason the sender includes two instances of LTP-auth headers, then there is a potential problem for the receiver in that presumably at least one of the AuthVal fields will not verify. There are very few situations where it would make sense to include more than one LTP-auth extension in a single segment, since LTP is a peer-to-peer protocol. If however, keys are being upgraded, then the sender might protect the segment with both the new and old keys. In such cases, the receiver MUST search and can consider the LTP authentication valid so long as one AuthVal is correct.
何らかの理由で、送信者にLTP-Authヘッダーの2つのインスタンスが含まれている場合、おそらくAuthalフィールドの少なくとも1つが確認されないという点で、受信機に潜在的な問題があります。LTPはピアツーピアプロトコルであるため、1つのセグメントに複数のLTP-Auth拡張機能を含めることが理にかなっている状況はほとんどありません。ただし、キーがアップグレードされている場合、送信者は新しいキーと古いキーの両方でセグメントを保護する場合があります。そのような場合、受信者は検索する必要があり、1つのauthvalが正しい限り、LTP認証の有効を検討できます。
For all ciphersuites, the input to the calculation is the entire encoded segment including the AuthVal extension tag and length, but not of course, including the AuthVal value.
すべてのciphersuitesの場合、計算への入力は、authval拡張タグと長さを含むエンコードされたセグメント全体ですが、もちろんauthval値を含むものではありません。
We define three ciphersuites in this specification. Our approach is to follow the precedent set by TLS [TLS], and to "hardcode" all algorithm options in a single ciphersuite number. This means that there are 256 potential ciphersuites supported by this version of LTP-auth. Since this is a limited space, IANA has established a registry for LTP Ciphersuites as described in the IANA Considerations section below. Current ciphersuite assignments are:
この仕様で3つのciphersuitesを定義します。私たちのアプローチは、TLS [TLS]によって設定された先例に従い、すべてのアルゴリズムオプションを単一のCiphersuite番号に「ハードコード」することです。これは、LTP-Authのこのバージョンでサポートされている256個の潜在的なシファースーツがあることを意味します。これは限られたスペースであるため、IANAは以下のIANA考慮事項セクションで説明されているように、LTP Ciphersuitesのレジストリを確立しました。現在のciphersuiteの割り当ては次のとおりです。
Ciphersuite Value
----------- -----
HMAC-SHA1-80 0
RSA-SHA256 1
Unassigned 2-127
Reserved 128-191
Private/Experimental Use 192-254
NULL 255
1. HMAC-SHA1-80 Ciphersuite
1. HMAC-SHA1-80 CIPHERSUITE
The HMAC-SHA1-80 ciphersuite involves generating a MAC over the LTP segment and appending the resulting AuthVal field to the end of the segment. There is only one MACing algorithm defined for this, which is HMAC-SHA1-80 [HMAC]. The AuthVal field in this case contains just the output of the HMAC-SHA1-80 algorithm, which is a fixed-width field (10 octets).
HMAC-Sha1-80 Ciphersuiteには、LTPセグメントでMACを生成し、結果のAuthValフィールドをセグメントの最後まで追加することが含まれます。これに定義されたマッピングアルゴリズムは1つだけです。これはHMAC-SHA1-80 [HMAC]です。この場合のAuthValフィールドには、固定幅のフィールド（10オクテット）であるHMAC-Sha1-80アルゴリズムの出力のみが含まれています。
2. RSA-SHA256 Ciphersuite
2. RSA-Sha256 Ciphersuite
The RSA-SHA256 ciphersuite involves generating a digital signature of the LTP segment and appending the resulting AuthVal field to the end of the segment. There is only one signature algorithm currently defined for this, which is RSA with SHA256 as defined in [RSA], Section 8.2. The AuthVal field in this case is simply the signature value, where the signature value occupies the minimum number of octets, e.g., 128 octets for a 1024-bit signature).
RSA-Sha256 Ciphersuiteには、LTPセグメントのデジタル署名を生成し、結果のAuthValフィールドをセグメントの最後まで追加することが含まれます。現在定義されている署名アルゴリズムは1つだけです。これは、[RSA]、セクション8.2で定義されているSHA256を持つRSAです。この場合のAuthValフィールドは、単に署名値であり、署名値は1024ビットの署名の場合、たとえば128オクテットの最小オクテット数を占有します。
3. NULL Ciphersuite
3. null ciphersuite
The NULL ciphersuite is basically the same as the HMAC-SHA1-80 ciphersuite, but with a hardcoded key. This ciphersuite effectively provides only a strong checksum without authentication, and thus is subject to active attacks and is the equivalent of providing a Cyclic Redundancy Check (CRC).
null ciphersuiteは、基本的にHMAC-SHA1-80 Ciphersuiteと同じですが、ハードコーディングされたキーがあります。このciphersuiteは、認証なしで強力なチェックサムのみを効果的に提供するため、アクティブな攻撃の対象となり、循環冗長チェック（CRC）を提供することに相当します。
The hardcoded key to be used with this ciphersuite is the following:
このciphersuiteで使用されるハードコーディングキーは次のとおりです。
HMAC_KEY : c37b7e64 92584340 : bed12207 80894115 : 5068f738 (The above is the test vector from RFC 3537 [WRAP].)
hmac_key：c37b7e64 92584340：bed12207 80894115：5068f738（上記はRFC 3537 [wrap]のテストベクトルです。）
In each case, the bytes that are input to the cryptographic algorithm consist of the entire LTP segment except the AuthVal. In particular, the header extensions field that may contain the ciphersuite number and the KeyID field is part of the input.
いずれの場合も、暗号化アルゴリズムに入力されるバイトは、AUTHVALを除くLTPセグメント全体で構成されています。特に、Ciphersuite番号を含む可能性のあるヘッダー拡張フィールドとKeyIDフィールドは、入力の一部です。
The output bytes of the cryptographic operation are the payload of the AuthVal field.
暗号化操作の出力バイトは、AuthValフィールドのペイロードです。
The following shows an example LTP-auth header, starting from and including the Extensions field.
以下は、Extensionsフィールドから開始して、LTP-Authヘッダーの例を示しています。
ext tag sdnv c-s k-id
+----+----+----+----+----+
|0x11|0x00|0x02|0x00|0x24|
+----+----+----+----+----+
The Extensions field has the value 0x11 with the most significant and least significant nibble value 1, indicating the presence of one header and one trailer extension, respectively. The next octet is the extension tag (0x00 for LTP-auth), followed by the Self-Delimiting Numeric Value (SDNV) encoded length of the ensuing data: a one-octet ciphersuite (0x00 meaning HMAC-SHA1-80) and the KeyID (in this case with a short value of 0x24). The trailer extension (not shown above) should contain the AuthVal.
拡張フィールドのフィールドには、最も重要で最も有意なナブル値1を持つ値0x11があり、それぞれ1つのヘッダーと1つのトレーラー拡張機能の存在を示します。次のオクテットは、拡張タグ（LTP-Authの0x00）であり、その後、次のデータの自己導発数値（SDNV）エンコードされた長さが続きます。（この場合、0x24の短い値があります）。トレーラーの拡張機能（上記には示されていません）には、authvalを含める必要があります。
The use of cookies is a well-known way to make Denial of Service (DoS) attacks harder to mount. We define the cookie extension for use in environments where an LTP implementation is liable to such attacks.
Cookieの使用は、サービスの拒否（DOS）攻撃を取り付けるのが難しくなるというよく知られている方法です。LTP実装がそのような攻撃に対して責任を負う環境で使用するためのCookie拡張機能を定義します。
The cookie is placed in a header extension field, and has no related trailer extension field. It has the extension tag value 0x01.
Cookieはヘッダー拡張フィールドに配置されており、関連するトレーラー拡張フィールドはありません。拡張タグ値0x01があります。
The cookie value can essentially be viewed as a sufficiently long random number, where the length can be determined by the implementation (longer cookies are harder to guess and therefore better, though using more bandwidth). Note that cookie values can be derived using lots of different schemes so long as they produce random-looking and hard-to-predict values.
Cookie値は基本的に十分に長い乱数と見なすことができます。ここでは、実装によって長さを決定できます（より多くの帯域幅を使用しても、より長いCookieは推測が困難であるため、より良いものです）。Cookie値は、ランダムに見える予測が難しい値を生成する限り、多くの異なるスキームを使用して導出できることに注意してください。
The first cookie inserted into a segment for this session is called the initial cookie.
このセッションのセグメントに挿入された最初のCookieは、最初のCookieと呼ばれます。
Note that cookies do not outlast an LTP session.
CookieはLTPセッションを長持ちしないことに注意してください。
The basic mode of operation is that an LTP engine can include a cookie in a segment at any time. After that time, all segments corresponding to that LTP session MUST contain a good cookie value -- that is, all segments both to and from the engine MUST contain a good cookie. Clearly, there will be some delay before the cookie is seen in incoming segments -- implementations MUST determine an acceptable delay for these cases, and MUST only accept segments without a cookie until that time.
操作の基本モードは、LTPエンジンにいつでもセグメントにCookieを含めることができることです。その後、そのLTPセッションに対応するすべてのセグメントには、優れたCookie値を含める必要があります。つまり、エンジンとの両方のセグメントには、優れたCookieが含まれている必要があります。明らかに、Cookieが着信セグメントに見られる前にある程度の遅延があります。実装は、これらのケースの許容可能な遅延を決定する必要があり、その時までCookieのないセグメントのみを受け入れる必要があります。
The cookie value can be extended at any time by catenating more random bits. This allows both LTP engines to contribute to the randomness of the cookie, where that is useful. It also allows a node that considers the cookie value too short (say due to changing circumstances) to add additional security. In this case, the extended cookie value becomes the "to-be-checked-against" cookie value for all future segments (modulo the communications delay as above).
Cookie値は、より多くのランダムなビットを覆うことにより、いつでも拡張できます。これにより、両方のLTPエンジンがCookieのランダム性に寄与することができます。また、Cookieの値が短すぎる（状況が変化したため）と考えるノードが追加のセキュリティを追加することもできます。この場合、拡張されたCookie値は、すべての将来のセグメント（上記のように通信遅延）の「確認された」Cookie値になります。
It can happen that both sides emit segments containing an initial cookie before their peer has a chance to see any cookie. In that case, two cookie extension fields MUST be included in all segments subsequently (once the traffic has caught up). That is, the sender and recipient cookies are handled independently. In such cases, both cookie values MUST be "good" at all relevant times (i.e., modulo the delay). In this case, the peer's initial cookie MUST arrive before the calculated delay for receipt of segments containing this engine's cookie -- there is only a finite window during which a second cookie can be inserted into the session.
双方が、ピアがクッキーを見る機会がある前に、最初のCookieを含むセグメントを放出することが起こります。その場合、その後、2つのCookie拡張フィールドをすべてのセグメントに含める必要があります（トラフィックが追いついたら）。つまり、送信者と受信者のCookieは独立して処理されます。そのような場合、両方のCookie値は、関連するすべての時間（つまり、遅延をmodulo）で「良好」でなければなりません。この場合、ピアの最初のCookieは、このエンジンのCookieを含むセグメントを受領するために計算された遅延の前に到着する必要があります。セッションに2番目のCookieを挿入できる有限ウィンドウのみがあります。
A "good" cookie is therefore one that starts with the currently stored cookie value, or else a new cookie where none has been seen in that session so far. Once a cookie value is seen and treated as "good" (e.g., an extended value), the previous value is no longer "good".
したがって、「良い」Cookieは、現在保存されているCookie値から始まるもの、またはそのセッションでこれまで見られなかった新しいCookieから始まるものです。Cookie値が「良い」（例：拡張値など）として扱われ、以前の値が「良い」ものではなくなりました。
Modulo the communications delay, segments with an incorrect or missing cookie value MUST be silently discarded.
通信遅延を測定すると、Cookie値が誤っていない、または欠落しているセグメントは静かに廃棄する必要があります。
If a segment is to be retransmitted (e.g., as a result of a timer expiring), then it needs to contain the correct cookie value at the time of (re)transmission. Note that this may differ from what was the correct cookie value at the time of the original transmission.
セグメントが再送信される場合（たとえば、タイマーが失効した結果として）、（RE）送信時に正しいCookie値を含める必要があります。これは、元の送信時の正しいCookie値とは異なる場合があることに注意してください。
The extensions specified above are generally intended to help thwart DoS attacks. For environments where lower layers provide neither integrity nor freshness, it makes sense to use both extensions together. For example, in the case where a node extends an existing cookie, the lack of origin authentication would allow a man in the middle to lock out the session.
上記で指定された拡張機能は、一般にDOS攻撃を阻止するのに役立つことを目的としています。下層が完全性も新鮮さも提供しない環境の場合、両方の拡張機能を一緒に使用することは理にかなっています。たとえば、ノードが既存のCookieを拡張する場合、Origin Authenticationが不足すると、中央の男性がセッションをロックアウトすることができます。
While there are currently some concerns about using the SHA-1 algorithm, these appear to only make it easier to find collisions. In that case, the use of HMAC with SHA-1 can still be considered safe. However, we have changed to use SHA-256 for the signature ciphersuite.
現在、SHA-1アルゴリズムを使用することにはいくつかの懸念がありますが、これらは衝突を見つけるのが簡単になるように見えます。その場合、SHA-1を使用したHMACの使用は依然として安全と見なすことができます。ただし、SHA-256を署名Ciphersuiteに使用するように変更されました。
IANA has created and now maintains registry for known LTP ciphersuites (as defined in Section 2.1). The registry has been populated using the initial values given in Sections 2.1 and 2.2 above. IANA may assign LTP Extension Tag values from the range 2..127 (decimal, inclusive) using the Specification Required rule [GUIDE]. The specification concerned can be an RFC (whether Standards Track, Experimental, or Informational), or a specification from any other standards development organization recognized by IANA or with a liaison with the IESG, specifically including CCSDS (http://www.ccsds.org/).
IANAは、既知のLTP Ciphersuitesのレジストリを作成し、維持しています（セクション2.1で定義されています）。レジストリは、上記のセクション2.1および2.2に示されている初期値を使用して入力されています。IANAは、仕様が必要なルール[ガイド]を使用して、範囲2..127（10進、包括的）からLTP拡張タグ値を割り当てることができます。関係する仕様は、RFC（標準の追跡、実験、情報のいずれか）、またはIANAによって認識されたその他の標準開発組織からの仕様、またはCCSDSを含むIESGとのリエゾン（http：//www.ccsdsの仕様です。org/）。
Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for their thoughts on this protocol and its role in Delay-Tolerant Networking architecture.
ティム・レイ、ヴィント・ケルフ、ボブ・ダースト、ケビン・フォール、エイドリアン・フック、キース・スコット、リー・トーガーソン、エリック・トラビス、ハウィー・ワイスに感謝します。
Part of the research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. This work was performed under DOD Contract DAA-B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407.
この文書に記載されている研究の一部は、国立航空宇宙局との契約の下で、カリフォルニア工科大学のジェット推進研究所で実施されました。この作業は、DOD契約DAA-B07-00-CC201、DARPA AO H912で実行されました。JPLタスクプランNo. 80-5045、DARPA AO H870;およびNASA契約NAS7-1407。
Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers at Ohio University for their suggestions and advice in making various design decisions. This work was done when Manikantan Ramadas was a graduate student at the EECS Dept., Ohio University, in the Internetworking Research Group Laboratory.
また、Shawn Ostermann、Hans Kruse、およびDovel Myersのおかげで、さまざまなデザインの決定を下すための提案とアドバイスに感謝します。この作業は、マニカンタン・ラマダスがオハイオ大学のEECS部門のインターネットワーキング研究グループ研究所の大学院生だったときに行われました。
Part of this work was carried out at Trinity College Dublin as part of the Dev-SeNDT contract funded by Enterprise Ireland's technology development programme.
この作業の一部は、エンタープライズアイルランドのテクノロジー開発プログラムが資金を提供する開発系契約の一環として、ダブリンのトリニティカレッジで実施されました。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[ガイド] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
[LTPSPEC] Ramadas、M.、Burleigh、S。、およびS. Farrell、「Licklider Transmission Protocol -Specification」、RFC 5326、2008年9月。
[RSA] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RSA] Jonsson、J。and B. Kaliski、「パブリックキー暗号化基準（PKCS）＃1：RSA暗号仕様バージョン2.1 "、RFC 3447、2003年2月。
[LTPMOTIVE] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
[LTPMotive] Burleigh、S.、Ramadas、M。、およびS. Farrell、「Licklider Transmission Protocol -Motivation」、RFC 5325、2008年9月。
[PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIXPROF] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[WRAP] Schaad, J. and R. Housley, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, May 2003.
[wrap] Schaad、J。and R. Housley、「トリプルデータ暗号化標準（DES）キーまたは高度な暗号化標準（AES）キーを備えたハッシュメッセージ認証コード（HMAC）キーをラッピングする」、RFC 3537、2003年5月。
Authors' Addresses
著者のアドレス
Stephen Farrell Computer Science Department Trinity College Dublin Ireland Telephone: +353-1-896-1761 EMail: stephen.farrell@cs.tcd.ie
スティーブンファレルコンピューターサイエンス部門トリニティカレッジダブリンアイルランド電話：353-1-896-1761メール：stephen.farrell@cs.tcd.ie
Manikantan Ramadas ISRO Telemetry Tracking and Command Network (ISTRAC) Indian Space Research Organization (ISRO) Plot # 12 & 13, 3rd Main, 2nd Phase Peenya Industrial Area Bangalore 560097 India Telephone: +91 80 2364 2602 EMail: mramadas@gmail.com
Manikantan Ramadas Isro Telemetry Tracking and Command Network（ISTRAC）Indian Space Research Organization（ISRO）PLOT＃12＆13、3番目のメイン、第2フェーズPeenya Industrial Area Bangalore 560097インド電話：91 80 2364 2602メール：mramadas@gmail.com
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 301-485B Pasadena, CA 91109-8099 Telephone: +1 (818) 393-3353 Fax: +1 (818) 354-1075 EMail: Scott.Burleigh@jpl.nasa.gov
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S：301-485B Pasadena、CA 91109-8099電話：1（818）393-3353 FAX：1（818）354-1075メール：scott.burleigh@jpl。NASA.GOV
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびhttp://www.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。