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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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はインターネットStandardのどんなレベルの候補ではありません。これは、インターネット研究タスクフォースの遅延耐性ネットワーク（DTN）研究グループ（IRTF）のコンセンサスを表しています。これは、将来的にはIETFで標準化のために考慮することができるが、IETFが発行する決定はセキュリティのようなもののためにIETF見直し、混雑に基づいていないことを任意の目的のために特にノートに、このRFCのフィットネスの知識を否認しますコントロール、または展開されたプロトコルとの不適切な相互作用。詳細については、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.
リックライダー伝送プロトコル（LTP）は、単一ホップ深宇宙無線周波数（RF）リンクを介して信頼性の高い収束層として機能することが意図されています。 LTPは、選択的確認応答受信レポートを募集してデータ送信の自動再送要求（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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認証は、LTPセグメントヘッダの拡張フィールドの値、およびセグメントトレーラーで搬送された第三のように実行される最初の2つは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.
ヘッダ拡張フィールドで搬送されるフィールドは、（暗号スイートを表す左端のオクテットと、残りのオクテットKeyIDを有する）拡張値を形成するために一緒に鎖状に連結されています。 KeyIDをフィールドはオプションであり、拡張値は単一オクテットで構成されている場合は存在しないと判定されます。
Ciphersuite: an 8-bit integer value with values defined below.
暗号スイート：以下に定義する値を有する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 IssuerSerialのASN.1 DERエンコーディング構築物に含まれる場合であっても、生オクテットこれらの鍵IDフィールドを治療するなければなりません[例えば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）またはデジタル署名のいずれかである認証値が含ま。これは、その長さと書式設定暗号スイートに依存構造化フィールドそのものです。
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つのインスタンスが含まれている場合、確認しないであろうAuthValフィールドのおそらく少なくとも一方における受信機のための潜在的な問題があります。 LTPは、ピア・ツー・ピア・プロトコルであるため、それは、単一のセグメントに複数の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.
すべての暗号スイートのために、計算への入力は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つの暗号スイートを定義します。我々のアプローチは、TLS [TLS]で設定された先例に従うこと、および単一暗号スイート番号のすべてのアルゴリズムのオプションを「ハードコーディング」することです。これは、LTP-AUTHのこのバージョンでサポートされている256の潜在的な暗号スイートがあることを意味します。これは限られた空間であるため、以下のIANA Considerations部に記載されているように、IANAは、LTP Ciphersuitesをレジストリを確立しました。現在の暗号スイートの割り当ては以下のとおりです。
Ciphersuite Value
----------- -----
HMAC-SHA1-80 0
RSA-SHA256 1
Unassigned 2-127
Reserved 128-191
Private/Experimental Use 192-254
NULL 255
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の暗号スイートは、LTPセグメント上MACを生成し、セグメントの終わりに得られたAuthValフィールドを付加することを含みます。 HMAC-SHA1-80 [HMAC]である。このために定義された唯一のMACingアルゴリズムは、あります。この場合AuthValフィールドは固定幅フィールド（10オクテット）であるHMAC-SHA1-80アルゴリズムの出力だけを含んでいます。
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の暗号スイートは、LTPセグメントのデジタル署名を生成し、セグメントの終わりに得られたAuthValフィールドを付加することを含みます。 [RSA]、セクション8.2で定義されるようにSHA256とRSAは現在、このために定義された唯一の署名アルゴリズムがあります。この場合AuthValフィールドは、署名値がオクテットの最小数を占め、単に署名値であり、例えば、1024ビットの署名のために128オクテット）。
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の暗号スイートは、基本的には、HMAC-SHA1-80の暗号スイートと同じであるが、ハードコードされたキーを持ちます。この暗号スイートを効果的に認証なしでのみ強いチェックサムを提供し、従って、アクティブな攻撃の対象であり、巡回冗長検査（CRC）を提供するのと等価です。
The hardcoded key to be used with this ciphersuite is the following:
この暗号スイートで使用するハードコードされたキーは次のとおりです。
HMAC_KEY : c37b7e64 92584340 : bed12207 80894115 : 5068f738 (The above is the test vector from RFC 3537 [WRAP].)
HMAC_KEY：c37b7e64 92584340：80894115 bed12207：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セグメントから成ります。具体的には、暗号の組み合わせの数と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.
以下から始まり、拡張フィールドを含む、例えば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つのヘッダと一つトレーラ拡張の存在を示す、最上位と最下位ニブル値1と値0x11をを有しています。 1オクテットの暗号スイート（0x00を意味HMAC-SHA1-80）およびKeyIDを：次のオクテットは、続くデータの長さは符号化された自己区切り数値（SDNV）が続く拡張タグ（LTP-AUTH用0x00で）、あります（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.
クッキーの使用は、サービス拒否（DoS攻撃）をマウントしにくい攻撃するようにする、よく知られた方法です。私たちは、LTPの実装では、このような攻撃しやすい環境で使用するためのクッキーの拡張子を定義します。
The cookie is placed in a header extension field, and has no related trailer extension field. It has the extension tag value 0x01.
クッキーは、ヘッダ拡張フィールドに配置され、そしていかなる関連トレーラ拡張フィールドを持っていません。これは、拡張タグ値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.
クッキー値は、本質的に長さを実装することによって決定することができる十分に長い乱数、と見ることができる（より多くの帯域幅を使用しても、より長いクッキーは、推測しにくく、したがって、良好です）。彼らはランダム探しているとハードツー予測値を生成するように、そのクッキーの値は限り異なるスキームの多くを使用して導出することができます。
The first cookie inserted into a segment for this session is called the initial cookie.
このセッションのセグメントに挿入された第一のクッキーは、初期クッキーと呼ばれています。
Note that cookies do not outlast an LTP session.
クッキーは、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エンジンがいつでもセグメント内のクッキーを含むことができることです。その時間の後、そのLTPセッションに対応する全てのセグメントは、良好なクッキーの値を含まなければならない - つまり、エンジンへとの両方からのすべてのセグメントは、良好なクッキーを含まなければなりません。実装は、これらの場合の許容遅延を決定しなければならない、とだけそれまでクッキーなしにセグメントを受け入れなければなりません - クッキーが受信セグメントに見られる前に、明らかに、いくらかの遅延が存在するであろう。
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).
クッキー値は、よりランダムビットをcatenatingことにより、いつでも拡張することができます。これは、両方のLTPエンジンがそれが有用であるクッキーのランダム性に貢献することができます。また、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.
彼らのピアが任意のクッキーを見る機会を持って前に、双方が最初のクッキーを含むセグメントを発することを起こることができます。 （トラフィックが追いついた後）その場合には、2クッキーの拡張フィールドはその後、すべてのセグメントに含まれなければなりません。つまり、送信者と受信者のクッキーは、独立して処理されます。このような場合、両方のクッキー値（すなわち、遅延を法）全ての関連する時点で「良好」でなければなりません。この場合には、ピアの最初のクッキーは、このエンジンのクッキーを含むセグメントの受信のために計算された遅延の前に到着しなければならない - 第二のクッキーは、セッション内に挿入することができ、その間のみ有限の窓があります。
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".
「良い」クッキーは、それゆえ、現在保存されたクッキーの値、または他のどれもが、これまでそのセッションで見れていない新しいクッキーで始まるものです。クッキーの値を見て、「良好な」（例えば、拡張された値）として処理されると、前の値はもはや「良好」ではありません。
Modulo the communications delay, segments with an incorrect or missing cookie value MUST be silently discarded.
モジュロ通信遅延、誤ったまたは欠落クッキー値を有するセグメントを静かに捨てなければなりません。
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.
セグメントが再送信される場合（例えば、期限切れタイマーの結果として）、それは（再）送信時の正しいクッキー値を含む必要があります。これは、元の送信時に正しいクッキー値であったものと異なってもよいことに留意されたいです。
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攻撃を阻止助けることを意図しています。下位層はどちらも整合性も新鮮さを提供環境の場合、それは一緒に両方の拡張機能を使用することに意味があります。たとえば、ノードが既存のクッキーを拡張する場合には、発信元の認証の欠如は、真ん中の男がセッションをロックアウトすることができるようになります。
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を使用するように変更されました。
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
IANAは、作成され、現在知られているLTPの暗号スイート（セクション2.1で定義されている）のために、レジストリを維持しています。レジストリは、上記のセクション2.1および2.2で与えられた初期値を使用して取り込まれています。 IANAは、仕様が必要ルール[GUIDE]を使用して、範囲2..127（小数、含む）からLTP拡張タグ値を割り当てることができます。当該仕様は、RFC（かとすることができます
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/).
標準化過程、実験的、または情報）、または特別CCSDSを含む、IANAによってまたは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.
このプロトコルに自分の考えや遅延耐性ネットワークアーキテクチャにおけるその役割のためのティム・レイ、ヴィントン・サーフ、ボブ・ダースト、ケビン秋、エイドリアンフック、キース・スコット、リーTorgerson、エリック・トラヴィス、とハウィーワイスに感謝します。
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タスクプラン番号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.
おかげで、様々な設計上の決定を行う際に彼らの提案やアドバイスにもショーンOstermann、ハンス・クルーゼ、およびオハイオ大学のDovelマイヤーズによるものです。 Manikantan Ramadasは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.
この作品の一部は、アイルランド政府商務庁の技術開発プログラムによって資金を供給のDev-SeNDT契約の一環として、トリニティ・カレッジ・ダブリンで行われました。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
【LTPSPEC] Ramadas、M.、バーレイ、S.、およびS.ファレル、 "リックライダー伝送プロトコル - 仕様"、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]ジョンソン、J.と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]バーレイ、S.、Ramadas、M.、およびS.ファレル、 "リックライダー伝送プロトコル - 動機"、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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン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.とR. Housley氏、 "ラッピングキーハッシュメッセージ認証コード（HMAC）トリプルデータ暗号化規格（DES）とキーまたはのAdvanced Encryption Standard（AES）キー"、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 Eメール：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テレメトリー追跡およびコマンドネットワーク（ISTRAC）インド宇宙研究機関（ISRO）プロット＃12＆13、第三のメイン、第二期Peenya工業区のバンガロール560097インド電話：+91 80 2364 2602 Eメール：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
スコットC.バーレイジェット推進研究所4800オークグローブドライブM / S：301-485Bパサデナ、CA 91109から8099電話：+1（818）393から3353ファックス：+1（818）354から1075 Eメール：Scott.Burleigh @ jpl.nasa.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。