RFC5327 日本語訳
5327 Licklider Transmission Protocol - Security Extensions. S.Farrell, M. Ramadas, S. Burleigh. September 2008. (Format: TXT=23269 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループS.ファレル要求をネットワークでつないでください: 5327年のトリニティー・カレッジダブリンカテゴリ: 実験的なM.Ramadas ISTRAC、ISRO S.バーレイNASA/ジェット推進委研究所2008年9月
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.
このメモはインターネットコミュニティのために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のどんなレベルの候補ではありません。 それはインターネットResearch Task Force(IRTF)のDelay Tolerant Networking(DTN)研究Groupのコンセンサスを表します。 それは将来、標準化のためにIETFによって考えられるかもしれませんが、IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 詳しい情報に関してRFC3932を見てください。
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.
単一のホップ宇宙空間無線周波数(RF)の上の信頼できる集合層がリンクされるときLicklider Transmissionプロトコル(LTP)が役立つことを意図します。 LTPは、選択している承認レセプションレポートに請求することによって、データ伝送のAutomatic Repeat reQuest(ARQ)をします。 それは、statefulで、どんな交渉も握手も持っていません。 このドキュメントは、セキュリティ拡大について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.
このドキュメントは、Delay Tolerant Networking Research Groupの製品であり、そのグループによって再検討されました。 RFCとしての公表への反論は全く上げられませんでした。
Farrell, et al. Experimental [Page 1] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[1ページ]RFC5327LTP--拡大2008年9月
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
1. 序論…2 2. セキュリティ拡大…2 2.1. LTP認証…3 2.2. クッキーメカニズム…6 3. セキュリティ問題…7 4. IANA問題…7 5. 承認…8 6. 参照…8 6.1. 標準の参照…8 6.2. 有益な参照…9
1. Introduction
1. 序論
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]に拡大について説明します。 バックグラウンドは「動機」ドキュメント[LTPMOTIVE]にLTPに説明されます。 本書では定義されたすべての拡大が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は、接続性で非常に長いメッセージ往復の倍(RTTs)特徴付けられたリンク、そして/または、頻繁な中断の上に「再-トランスミッション」ベースの信頼性を提供するように設計されています。 惑星間空間の向こう側のコミュニケーションがこの種類の環境の最も際立った例であるので、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[B97]で説明されるように本書では解釈されることであるべきですか?
2. Security Extensions
2. セキュリティ拡大
The syntactical layout of the extensions are defined in Section 3.1.4 of the base protocol specification [LTPSPEC].
拡大の構文のレイアウトは.4のセクション3.1ベースプロトコル仕様[LTPSPEC]に基づき定義されます。
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.
Implementersは、LTP拡大メカニズムが両方でのどんな拡大タグの複数の発生(どちらか)のためにもヘッダーかトレーラを許容することに注意するはずです。 例えば、以下で定義されたLTP認証機構はヘッダーとトレーラ拡大の両方を必要とします。(ともに、それは、同じタグを使用します)。
Farrell, et al. Experimental [Page 2] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[2ページ]RFC5327LTP--拡大2008年9月
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.
Delay許容性があるNetworking(DTN)のかぎ管理が未解決の研究質問のままで残っているので、このドキュメントは、LTPのために新しいセキュリティ拡大を定義しますが、かぎ管理に演説しません。
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)は働くことができません(例えば、どこで、リンク遅れは数分間測定されますか)。
2.1. LTP Authentication
2.1. LTP認証
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セグメントヘッダーのExtensions分野の値として運ばれて、それの3番目がセグメントトレーラで運ばれる1番目)を必要とします。
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)を形成するために一緒にcatenatedされます。 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: 任意の主要な識別子。この仕様(すなわち、implementersはこれらのKeyID分野を生の八重奏として扱わなければなりません、例えばX.509 IssuerSerial構造物[PKIXPROF]をコード化するASN.1DERを含んだとしても)のための範囲の外にそれの解釈があります。
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セッションによっても、最初のセグメントで存在していなければなりませんが、そのセッションのときにその後のセグメントから省略されるかもしれません。 無くなっているセグメント、実現SHOULDから起こることにおける追加問題に用心するのは中でLTPセッションを区分します。そこでは、帯域幅は、許容して、数におけるこれらの分野を含んでいます。 最初のセグメント(または、それのどんな部分も)が再送されるなら、「再-トランスミッション」にLTP-authヘッダー拡張子を含まなければなりません。
Farrell, et al. Experimental [Page 3] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[3ページ]RFC5327LTP--拡大2008年9月
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つの例を入れるなら、受信機のための潜在的な問題がそんなにおそらく少なくとも分野が確かめないAuthValの1つにあります。 ほんのわずかな状況がそれがただ一つのセグメントで1つ以上のLTP-auth拡張子を含む意味になるところにあります、LTPが同輩への同輩プロトコルであるので。 しかしながら、キーがアップグレードしているなら、送付者は両方の新しくて古いキーでセグメントを保護するかもしれません。 そのような場合、受信機は、探さなければならなくて、1AuthValが正しい限り、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:
私たちはこの仕様に基づき3ciphersuitesを定義します。 私たちのアプローチはTLS[TLS]によって設定された先例、および"hardcode"へのただ一つのciphersuite番号におけるすべてのアルゴリズムオプションに続くことです。 これは、LTP-authのこのバージョンによって支持された256潜在的ciphersuitesがあることを意味します。 これが限られたスペースであるので、IANAはLTP Ciphersuitesのために下のIANA Considerations部で説明されるように登録を確立しました。 現在のciphersuite課題は以下の通りです。
Ciphersuite Value
----------- -----
HMAC-SHA1-80 0
RSA-SHA256 1
Unassigned 2-127
Reserved 128-191
Private/Experimental Use 192-254
NULL 255
Ciphersuite値----------- ----- 2-127に割り当てられなかったHMAC-SHA1-80 0RSA-SHA256 1は128-191 個人的であるか実験している使用192-254ヌル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つのMACingアルゴリズムしかありません。(それは、HMAC-SHA1-80[HMAC]です)。 AuthVal分野はこの場合まさしくHMAC-SHA1-80アルゴリズムの出力を含みます。(アルゴリズムは固定幅の分野(10の八重奏)です)。
Farrell, et al. Experimental [Page 4] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[4ページ]RFC5327LTP--拡大2008年9月
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. ヌル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と基本的に同じですが、hardcodedキーで同じです。 このciphersuiteは事実上、認証なしで強いチェックサムだけを提供して、その結果、活発な攻撃を受けることがあって、Cyclic Redundancy Check(CRC)を提供する同等物です。
The hardcoded key to be used with this ciphersuite is the
following:
このciphersuiteと共に使用されるべきhardcodedキーは以下です:
HMAC_KEY : c37b7e64 92584340
: bed12207 80894115
: 5068f738
(The above is the test vector from RFC 3537 [WRAP].)
HMAC_キー: c37b7e64 92584340: bed12207 80894115: 5068f738(上記はRFC3537[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|
+----+----+----+----+----+
extタグsdnv c-s k-イド+----+----+----+----+----+ |0×11|0×00|0×02|0×00|0×24| +----+----+----+----+----+
Farrell, et al. Experimental [Page 5] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[5ページ]RFC5327LTP--拡大2008年9月
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.
Extensions分野には、最も重要で最も重要でない少量値1がある値0x11があります、それぞれ1個のヘッダーと1つのトレーラ拡大の存在を示して。 次の八重奏は続くデータのNumeric Value(SDNV)を区切るSelfのコード化された長さがいうことになった拡大タグ(LTP-authのための0×00)です: 1八重奏のciphersuite(0×00意味HMAC-SHA1-80)とKeyID、(この場合、0×24の)短い値で。 トレーラ拡大(上では、目立たない)がAuthValを含むべきです。
2.2. A Cookie Mechanism
2.2. クッキーメカニズム
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エンジンはクッキーの偶発性に貢献します。(そこでは、それが役に立ちます)。 また、それは追加担保を加えることができないくらいの急(事情を変えるため言う)にそれが考えるノードにクッキー値を許容します。 この場合、拡張クッキー値はすべての将来のセグメント(コミュニケーションが同じくらい上に遅らせる法)のための「チェックされた」クッキー値になります。
Farrell, et al. Experimental [Page 6] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[6ページ]RFC5327LTP--拡大2008年9月
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つのクッキー拡大分野を含まなければなりません(交通がいったん追いつくと)。 すなわち、送付者と受取人クッキーは独自に扱われます。 そのような場合、両方のクッキー値が全く関連している「良い」回でなければならない、(すなわち、法、遅れ) この場合、同輩の初期のクッキーは計算された遅れの前にこのエンジンのクッキーを含むセグメントの領収書のために届かなければなりません--セッションまで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.
セグメントが再送される(例えば、タイマが期限が切れるという結果として)ことであるなら、それは、(re)トランスミッション時点で正しいクッキー値を含む必要があります。 これがオリジナルのトランスミッション時点で正しいクッキー値であったことと異なるかもしれないことに注意してください。
3. Security Considerations
3. セキュリティ問題
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の使用を考えることができます。 しかしながら、私たちは、署名ciphersuiteにSHA-256を使用するために変化しました。
4. IANA Considerations
4. IANA問題
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 ciphersuites(セクション2.1で定義されるように)のために登録であると主張します。 セクション2.1と2.2で上に与えられた初期の値を使用することで登録は居住されました。 IANAは値を範囲2からLTP Extension Tagに割り当てるかもしれません。127 (10進的、そして、包括的な) Specification Required規則[ガイド]を使用します。 関する仕様がRFCであるかもしれない、(
Farrell, et al. Experimental [Page 7] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[7ページ]RFC5327LTP--拡大2008年9月
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/).
規格Track、Experimental、またはInformational)、IANAによって認識されたいかなる他の規格開発組織か明確に、CCSDS( http://www.ccsds.org/ )を含むIESGとの連絡係がいる仕様
5. Acknowledgments
5. 承認
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.
Delay許容性があるNetworking構造におけるこのプロトコルとその役割に関する彼らの考えのためにティム・レイ、Vintサーフ、ボブDurst、ケビンFall、エードリアン・フック、キース・スコット、リー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 Contract DAA-B07 00-CC201、DARPA AO H912の下でこの仕事をしました。 DARPA AO H870、JPLはプランNo.80-5045に仕事を課します。 そして、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.
感謝は様々なデザイン決定をすることにおける彼らの提案とアドバイスを求めるオハイオ大学のショーン・オステルマン、ハンス・クルーゼ、およびDovelマイアーズのもためです。 Manikantan RamadasがEECS部の大学院生であったときに、この仕事をしました、オハイオ大学、Internetworking Research Group研究所で。
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.
この仕事の一部がエンタープライズアイルランドの技術開発プログラムで資金を供給されたデーウ-SeNDT契約の一部としてトリニティー・カレッジダブリンで行われました。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[B97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」(BCP26、RFC5226)は2008がそうするかもしれません。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
September 2008.
[LTPSPEC] Ramadas、M.、バーレイ、S.、およびS.ファレル、「Lickliderトランスミッションは議定書を作ります--仕様」、RFC5326、9月2008日
Farrell, et al. Experimental [Page 8] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[8ページ]RFC5327LTP--拡大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インチ、RFC3447、2月2003日
6.2. Informative References
6.2. 有益な参照
[LTPMOTIVE] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
Transmission Protocol - Motivation", RFC 5325, September
2008.
[LTPMOTIVE] バーレイ、S.、Ramadas、M.、およびS.ファレル、「Lickliderトランスミッションは議定書を作ります--動機」、RFC5325、9月2008日
[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)プロフィールをリストアップします」、RFC5280、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.レスコラ、「トランスポート層セキュリティ(TLS)は2008年8月にバージョン1.2インチ、RFC5246について議定書の中で述べます」。
[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、「Triple-データ暗号化規格(DES)キーかエー・イー・エス(AES)キーによって主要なHashedメッセージ立証コード(HMAC)を包装します」、RFC3537、2003年5月。
Farrell, et al. Experimental [Page 9] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[9ページ]RFC5327LTP--拡大2008年9月
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遠隔測定法の追跡とコマンドネットワーク(ISTRAC)インド宇宙研究機構(ISRO)陰謀#12と13(第3メイン)は2番目にPeenya工業地域バンガロール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
スコットC.バーレイジェット推進委研究所4800オーク木立ドライブM/S: 301-485 Bパサディナ、カリフォルニア91109-8099に電話をします: +1 (818) 393-3353Fax: +1 (818) 354-1075 メールしてください: Scott.Burleigh@jpl.nasa.gov
Farrell, et al. Experimental [Page 10] RFC 5327 LTP - Extensions September 2008
ファレル、他 実験的な[10ページ]RFC5327LTP--拡大2008年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78と 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Farrell, et al. Experimental [Page 11]
ファレル、他 実験的[11ページ]
一覧
スポンサーリンク
