約 2,748,449 件
https://w.atwiki.jp/itb-100hd/pages/24.html
詳細 http //www.finevu.com/product/cr-500hd/cr-500hd.jsp 特徴 Sony Exmor R™ CMOS搭載 裏面照射型CMOSセンサー“Exmor R” 詳しくは http //www.sony.co.jp/SonyInfo/technology/technology/theme/exmor_r_01.html 外観 |||| 違うのはレンズ周りと表記だけ GPS,バッテリー保護装置（パワーマジックみたいなもの）付属していた オプションのはずだが.. 設定 | 期待するのは映像 さて 取り付けて撮影してきます。 映像 DR-500HD CPLなし DR400 DR-500HDの1分10秒位から 夜 条件 雨 DR-500HD CPLなし DR400 DR-500HDの1分15秒位から
https://w.atwiki.jp/code_matome/pages/40.html
3.3.2. Transform Substructure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Attributes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 Transform Substructure o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal. This syntax is inherited from ISAKMP, but is unnecessary because the last transform could be identified from the length of the proposal. The value (3) corresponds to a payload type of Transform in IKEv1, and the first four octets of the Transform structure are designed to look somewhat like the header of a payload. Proposalの最後のTransform Substructureであることを示す。このシンタックスはISAKMPから継承されている。ただし、最後のtransformはproposal lengthから特定できるため不要である。3はIKEv1におけるTransformのpayload typeで TransformはProposalのlengthから特定できるため不要である。3はIKEv1のTransformのpayload typeに対応し、Transform structureの最初の4オクテットがpayload headerになるように設計されている。 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 0で送信し、受信側は無視すること。 Kaufman, et al. Standards Track [Page 79] RFC 5996 IKEv2bis September 2010 o Transform Length - The length (in octets) of the Transform Substructure including Header and Attributes. HeaderとAttiributeを含むTransform Substructureのオクテット長。 o Transform Type (1 octet) - The type of transform being specified in this transform. Different protocols support different Transform Types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. If the initiator wishes to make use of the transform optional to the responder, it includes a transform substructure with Transform ID = 0 as one of the options. このTransformで指定されるTransform type。異なるprotocolは異なるTransform Typeをサポートする。いくつかのProtocolにおいては、Transformはオプションである。Trasnsformがオプションで、initiatorが省略するtransformを提案する場合、TransfromのTypeはProposalに含まれない。initiatorはresponderにオプションのTransformを使用することを示すため、オプションの一つとしてTransform ID=0のTransform Substructureを含める。 o Transform ID (2 octets) - The specific instance of the Transform Type being proposed. 提案されたTransform Type。 The Transform Type values are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Typeを下記に示す。下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。 Description Trans. Used In Type ------------------------------------------------------------------ Encryption Algorithm (ENCR) 1 IKE and ESP Pseudorandom Function (PRF) 2 IKE Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP Diffie-Hellman group (D-H) 4 IKE, optional in AH ESP Extended Sequence Numbers (ESN) 5 AH and ESP (*) Negotiating an integrity algorithm is mandatory for the Encrypted payload format specified in this document. For example, [AEAD] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated. このドキュメントにおいて、Integrity algorithmをネゴシエーションすることはEncrypted paylaodを指定する場合、必須である。例えば、[AEAD]では独立したintegrity algorithmはネゴシエーションされず、認証された暗号化方式に基づき、追加のフォーマットを指定する。 For Transform Type 1 (Encryption Algorithm), the Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 1(Encryption Algorithm)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Kaufman, et al. Standards Track [Page 80] RFC 5996 IKEv2bis September 2010 Name Number Defined In --------------------------------------------------- ENCR_DES_IV64 1 (UNSPECIFIED) ENCR_DES 2 (RFC2405), [DES] ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_CAST 6 (RFC2451) ENCR_BLOWFISH 7 (RFC2451) ENCR_3IDEA 8 (UNSPECIFIED) ENCR_DES_IV32 9 (UNSPECIFIED) ENCR_NULL 11 (RFC2410) ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CTR 13 (RFC3686) For Transform Type 2 (Pseudorandom Function), the Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 2(Pseudorandom Function)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Name Number Defined In ------------------------------------------------------ PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_TIGER 3 (UNSPECIFIED) For Transform Type 3 (Integrity Algorithm), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 3(Integrity Algorithm)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Name Number Defined In ---------------------------------------- NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_DES_MAC 3 (UNSPECIFIED) AUTH_KPDK_MD5 4 (UNSPECIFIED) AUTH_AES_XCBC_96 5 (RFC3566) For Transform Type 4 (Diffie-Hellman group), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 4(Diffie-Hellman group)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Kaufman, et al. Standards Track [Page 81] RFC 5996 IKEv2bis September 2010 Name Number Defined In ---------------------------------------- NONE 0 768-bit MODP 1 Appendix B 1024-bit MODP 2 Appendix B 1536-bit MODP 5 [ADDGROUP] 2048-bit MODP 14 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP] Although ESP and AH do not directly include a Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, providing perfect forward secrecy for the generated Child SA keys. ESP/AHはDiffie-Hellman exchangeが含まれていないが、Diffie-Hellman groupはChild SAのためにネゴシエーションされる。これは、生成されたChild SA keyにforward secrecyを提供し、CREATE_CHILD_SA exchangeにおいてpeerがDiffie-Hellmanを使うことを可能とする。 For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform Type 5(Extended Sequence Numbers)におけるTransform IDは下記である。下記はRFC4306をもとにしており、最新の値は[IKEV2IANA]にある。 Name Number -------------------------------------------- No Extended Sequence Numbers 0 Extended Sequence Numbers 1 Note that an initiator who supports ESNs will usually include two ESN transforms, with values 0 and 1 , in its proposals. A proposal containing a single ESN transform with value 1 means that using normal (non-extended) sequence numbers is not acceptable. ESNをサポートするinitiatorは、通常、Proposalに2つのESN Transform 1、0が含まれることに注意せよ。1のESN Transformのみ含むProposalはnon-extended sequence numberを許可しないことを示す。 Numerous additional Transform Types have been defined since the publication of RFC 4306. Please refer to the IANA IKEv2 registry for details. RFC 4306の発行後、多くのTransform Typeが追加された。詳細は[IKEV2IANA]参照。 3.3.3. Valid Transform Types by Protocol The number and type of transforms that accompany an SA payload are dependent on the protocol in the SA itself. An SA payload proposing the establishment of an SA has the following mandatory and optional Transform Types. A compliant implementation MUST understand all mandatory and optional types for each protocol it supports (though it need not accept proposals with unacceptable suites). A proposal MAY omit the optional types if the only value for them it will accept is NONE. SA payloadのTrsnform Typeと数はSAのプロトコルに依存する。SAの確立を提案するSA payloadには必須/オプションのTransform Typeがある。準拠した実装では、実装がサポートするプロトコル毎の必須/オプションを識別する必要がある（許容できないsuiteのproposalは許可する必要はない）。唯一許容する値がNONEの場合、ProposalのOptional Typeを省略してよい。 Protocol Mandatory Types Optional Types --------------------------------------------------- IKE ENCR, PRF, INTEG*, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H (*) Negotiating an integrity algorithm is mandatory for the Encrypted payload format specified in this document. For example, [AEAD] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated. このドキュメントにおいて、Integrity algorithmをネゴシエーションすることはEncrypted paylaodを指定する場合、必須である。例えば、[AEAD]では独立したintegrity algorithmはネゴシエーションされず、認証された暗号化方式に基づき、追加のフォーマットを指定する。 3.3.4. Mandatory Transform IDs The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves. At the time of publication of this document, [RFC4307] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. 相互運用性とドキュメントが変化する可能性がある関係で必須のsuiteは規定しない。このドキュメント発行時点ではRFC4307に基づくsuiteを規定するが、将来更新され他のRFCの異なるsuiteが規定される可能性があることに注意せよ。。 An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. IKEv1から学んだ重要なことは、必須のアルゴリズムのみを実装しており、れが全ての顧客が最も期待しているというシステムはないことである。 It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits. In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman parameters (the generator, modulus, and exponent lengths and values) for new Diffie-Hellman groups. Implementations SHOULD provide a management interface through which these parameters and the associated Transform IDs may be entered (by a user or system administrator), to enable negotiating such groups. IANAが将来transformを追加し、private suiteとしてユーザーが使用することができ、特定のサイズ制限内でIKEの実装はそれらのパラメータをサポートすることができる。この目的のため、IKEv2の実装では新しいDiffie-Hellman groupのDiffie-Hellman parameters(the generator, modulus, and exponent lengths and values)を設定できる（ユーザー or システム管理者により）管理機能を含めるべきである。実装ではそのようなgroupのネゴシエーションが可能なように、parameterと関連するTransform IDが入力できる（ユーザー or システム管理者から）管理インターフェースを提供するべきである。 All implementations of IKEv2 MUST include a management facility that enables a user or system administrator to specify the suites that are acceptable for use with IKE. Upon receipt of a payload with a set of Transform IDs, the implementation MUST compare the transmitted Transform IDs against those locally configured via the management controls, to verify that the proposed suite is acceptable based on local policy. The implementation MUST reject SA proposals that are not authorized by these IKE suite controls. Note that cryptographic suites that MUST be implemented need not be configured as acceptable to local policy. IKEv2のすべての実装は、IKEで使用することを許容するsuiteを指定することをユーザーorシステム管理者に可能とする管理機能を含めること。Transform IDのsetのpayloadを受信すると、実装は、提案されたsuiteがローカルポリシーに基づき許可されるかを検証するため、management controlを経由してローカル設定と送信されたTransform IDを比較すること。実装は、これらのIKE suite制御によって、許容しないSAのproposalを拒絶すること。実装が必須なcryptographic suiteはローカルポリシーで許容されるように設定される必要はないことに注意せよ。 3.3.5. Transform Attributes Each transform in a Security Association payload may include attributes that modify or complete the specification of the transform. The set of valid attributes depends on the transform. Currently, only a single attribute type is defined the Key Length attribute is used by certain encryption transforms with variable- length keys (see below for details). Security Association payloadのTransformはtransformの仕様を設定/決定するAttributeを含めてよい。設定可能なAttributeはTransformによって異なる。現在一つのAttribute typeが定義されている。Key Length attributeは特定のEncryption Transfromの可変キー長を指定する(詳細は下記参照)。 The attributes are type/value pairs and are defined below. Attributes can have a value with a fixed two-octet length or a variable-length value. For the latter, the attribute is encoded as type/length/value. Attributeはtype/valueのペアで以下のように定義される。Attirubuteは2オクテットまたは可変長の値である。後者の場合、Attributeはtype/length/valueにエンコードされる。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Attribute Type | AF=0 Attribute Length | |F| | AF=1 Attribute Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AF=0 Attribute Value | | AF=1 Not Transmitted | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 Data Attributes o Attribute Format (AF) (1 bit) - Indicates whether the data attribute follows the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is zero (0), then the attribute uses TLV format; if the AF bit is one (1), the TV format (with two-byte value) is used. AttibuteがType/Length/Value(TLV)か短縮形のType/Value(TV)かを示す。AFが0の場合、attributeはTLV形式を使用する。AFが1の場合、TV（2バイトvalue）を使用する。 o Attribute Type (15 bits) - Unique identifier for each type of attribute (see below). Attributeのtypeを識別する識別子。下記参照。 o Attribute Value (variable length) - Value of the attribute associated with the attribute type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets. Attribute typeに関連するAttributeのvalue。AF bitが0の場合、このfieldはAttribute Length filedで定義された変数長をもつ。AFが1の場合、Attirbute Valueは2オクテットである。 The only currently defined attribute type (Key Length) is fixed length; the variable-length encoding specification is included only for future extensions. Attributes described as fixed length MUST NOT be encoded using the variable-length encoding unless that length exceeds two bytes. Variable-length attributes MUST NOT be encoded as fixed-length even if their value can fit into two octets. Note This is a change from IKEv1, where increased flexibility may have simplified the composer of messages but certainly complicated the parser. 現在、固定長のKey Lengthのみがattribute typeとして定義されている。可変長エンコーディングは今後の拡張のために含まれている。固定長として定義されるAttributeは2オクテットを超えない場合、可変長エンコーディングしないこと。可変長として定義されるAttirbuteは2オクテット内になる場合でも固定長エンコーディングしないこと。注意：これはIKEv1からの変更で、メッセージの構成に柔軟性はあるが、パースが複雑になる。 The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。 Attribute Type Value Attribute Format ------------------------------------------------------------ Key Length (in bits) 14 TV Values 0-13 and 15-17 were used in a similar context in IKEv1, and should not be assigned except to matching values. 0～13、15～17は同じコンテキストとしてIKEv1で使用されるため、一致する値以外には割り当てないこと。 The Key Length attribute specifies the key length in bits (MUST use network byte order) for certain transforms as follows Key Length attributeは以下のように特定のTransformでkey lengthのbit長(ネットワークバイトオーダーを使用すること)を規定する。 o The Key Length attribute MUST NOT be used with transforms that use a fixed-length key. For example, this includes ENCR_DES, ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3 (Integrity Algorithm) transforms specified in this document. It is recommended that future Type 2 or 3 transforms do not use this attribute. Key Length attributeは固定長のkeyを使用するTransformに使用しないこと。例えば、ENCR_DES、ENCR_IDEAとType 2(Pseudorandom function)Transfrom、Type 3(Integrity Algorith) Transfromである。将来のType 2、Type3のTransformもこのAttributeを使用しないことを推奨する。 o Some transforms specify that the Key Length attribute MUST be always included (omitting the attribute is not allowed, and proposals not containing it MUST be rejected). For example, this includes ENCR_AES_CBC and ENCR_AES_CTR. いくつかのTransformはKey Length attribtuteを常に含む(Attributeが含まれないことが許容されない場合、Proposalは拒否されること)。例えば、ENCR_AES_CBC、ENCR_AES_CTRがある。 o Some transforms allow variable-length keys, but also specify a default key length if the attribute is not included. For example, these transforms include ENCR_RC5 and ENCR_BLOWFISH. いくつかのTransformは可変長キーを許可し、attributeを含まない場合、デフォルトのkey lengthを用いる。例えば、ENCR_RC5、ENCR_BLIWFISHがある。 Implementation note To further interoperability and to support upgrading endpoints independently, implementers of this protocol SHOULD accept values that they deem to supply greater security. For instance, if a peer is configured to accept a variable-length cipher with a key length of X bits and is offered that cipher with a larger key length, the implementation SHOULD accept the offer if it supports use of the longer key. Support for this capability allows a responder to express a concept of at least a certain level of security -- a key length of _at least_ X bits for cipher Y . However, as the attribute is always returned unchanged (see the next section), an initiator willing to accept multiple key lengths has to include multiple transforms with the same Transform Type, each with a different Key Length attribute. 実装上の注意：相互運用性の向上およびエンドポイントのアップグレードを提供するため、プロトコルの実装では高いセキュリティを提供するための値を許容すること。例えば、peerがkey length X bitの可変長暗号を許容するように設定されていて、より長いキー長を要求された場合、長いキーをサポートする場合は、実装はその要求を許容するべきである。この機能の提供はresponderが最低限のsecurity levelを表すことを可能にする（暗号Yのkey lengthは最低でもX bit）。しかし、attributeは変更されずに返されるため（次のセクション参照）、複数のkey lengthを受け入れるinitiatorは、同じTransfomr Type、異なるKey Length attributeの複数のtransformを含める。 3.3.6. Attribute Negotiation During Security Association negotiation initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers (or reject all offers if none are acceptable). If there are multiple proposals, the responder MUST choose a single proposal. If the selected proposal has multiple transforms with the same type, the responder MUST choose a single one. Any attributes of a selected transform MUST be returned unmodified. The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not MUST terminate the exchange. Security Associationのネゴシエーション中、initiatorはresponderに要求する際。Responderは要求から、パラメータの一つを選択する(すべての要求を許容できない場合、拒否する)。複数のproposalがある場合、responderは一つのproposalを選択すること。選択されたproposalが同じtypeのtransformを複数もつ場合、responderは一つを選択すること。選択したいずれかのattibuteを変更せずに応答すること。exchangeのinitiatorは応答がinitiatorのproposalと一致しているか確認すること。一致していない場合、exchangeを終了する。 If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and Transform Attributes to be defined in the future. responderが解釈できないTransfrom Type、必須のTransform TypeのないProposalを受信した場合、Proposalは許容しないこと。ただし、同じSA payloadの他のProposalは通常通り処理される。同様にresponderは解釈できないTransform、解釈できないTransform Attributeを含むtrasnfromについても許容しないこと。ただし、同じTransform Typeをもつ他のTransformは通常通り処理されること。これは、将来、新しいTransform Type、Transform Attributeが定義されることを許容する。 Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and include a KE corresponding to that group. If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. It SHOULD, however, continue to propose its full supported set of groups in order to prevent a man-in-the- middle downgrade attack. If one of the proposals offered is for the Diffie-Hellman group of NONE, and the responder selects that Diffie- Hellman group, then it MUST ignore the initiator s KE payload and omit the KE payload from the response. Diffie-Hellman groupのネゴシエーションにはいくつかの特別な課題がある。SAの要求は同じメッセージにproposal attributeとDiffie-Hellman public number(KE)を含む。initial exchangeでinitiatorが複数のDiffie-Hellman groupから一つの使用を要求する場合、initiatorはresponderがそれを選ぶようにKEに対応するgroupを含める。responderが異なるDiffie-Hellman group (NONEを除く)を選択する場合、responderは適切なgroupをresponseで示し、initiatorはそのgroupをKEに選択し、最初のメッセージを再試行する。ただし、initiatorはman-in-the-middle downgrade attackを防ぐためにgroupのフルセットをproposeし続けること。要求された一つがDiffie-Hellman group NONEであり、responderがそのDiffie-Hellman groupを選択した場合、responderはinitiatorのKE payloadを無視し、initiatorは応答のKE paylaodを切り捨てること。 3.4. Key Exchange Payload The Key Exchange payload, denoted KE in this document, is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself. Key Exchange payloadはKEと表記され、Diffie-Hellman鍵交換の一部として、Diffie-Hellman public numberを交換するために使用される。Key Exchange paloadはIKE generic payloadとDiffie-Hellman public valueで構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diffie-Hellman Group Num | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Key Exchange Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 Key Exchange Payload Format A Key Exchange payload is constructed by copying one s Diffie-Hellman public value into the Key Exchange Data portion of the payload. The length of the Diffie-Hellman public value for modular exponentiation group (MODP) groups MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary. Key Exchange payloadはpayloadのKey Exchange DataにDiffie-Hellman public valueを設定する。(modular exponentiation group)MODP groupのDiffie-Hellman public valueの値はprime module(素数)と同じ長さであること。必要であれば0で埋めること。 The Diffie-Hellman Group Num identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). This Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified in a proposal in the SA payload that is sent in the same message, and SHOULD match the Diffie-Hellman group in the first group in the first proposal, if such exists. If none of the proposals in that SA payload specifies a Diffie-Hellman group, the KE payload MUST NOT be present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7. Diffie-Hellman Group NumはKey Exchange Dataが算出されるDiffie-Hellman groupを識別する（Section 3.3.2参照）。Diffie-Hellman Group Numは同じメッセージで送信されたSA payloadのproposalで規定されたDiffie-Hellman groupと一致すること。さらに、最初proposalと一致すること。SA payloadでDiffie-Hellman groupがporoposalされない場合、KE payloadを提供しないこと。選択されたproposalが異なるdifferent Diffie-Hellman group (NONE以外)の場合、messageはINVALID_KE_PAYLOADでrejectすること。Section 1.2と2.7参照。 The payload type for the Key Exchange payload is thirty-four (34). Key Exchange payloadのpayload typeは34である。 3.5. Identification Payloads The Identification payloads, denoted IDi and IDr in this document, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. Identification PayloadはIDi、IDrと表現され、peerが相互に他方にIDを通知するために使用する。このIDはpolicy検索に使用できるが、CERT payloadとマッチする必要はない。両方のfieldはアクセス制御の決定をするために実装で使用される。IDi/IDr paylaodでID_IPV4_ADDR/ID_IPV6_ADDR identity typesを使用する場合、IKEv2ではIKEv2のIP headerアドレスまたはTSi/TSr paylaodと一致することを必要としない。IDi/IDrは相手のpolicyと認証データを照会するために使用される。 NOTE In IKEv1, two ID payloads were used in each direction to hold Traffic Selector (TS) information for data passing over the SA. In IKEv2, this information is carried in TS payloads (see Section 3.13). NOTE IKEv1では2つのID payloadが各方向でSA上でデータを通過させるためのTraffic Selector情報を保持するために使われる。IKEv2ではこの情報はTS payloadで設定される(Section 3.13)。 The Peer Authorization Database (PAD) as described in RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement. The PAD is intended to provide a link between the SPD and the IKE Security Association management. See Section 4.4.3 of RFC 4301 for more details. RFC 4301[IPSECARCH]にあるように、Peer Authorization Database(PAD)はIKEのID payloadの使用方法とpolicyの適用方法を具体化するための形式的なモデルを提供する。PADはSPDとIKE Security Association managementとのリンクを提供する。詳細はRFC 4301 Section 4.4.3を参照。 The Identification payload consists of the IKE generic payload header followed by identification fields as follows Identification payloadはIKE generic paylaod headerと下記のidentification fieldで構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Identification Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 Identification Payload Format o ID Type (1 octet) - Specifies the type of Identification being used. Identificationのtypeを規定する。 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 0を設定し、受信者は無視すること。 o Identification Data (variable length) - Value, as indicated by the Identification Type. The length of the Identification Data is computed from the size in the ID payload header. Identification Typeで規定される値。Identification DataのlengthはID paylaod header内のsizeから計算される。 The payload types for the Identification payload are thirty-five (35) for IDi and thirty-six (36) for IDr. Identificatin paylaodのpayload typeはIDiが35、IDrが36である。 The following table lists the assigned semantics for the Identification Type field. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 下記の表はIdentification Type filedに割り当てられたセマンティクスである。最新の情報は[IKEV2IANA]参照。下記の表はRFC4306発行時のものである。その他の値が追加される可能性もある。最新の情報は[IKEV2IANA]参照。 ID Type Value ------------------------------------------------------------------- ID_IPV4_ADDR 1 A single four (4) octet IPv4 address. 4オクテットのIPv4アドレス。 ID_FQDN 2 A fully-qualified domain name string. An example of an ID_FQDN is example.com . The string MUST NOT contain any terminators (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an internationalized domain name , the syntax is as defined in [IDNA], for example xn--tmonesimerkki-bfbb.example.net . FQDMの文字列。ID_FQDNの例は example.com である。文字列はNULL、CRなどで終端しないこと。ID_FQDNの文字はすべてASCIIである。[IDNA]で定義されたinternationalized domain nameで例えばxn--tmonesimerkki-bfbb.example.netである。 ID_RFC822_ADDR 3 A fully-qualified RFC 822 email address string. An example of a ID_RFC822_ADDR is jsmith@example.com . The string MUST NOT contain any terminators. Because of [EAI], implementations would be wise to treat this field as UTF-8 encoded text, not as pure ASCII. 完全修飾のRFC 822のemail addressの文字列。ID_RFC822_ADDRの例はjsmith@example.comである。文字列には終端を含まないこと。[EAI]により実装ではASCIIではなくUTF-8 encoded textとして扱ったほうがよい。 ID_IPV6_ADDR 5 A single sixteen (16) octet IPv6 address. 16オクテットのIPv6アドレス。 ID_DER_ASN1_DN 9 The binary Distinguished Encoding Rules (DER) encoding of an ASN.1 X.500 Distinguished Name [PKIX]. ASN.1 X.500[PKIX]のバイナリDER encoding。 ID_DER_ASN1_GN 10 The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX]. ASN.1 X.509[PKIX]のバイナリDER encoding。 ID_KEY_ID 11 An opaque octet stream that may be used to pass vendor- specific information necessary to do certain proprietary types of identification. オクテット列でベンダー仕様の独自のID typeを渡すために使用してよい。 Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these four types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for IP addresses. お互いが他方が許容できるIDタイプを生成できる場合、2つの実装（2種類のID）が相互運用する。最大の相互運用性を保証するためには、実装はID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_IDの少なくとも一つを送信し、4つのどのタイプでも許容できることが可能であること。実装は全てのタイプを生成でき、許容できること。IPv6に対応した実装ではID_IPV6_ADDRを許容できること。IPv6のみの実装ではID_IPV4_ADDRの代わりにID_IPV6_ADDRのみを送信してもよい。 EAP [EAP] does not mandate the use of any particular type of identifier, but often EAP is used with Network Access Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like email addresses (e.g., joe@example.com ), the syntax is not exactly the same as the syntax of email address in [MAILFORMAT]. For those NAIs that include the realm component, the ID_RFC822_ADDR identification type SHOULD be used. Responder implementations should not attempt to verify that the contents actually conform to the exact syntax given in [MAILFORMAT], but instead should accept any reasonable-looking NAI. For NAIs that do not include the realm component, the ID_KEY_ID identification type SHOULD be used. EAPは特定のIDタイプを指定しないが、たいてい[NAI]で定義されたNetwork Access Identifiers(NAI)が使用される。NAIはemail addressのように見えるが（例：joe@example.com）、構文は[MAILFORMAT]とは厳密には同じではない。realmを含むNAIはID_RFC822_ADDRのIDタイプを使用すること。responderの実装は、[MAILFORMAT]によるチェックではなく、NAIの定義によりチェックすること。NAIがrealmを含まない場合、ID_KEY_ID identification typeを使用すること。 3.6. Certificate Payload The Certificate payload, denoted CERT in this document, provides a means to transport certificates or other authentication-related information via IKE. Certificate payloads SHOULD be included in an exchange if certificates are available to the sender. The Hash and URL formats of the Certificate payloads should be used in case the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the term Certificate payload is somewhat misleading, because not all authentication mechanisms use certificates and data other than certificates may be passed in this payload. Certificate payload はCERTと表記され、IKEによる証明書や認証関連情報の転送を提供する。証明書を送信者が利用する場合、Certificate payloadがexchangeに含まれること。peerがHTTP_CERT_LOOKUP_SUPPORTED Notify payloadを使用し、この情報を取得する能力を通知してから、Certificate payloadのHash and URL formatが使用されること。 Certificate payload は誤解を招くのに注意せよ。なぜなら、すべての認証メカニズムが証明書を使用するとは限らず、証明書以外のデータも送信されるため。 The Certificate payload is defined as follows Certificate payload は下記のように定義される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Encoding | | +-+-+-+-+-+-+-+-+ | ~ Certificate Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 Certificate Payload Format o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. このfieldはCertificate Data fieldに含まれる証明書または証明書関連情報のtypeを示す。下記の値および以降に追加されてた値が設定される。下記はRFC4306発行時のものである。以降に追加された値は[IKEV2IANA]参照。 Certificate Encoding Value ---------------------------------------------------- PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED PGP Certificate 2 UNSPECIFIED DNS Signed Key 3 UNSPECIFIED X.509 Certificate - Signature 4 Kerberos Token 6 UNSPECIFIED Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 UNSPECIFIED SPKI Certificate 9 UNSPECIFIED X.509 Certificate - Attribute 10 UNSPECIFIED Raw RSA Key 11 Hash and URL of X.509 certificate 12 Hash and URL of X.509 bundle 13 o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field. 証明書データのencoding。証明書のtypeはCertificate Encoding fieldで示される。 The payload type for the Certificate payload is thirty-seven (37). Certificate payloadのpayload typeは37である。 Specific syntax for some of the certificate type codes above is not defined in this document. The types whose syntax is defined in this document are 上記の証明書 type codeのすべてのシンタックスは本ドキュメントでは規定しない。本ドキュメントでは下記のtypeのシンタックスを定義する。 o X.509 Certificate - Signature contains a DER-encoded X.509 certificate whose public key is used to validate the sender s AUTH payload. Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender s AUTH payload. X.509 Certificate - Signature は、送信者のAUTH payloadを検証するために使用されるpublic keyの DER-encoded X.509証明書が含まれる。エンコーディングは、証明書チェーンを送信する必要がある場合、複数のCERT payloadが使用され、最初のpayloadだけ送信者のAUTH payloadを検証するために使用されるpublic keyを含む。 o Certificate Revocation List contains a DER-encoded X.509 certificate revocation list. Certificate Revocation List はDER-encoded X.509の証明書の失効リストが含まれる。 o Raw RSA Key contains a PKCS #1 encoded RSA key, that is, a DER- encoded RSAPublicKey structure (see [RSA] and [PKCS1]). Raw RSA Key はPKCS #1 encoded RSA keyつまり、DER-encoded RSAPublicKey structureが含まれる（[RSA]、[PKCS1]参照）。 o Hash and URL encodings allow IKE messages to remain short by replacing long data structures with a 20-octet SHA-1 hash (see [SHA]) of the replaced value followed by a variable-length URL that resolves to the DER-encoded data structure itself. This improves efficiency when the endpoints have certificate data cached and makes IKE less subject to DoS attacks that become easier to mount when IKE messages are large enough to require IP fragmentation [DOSUDPPROT]. Hash and URL encodingにより、長いdata structuresをDER-encoded data structureに対応する可変長URLに続く20-octet SHA-1 hashに置き換えることで、IKE messageを短くすることができる。これにより、証明書データがキャッシュされているときの効率化と、IP fragmentを利用したDoS攻撃の防止になる[DOSUDPPROT]。 The Hash and URL of a bundle type uses the following ASN.1 definition for the X.509 bundle Hash and URL of a bundle typeは下記のX.509 bundleのASN.1定義を使用する。 CertBundle { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cert-bundle(34) } DEFINITIONS EXPLICIT TAGS = BEGIN IMPORTS Certificate, CertificateList FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ; CertificateOrCRL = CHOICE { cert [0] Certificate, crl [1] CertificateList } CertificateBundle = SEQUENCE OF CertificateOrCRL END Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the Hash and URL format (with HTTP URLs). Implementations SHOULD be capable of being configured to send and accept Raw RSA keys. If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order. 実装は認証をサポートする4つのX.509証明書の送受信が構成できること。また、Hash and URL formatの送受信が構成できること。実装はRaw RSA keyの送受信を構成できること。複数の証明書を送信する場合、最初の証明書はAUTH payloadの署名に使用するpublic keyを含めること。その他の証明書は任意の順番で送信してよい。 Implementations MUST support the HTTP [HTTP] method for hash-and-URL lookup. The behavior of other URL methods [URLS] is not currently specified, and such methods SHOULD NOT be used in the absence of a document specifying them. 実装は、hash-and-URL lookupのためのHTTP methodをサポートすること。他のURL method[URLS]は現在規定されず、そのようなmethodはそれらを規定するドキュメントが存在しない場合に使用しないこと。 3.7. Certificate Request Payload The Certificate Request payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. Certificate Request payloadはCERTREQと表記され、IKEで証明書を要求する手段を提供し、IKE_INIT_SA responseとIKE_AUTH requestで送信される。Certificate Request payloadは、送信者が受信者の証明書を取得する必要がある場合、Certificate Request payloadがexchangeに含まれてよい。 The Certificate Request payload is defined as follows Certificate Request payloadは下記のように定義される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Encoding | | +-+-+-+-+-+-+-+-+ | ~ Certification Authority ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 Certificate Request Payload Format o Certificate Encoding (1 octet) - Contains an encoding of the type or format of certificate requested. Values are listed in Section 3.6. 要求された証明書の種類、encoding typeが含まれる。値のリストはSection 3.6参照。 o Certification Authority (variable length) - Contains an encoding of an acceptable certification authority for the type of certificate requested. 要求された証明書のタイプの認証局のencodingが含まれる。 The payload type for the Certificate Request payload is thirty-eight (38). Certificate Request payloadのpaylaod typeは38である。 The Certificate Encoding field has the same values as those defined in Section 3.6. The Certification Authority field contains an indicator of trusted authorities for this certificate type. The Certification Authority value is a concatenated list of SHA-1 hashes of the public keys of trusted Certification Authorities (CAs). Each is encoded as the SHA-1 hash of the Subject Public Key Info element (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. The 20-octet hashes are concatenated and included with no other formatting. Certificate Encoding fieldはSection 3.6の定義と同じ値である。Certification Authority fieldは証明書typeの認証局のindicatorが含まれる。Certification Authority valueは、認証局(CA)のpublic keyのSHA-1ハッシュの連結リストである。それぞれが、Subject Public Key Info element(see section 4.1.2.7 of [PKIX])のSHA-1ハッシュとしてそれぞれのTrust Anchor certificateからencodeされる。20-octetのハッシュには他のフォーマットが連結されず、含まれない。 The contents of the Certification Authority field are defined only for X.509 certificates, which are types 4, 12, and 13. Other values SHOULD NOT be used until Standards-Track specifications that specify their use are published. Certification Authority fieldの内容はX.509証明書のみ定義され、typeは4、12、13である。他の値は他の値を規定する仕様が公開されるまで使用しないこと。 Kaufman, et al. Standards Track [Page 93] RFC 5996 IKEv2bis September 2010 Note that the term Certificate Request is somewhat misleading, in that values other than certificates are defined in a Certificate payload and requests for those values can be present in a Certificate Request payload. The syntax of the Certificate Request payload in such cases is not defined in this document. Certificate Request は誤解を招くことに注意せよ。 Certificate payloadに証明書以外の値が定義され、Certificate Request payloadによりそれらの値が要求される場合がある。それらの場合におけるCertificate Request payloadのsyntaxはこのドキュメントでは定義されない。 The Certificate Request payload is processed by inspecting the Cert Encoding field to determine whether the processor has any certificates of this type. If so, the Certification Authority field is inspected to determine if the processor has any certificates that can be validated up to one of the specified certification authorities. This can be a chain of certificates. Certificate Request payloadはprocessorがどのタイプの証明書を持っているかを Cert Encoding fieldを検証して処理する。 Certification Authority fieldは認証局を検証できる証明書を持っているか判断するために検証される。これは証明書チェーンをすることができる。 If an end-entity certificate exists that satisfies the criteria specified in the CERTREQ, a certificate or certificate chain SHOULD be sent back to the certificate requestor if the recipient of the CERTREQ CERTREQの条件を満たすend-entity証明書が存在する場合、CERTREQの受信者は証明書または証明書チェーンを証明書の要求者に送信すること。 o is configured to use certificate authentication, 証明書認証を使用することが設定されている。 o is allowed to send a CERT payload, CERT payloadの送信が許容される。 o has matching CA trust policy governing the current negotiation, and ネゴシエーション中のCA trust policyに一致する。 o has at least one time-wise and usage-appropriate end-entity certificate chaining to a CA provided in the CERTREQ. CERTREQ内のCAに提供された使用可能なend-entity証明書チェーンがある。 Certificate revocation checking must be considered during the chaining process used to select a certificate. Note that even if two peers are configured to use two different CAs, cross-certification relationships should be supported by appropriate selection logic. 証明書の失効チェックは証明書を選択するために使用されるチェーン処理中に考慮されること。2つのpeerが2つの異なるCAを使うように構成されている場合、cross-certification relationshipがselection logicによってサポートされることに注意せよ。 The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out-of- band configured means. Thus, the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist, then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator). CERTREQの処理は、証明書の取得命令ではなく選択の提案としてみなされる。証明書が存在しない場合、CERTREQは無視される。これはprotocolエラー状態ではない。CERTREQのCAよりよいCAがあるが、代替が許容される場合がある（オペレーターが指定した場合）。 The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format). HTTP_CERT_LOOKUP_SUPPORTED notificationがCERTREQ payloadを含む任意のメッセージに含まれてよく、送信者がHTTP-based URLによる証明書のlook upができることを示す（つまり、その形式の証明書を受信することを望んでいる）。 3.8. Authentication Payload The Authentication payload, denoted AUTH in this document, contains data used for authentication purposes. The syntax of the Authentication data varies according to the Auth Method as specified below. Authentication payloadはAUTHと表記され、認証に使用されるデータが含まれる。Authentication dataの構文は下記に示すように認証方法によって異なる。 The Authentication payload is defined as follows Authentication payloadは下記のように定義される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Method | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 Authentication Payload Format o Auth Method (1 octet) - Specifies the method of authentication used. The types of signatures are listed here. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 使用される認証方法を規定する。署名の種類は下記の通り。この値はRFC4306のものである。最新の値は[IKEV2IANA]を参照。 Mechanism Value ----------------------------------------------------------------- RSA Digital Signature 1 Computed as specified in Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] (implementers should note that IKEv1 used a different method for RSA signatures). To promote interoperability, implementations that support this type SHOULD support signatures that use SHA-1 as the hash function and SHOULD use SHA-1 as the default hash function when generating signatures. Implementations can use the certificates received from a given peer as a hint for selecting a mutually understood hash function for the AUTH payload signature. [PKCS1]で規定されたRSASSA-PKCS1-v1_5 signature schemeのRSA秘密鍵を使用してSection 2.15で規定された方法で計算される。（実装は、IKEv1ではRSA signatureのために別のmethodを使用したことに注意せよ。） 相互運用性の保証のため、このタイプの署名をサポートする実装では、ハッシュ関数としてSHA-1を使用してsignatureを生成するときはデフォルトのハッシュ関数としてSHA-1を使用するsignatureをサポートすること。実装は、相互にAUTH payload署名のハッシュ関数を特定し、選択するためにpeerから受信した証明書を使用できる。 Note, however, that the hash algorithm used in the AUTH payload signature doesn t have to be the same as any hash algorithm(s) used in the certificate(s). AUTH paylaodのsignatureに使用されるハッシュアルゴリズムは証明書で使用されるハッシュアルゴリズムと同じである必要はない。 Shared Key Message Integrity Code 2 Computed as specified in Section 2.15 using the shared key associated with the identity in the ID payload and the negotiated PRF. ID payloadのidentityと関連付けられるshared keyとネゴシエーションされたPRFを使用し、Section 2.15で規定された方法で計算される。 DSS Digital Signature 3 Computed as specified in Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash. SHA-1ハッシュのDSS秘密鍵を使用してSection 2.15の方法で計算される。([DSS]参照) o Authentication Data (variable length) - see Section 2.15. Section 2.15参照。 The payload type for the Authentication payload is thirty-nine (39). Authentication payloadのpayload typeは39である。 3.9. Nonce Payload The Nonce payload, denoted as Ni and Nr in this document for the initiator s and responder s nonce, respectively, contains random data used to guarantee liveness during an exchange and protect against replay attacks. Nonce payloadはNi/Nrと表現され、replay攻撃に対する保護のためと、echangeの間の生存性を保証するためのランダムデータを含む。 The Nonce payload is defined as follows Nonce payloadは下記のように定義される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 Nonce Payload Format o Nonce Data (variable length) - Contains the random data generated by the transmitting entity. 送信エンティティによって生成されたランダムデータが含まれる。 The payload type for the Nonce payload is forty (40). Nonce payloadのpayload typeは40である。 The size of the Nonce Data MUST be between 16 and 256 octets, inclusive. Nonce values MUST NOT be reused. Nonce Dataは16～256オクテットであること。Nonce valueは再利用しないこと。 3.10. Notify Payload The Notify payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL Exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request. Notify payload（Nと表記される）はIKE peerにエラー状態や状態遷移などの情報データを送信するために使用される。Notify payloadは応答メッセージ(通常はrequestを拒否した理由を示す)、INFORMATIONAL Exchange(IKE requestでないエラーの報告)、送信者の機能、requestの意味(meaning)の変更に使用される。 The Notify payload is defined as follows Notify payloadは下記のように定義される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID | SPI Size | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Security Parameter Index (SPI) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Notification Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16 Notify Payload Format o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. このnotificationがSPI fieldで示されるSPIをもつ既存のSAに関係する場合、このfiledはSAの種類を示す。Child SAに関するnotificationの場合、このfiledはAH(2)かESP(3)であること。このドキュメントで定義されたnotificationの中で、SPIはINVALID_SELECTORS、REKEY_SAにのみ含まれる。SPI filedが空の場合、このfiledは0で送信され、受信者はそれを無視すること。 o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty. IPsec protocol IDで定義されたSPIのオクテット長。SPIが有効でない場合は0。IKE SAに関するnotificationは、SPI Sizeは0であり、field（SPI field variable lengthのこと）は空であること。 o Notify Message Type (2 octets) - Specifies the type of notification message. notification messageのタイプを指定する。 o SPI (variable length) - Security Parameter Index. Security Parameter Index(SPI)。 o Notification Data (variable length) - Status or error data transmitted in addition to the Notify Message Type. Values for this field are type specific (see below). Statusまたはerror dataがNotify Message Typeに加えて送信される。このfieldの値はtypeによって決まる(下記参照)。 The payload type for the Notify payload is forty-one (41). Notify payloadのpaylaod typeは41である。
https://w.atwiki.jp/withoutborder/pages/99.html
基本情報 運用会社 西武鉄道 製造年 1969～1978年 引退 1995年 運用範囲 池袋～飯能・西武秩父、西武新宿～西武秩父 定員 クハ5500：56人モハ5000：72人 性能諸元 電気方式 直流1500V 架空電車線方式 最高速度 105km/h 制御装置 日立製MMC-HTB-20E 台車 クハ5500：FS-072モハ5000：FS-372 製造メーカー 西武所沢、日立笠戸 概要 5000系は西武鉄道初の有料特急用車両で、西武秩父線の開通と同時にデビューした。 「活気あふれる若者達」というテーマのもとに、側面の大きな窓、クリーム色に赤色のラインが映える明るいデザイン。 正面はセンターピラーで分れた2枚の大きな窓、その下にはステンレス製のシマ模様を配した飾り帯、中央には西武の社章を付けた。 ライト類は左右対称に前照灯2灯、尾灯1灯をまとめた角型のグリルを配置。 先頭から側面へ伸びる速度感のある赤い帯、その見た目から「レッドアロー」号の愛称で親しまれた。 登場時は4両編成が2編成のみで、1日最大4往復、多客期には2編成併結して8両編成で運転された。 1974年に新製された編成からは6両編成化され、後に4両編成にも2両追加されて、1976年には全て6両化され、特急列車も毎時運行された。 下回りは、同時期既に新性能電車として主力の101系と全く同じで、150kwモーターを搭載、平地から山地まで安定した走りを見せた。 内装 車両両端に扉を配置、扉間はオールクロスシート。当初は号車ごとにモケットの色を変えた回転式腰掛だったが、後に朱色の簡易リクライニングシートが導入され、最終的にはワインレッドのものになった。 シートピッチは930mm。当時の国鉄特急車より広くとられていた。余談だが後継の10000系にも、シートピッチの広さは受け継がれている。 飯能向き先頭車の妻側にトイレと、車内販売準備室が設けられた。 模型について このセットは登場初期の4両編成、アンテナの無い姿を再現したセット。正面に付くヘッドマークも後期の電照式でないものが付属している。 スカートを付属する併結仕様に交換することで、2編成併結した8両編成として走行を楽しむこともできる。 メーカ名 品番 製品名 軌間 縮尺 電源 購入場所・サイト 状態 金額 KATO 10-1323 西武鉄道5000系＜レッドアロー＞初期形4両セット 9mm 1/150 DC Models IMON 新品 約11,500円
https://w.atwiki.jp/hensei/pages/30.html
900番台 EH500-901 (東芝/04/03/10～) 貨 仙台 0番台 EH500-1 (東芝/00/03/01～) 貨 仙台 EH500-2 (東芝/00/03/04～) 貨 仙台 EH500-3 (東芝/00/03/28～) 貨 仙台 EH500-4 (東芝/00/04/24～) 貨 仙台 EH500-5 (東芝/00/05/26～) 貨 仙台 EH500-6 (東芝/00/10/24～) 貨 仙台 EH500-7 (東芝/00/11/23～) 貨 仙台 EH500-8 (東芝/00/12/23～) 貨 仙台 EH500-9 (東芝/01/01/29～) 貨 仙台 EH500-10 (東芝/01/08/21～) 貨 仙台 EH500-11 (東芝/01/08/21～) 貨 仙台 EH500-12 (東芝/01/11/12～) 貨 仙台 EH500-13 (東芝/02/01/16～) 貨 仙台 EH500-14 (東芝/02/03/11～) 貨 仙台 EH500-15 (東芝/02/04/26～) 貨 仙台 EH500-16 (東芝/02/06/04～) 貨 仙台 EH500-17 (東芝/02/07/02～) 貨 仙台 EH500-18 (東芝/02/09/01～) 貨 仙台 EH500-19 (東芝/02/10/11～) 貨 仙台 EH500-20 (東芝/02/11/21～) 貨 仙台 EH500-21 (東芝/03/02/13～) 貨 仙台 EH500-22 (東芝/03/05/10～) 貨 仙台 EH500-23 (東芝/03/06/07～) 貨 仙台 EH500-24 (東芝/03/07/12～) 貨 仙台 EH500-25 (東芝/03/09/12～) 貨 仙台 EH500-26 (東芝/03/11/06～) 貨 仙台 EH500-27 (東芝/04/04/21～) 貨 仙台 EH500-28 (東芝/04/06/25～) 貨 仙台 EH500-29 (東芝/04/08/10～) 貨 仙台 EH500-30 (東芝/04/09/28～) 貨 仙台 EH500-31 (東芝/04/11/10～) 貨 仙台 EH500-32 (東芝/05/05/20～) 貨 仙台 EH500-33 (東芝/05/06/10～) 貨 仙台 EH500-34 (東芝/05/07/26～) 貨 仙台 EH500-35 (東芝/05/09/07～) 貨 仙台 EH500-36 (東芝/05/10/12～) 貨 仙台 EH500-37 (東芝/05/11/10～) 貨 仙台 EH500-38 (東芝/05/12/06～) 貨 仙台 EH500-39 (東芝/05/12/26～) 貨 仙台 EH500-40 (東芝/06/01/25～) 貨 仙台 EH500-41 (東芝/06/06/22～) 貨 仙台 EH500-42 (東芝/06/07/26～) 貨 仙台 EH500-43 (東芝/06/08/09～) 貨 仙台 EH500-44 (東芝/06/08/29～) 貨 仙台 EH500-45 (東芝/06/09/13～) 貨 門司 EH500-46 (東芝/06/10/20～) 貨 門司 EH500-47 (東芝/06/11/10～) 貨 門司 EH500-48 (東芝/06/11/20～) 貨 門司 EH500-49 (東芝/06/12/11～) 貨 門司 EH500-50 (東芝/06/12/25～) 貨 門司 EH500-51 (東芝/07/05/17～) 貨 仙台 EH500-52 (東芝/07/06/28～) 貨 仙台 EH500-53 (東芝/07/07/19～) 貨 仙台 EH500-54 (東芝/07/08/23～) 貨 仙台 EH500-55 (東芝/07/09/20～) 貨 仙台 EH500-56 (東芝/07/10/11～) 貨 仙台 EH500-57 (東芝/07/11/01～) 貨 仙台 EH500-58 (東芝/07/11/29～) 貨 仙台 EH500-59 (東芝/07/12/20～) 貨 仙台 EH500-60 (東芝/08/08/21～) 貨 仙台 EH500-61 (東芝/08/09/22～) 貨 仙台 EH500-62 (東芝/08/10/27～) 貨 仙台 EH500-63 (東芝/09/03/27～) 貨 仙台 EH500-64 (東芝/09/05/14～) 貨 仙台 EH500-65 (東芝/09/07/30～) 貨 仙台
https://w.atwiki.jp/audiomatome/pages/82.html
外観 Features ハウジングに音響特性に優れた黒檀材を採用＊1。 ジョイント、フレームにはマグネシウム合金採用の軽量設計。 W5000専用設計のφ53mmドライバー。 ドライバーユニットの磁気回路にパーメンジュールを採用＊2。 OFC-8Nボビン巻きボイスコイル採用＊3。 D.A.D.S.(Double Air Damping System)機構で伸びのある低音を再生＊4。 ヘッドホンコードにOFC-6N＋Hi-OFCのハイブリッド線の4芯構造採用。 絡みにくい高弾性エラストマーシースの両出しYコード採用。 プラグには金属スリーブを使用したφ6.3標準プラグで音質重視設計。 イヤパッドはスペイン産ラムスキン採用で耐久性アップ。 圧迫感を軽減したトータルイヤフィット設計。 3D方式ウイングサポートで安定装着。 ハードケース付属で保管や持ち運びに便利。 ＊1 木材のなかで硬く重いため加工が難しい素材。高級な楽器などに使用されています。 ＊2 優れた磁気特性をもつ素材で一部のコンプレッションドライバーなどに採用されています。 ＊3 純度99.9999997％の無酸素銅：OFC-8N(通常の銅線は99.99%の4N) ＊4 二重構造のハウジングで空気のダンピング効果を高め、低音の伸びを改善します。 Spec 型式 密閉ダイナミック型 最大入力 2,000mW ハウジング 黒檀材 インピーダンス 40Ω 出力音圧レベル 102dB(JEITA) 質量 340g(コード除く) 再生周波数帯域 5～45,000Hz プラグ φ6.3金メッキステレオ標準 ドライバー φ53mm、OFC-8N ボビン巻きボイスコイル、 パーメンジュール採用磁気回路 コード(シース/素材/長) エラストマーシース/OFC-6N＋Hi-OFC/3.0m/4芯平行コード ●付属品 ハードケース、ケーブル収納用ポーチ ●別売 交換イヤパッド HP-W5000(税抜 ￥5,000.) 定価：120,750円 User s Comments Others 公式ホームページ： ATH-W5000 価格.com - ATH-W5000 Comments 名前 コメント
https://w.atwiki.jp/alternative_girls/pages/429.html
[ラビットハウス]桜子 前へ 次へ No.0500 蒼月 ★★ 最大Lv.50 [ラビットハウス]桜子 体力 404 素早さ 101 回避率 5 攻撃 124 命中率 100 クリ率 10 防御 153 特性 混乱耐性UP中 スキル名 スキル効果 Lv.UP効果 初期チャージ 最短チャージ Lスキル 防御UP 蒼月防御UP15% スキル1 ブラインハンマー 敵1体にダメージ 対象に暗闇を低確率で与える（3ターン） ダメージ量UP（小） 6 4 スキル2 ハイウィーク 敵1体の攻撃を中ダウンさせる（6ターン） 効果量UP（中） 6 4 スキル3 登場日 登場イベント/ガチャ 恒常入り 2016/12/21 ご注文はうさぎですか？？コラボガチャ? 限定ガチャ 専用ボイス シーン - ラウンジ - ラウンジ - 戦闘開始時 - Wave進行時 - 勝利時 洋服 小物 シャロのラビットハウス制服 シャロのヘアアクセサリー 前へ 次へ 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/kancolle/pages/1255.html
CV Illustrator 史実情報 台詞一覧 同型艦 コメント CV ？？？ Illustrator 絵師 史実情報 (史実の情報を記載) 台詞一覧 状況 台詞 関連する史実や元ネタ、解説など 自己紹介 秘書クリック会話① 秘書クリック会話② 秘書クリック会話③ 秘書クリック会話④ ケッコン後 戦績表示時 編成選択時 装備時① 装備時② 装備時③ （マップ選択･資材発見･修復剤使用･装備開発と装備時③は共通） 補給時 ドック入り ドック入り(重傷) 建造時 艦隊帰投時 出撃時 戦闘開始時 航空戦開始時 空母・水母のみ・夜戦攻撃時と同じ 攻撃時 夜戦開始時 夜戦攻撃時 空母以外・航空戦開始時と同じ MVP時 被弾時 被弾カットイン 撃沈時(反転) ケッコンカッコカリ + 未実装なら格納 時間 台詞 関連する史実や元ネタ、解説など 00 00 - 01 00 - 02 00 - 03 00 - 04 00 - 05 00 - 06 00 - 07 00 - 08 00 - 09 00 - 10 00 - 11 00 - 12 00 - 13 00 - 14 00 - 15 00 - 16 00 - 17 00 - 18 00 - 19 00 - 20 00 - 21 00 - 22 00 - 23 00 - 放置時 - 同型艦 呂500 ― 艦船情報テンプレ コメント 最新の30コメントを表示しています。 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/code_matome/pages/39.html
2.9. Traffic Selector Negotiation When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a protect selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system s SPD is outside the scope of IKE, although some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3). RFC4301準拠のIPsecサブシステムはSecurity Policy Database(SPD)の protect selectorにマッチするIP packetを受信したら、サブシステムはそのパケットをIPsecで保護する。SAがまだ存在しない場合、それを作成するのはIKEである。システムがSPDを管理する方法はIKEのスコープ外であるが、いくつかの実装はIKEの実行によりSPDを更新する（シナリオの例はSection 1.1.3参照）。 Kaufman, et al. Standards Track [Page 40] RFC 5996 IKEv2bis September 2010 Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their SPD to their peers. These must be communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] uses the SADB_ACQUIRE message). TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA. This can serve as a consistency check in some scenarios to assure that the SPDs are consistent. In others, it guides the dynamic update of the SPD. Traffic Selector(TS) payloadはendpointがpeerに自分のSPDの情報伝達することを可能とする。これらはSPDからIKEに伝えられること（例えばPF_KEY APIのSADB_ACQUIRE messageを使って）。TS payloadは新しいSAで転送されるpacketの選択基準を規定する。SPDの一貫性とSPDの動的な更新が保証される。 Two TS payloads appear in each of the messages in the exchange that creates a Child SA pair. Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID. 2つのTS payloadがChild SAのpairを作成するmessage exchangeで現れる。各TS payloadには1つ以上のTraffic Selectorが含まれる。各Traffic Selectorはaddress range(IPv4 or IPv6)、port range、IP protocol IDで構成される。 The first of the two TS payloads is known as TSi (Traffic Selector- initiator). The second is known as TSr (Traffic Selector-responder). TSi specifies the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the Child SA pair. TSr specifies the destination address of the traffic forwarded to (or the source address of the traffic forwarded from) the responder of the Child SA pair. For example, if the original initiator requests the creation of a Child SA pair, and wishes to tunnel all traffic from subnet 198.51.100.* on the initiator s side to subnet 192.0.2.* on the responder s side, the initiator would include a single Traffic Selector in each TS payload. TSi would specify the address range (198.51.100.0 - 198.51.100.255) and TSr would specify the address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was acceptable to the responder, it would send identical TS payloads back. 最初のTS payloadはTSi(Traffic Selector-initiator)である。2つ目はTSr(Traffic Selector-responder)である。TSiはinitiatorのChild SAから受信するトラフィックのsource address、または送信するトラフィックのdestination addressを指定する。TSrはresponderのChild SAに送信するトラフィックのdestination address、または受信するsource addressを指定する。 例えば、original initiatorがChild SAの作成を要求し、tunnelはinitiator side 198.51.100.*、responder sideは192.0.2.*を希望する場合、initiatorは各TS payloadに1つのTraffic Selectorを指定する。TSiはaddress range(198.51.100.0 - 198.51.100.255)で指定され、TSrはaddress range(192.0.2.0 - 192.0.2.255)で指定される。responderがその提案を許容した場合、同一のTS payloadを返す。 IKEv2 allows the responder to choose a subset of the traffic proposed by the initiator. This could happen when the configurations of the two endpoints are being updated but only one end has received the new information. Since the two endpoints may be configured by different people, the incompatibility may persist for an extended period even in the absence of errors. It also allows for intentionally different configurations, as when one end is configured to tunnel all addresses and depends on the other end to have the up-to-date list. IKEv2ではinitiatorに提案されたtrafficのsubsetを選択することをresponderに許容する。これは2つのendpointで設定が更新され、片方でのみ新しい情報を受信したときに起こる可能性がある。2つのendpointが異なる人に設定される場合があるが、この不一致状態は問題なく継続する可能性がある。片方はtunnelにすべてのアドレスを設定し、もう片方のlist更新に依存するような構成も可能とする。 When the responder chooses a subset of the traffic proposed by the initiator, it narrows the Traffic Selectors to some subset of the initiator s proposal (provided the set does not become the null set). If the type of Traffic Selector proposed is unknown, the responder ignores that Traffic Selector, so that the unknown type is not returned in the narrowed set. responderがinitiatorから提案されたtrafficのsubsetを選択すると、initiatorの提案（null setではない）を狭くしたTraffic Selectorになる。提案されたTraffic Selectorが不明な場合、範囲を狭くしたsetを返さないようにするため、responderはTraffic Selectorを無視する。 Kaufman, et al. Standards Track [Page 41] RFC 5996 IKEv2bis September 2010 To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request. In the example, the initiator would include in TSi two Traffic Selectors the first containing the address range (198.51.100.43 - 198.51.100.43) and the source port and IP protocol from the packet and the second containing (198.51.100.0 - 198.51.100.255) with all ports and IP protocols. The initiator would similarly include two Traffic Selectors in TSr. If the initiator creates the Child SA pair not in response to an arriving packet, but rather, say, upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr can be ranges rather than specific values. このケースでresponderが適切な範囲を選択できるようにするため、initiatorがdata packetをSAに送信要求した場合、initiatorはTSiとTSrのTraffic Selectorとして、initiatorは特定のアドレスをTraffic Selectorに含める。 例えば、initiatorがTSiに2つのTraffic Selector、1つ目(198.51.100.43 - 198.51.100.43)とsource portとIP protocol、2つ目(198.51.100.0 - 198.51.100.255) と全てのportとIP protocol。initiarotは同じ2つTraffic Selector TSrを含むこととする。initiatorは2つのTraffic SelectorをTSiに含むこととする。initiatorが対向からのメッセージ無しにChild SAを作成する場合、起動時にはinitiatorのtunnelには特定のアドレスが無い場合がある。その場合はTSi/TSrの最初の値はその値としてよい。 The responder performs the narrowing as follows responderは下記のように範囲を狭める。 o If the responder s policy does not allow it to accept any part of the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE Notify message. responderのpolicyが提案されたTraffic Selectorの一部でも許可しない場合、TS_UNACCEPTABLE Notify messageを応答する。 o If the responder s policy allows the entire set of traffic covered by TSi and TSr, no narrowing is necessary, and the responder can return the same TSi and TSr values. responderのpolicyがTSiとTSrに完全に一致した場合、範囲を狭める必要はなく、responderは同じTSiとTSrを返す。 o If the responder s policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the Traffic Selectors to a subset that includes the initiator s first choices. In this example above, the responder might respond with TSi being (198.51.100.43 - 198.51.100.43) with all ports and IP protocols. responderのpolicyがTSiとTSrの最初のselectorを許容する場合、Traffic Selectorの範囲をinitiatorの最初の選択に狭める。例の場合、responderはTSi(198.51.100.43 - 198.51.100.43) with all ports and IP protocolを応答する。 o If the responder s policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. responderのpolicyが最初のTSiとTSrのselectorを許容しない場合、responderは許容するTSiとTSrのsubsetに狭める。 When narrowing is done, there may be several subsets that are acceptable but their union is not. In this case, the responder arbitrarily chooses one of them, and MAY include an ADDITIONAL_TS_POSSIBLE notification in the response. The ADDITIONAL_TS_POSSIBLE notification asserts that the responder narrowed the proposed Traffic Selectors but that other Traffic Selectors would also have been acceptable, though only in a separate SA. There is no data associated with this Notify type. This case will occur only when the initiator and responder are configured differently from one another. If the initiator and responder agree on the granularity of tunnels, the initiator will never request a tunnel wider than the responder will accept. 範囲狭めが行われる場合、いくつかのsubsetがあるが、それらはunion（和集合）でない可能性がある。その場合、responderはそれらの中の1つを選択し、応答にADDITIONAL_TS_POSSIBLE notificationを含めてよい。ADDITIONAL_TS_POSSIBLE notificationはresponderが提案されたTraffic Selectorを狭めたが、他のTraffic SelectorもそのSAで許容されることを示す。このNotfyに関連付けられるデータはない。このケースは、initiatorとresponderが異なる構成をされたときに発生する。initiatorとresponderがtunnelの設定で合意している場合、initiatorがresponderが許容するより広いtunnelを要求することはない。 Kaufman, et al. Standards Track [Page 42] RFC 5996 IKEv2bis September 2010 It is possible for the responder s policy to contain multiple smaller ranges, all encompassed by the initiator s Traffic Selector, and with the responder s policy being that each of those ranges should be sent over a different SA. Continuing the example above, the responder might have a policy of being willing to tunnel those addresses to and from the initiator, but might require that each address pair be on a separately negotiated Child SA. If the initiator didn t generate its request based on the packet, but (for example) upon startup, there would not be the very specific first Traffic Selectors helping the responder to select the correct range. There would be no way for the responder to determine which pair of addresses should be included in this tunnel, and it would have to make a guess or reject the request with a SINGLE_PAIR_REQUIRED Notify message. responderのpolicyに小さい複数のrangeを含むことができ、すべてinitiatorのTraffic Selectorに含まれ、responderのpolicyは異なるSAで送信される。上記例では、responderは希望のinitiatorとのtunnelのアドレスのpolocyを持っているかもしれないが、各アドレスのpairがそれぞれChild SAである必要がある。responderがtunnelに含まれるべきaddressを決めるための方法はないため、そのときはSINGLE_PAIR_REQUIRED Notify messageでrequestをrejectすること。 The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA request is unacceptable because its sender is only willing to accept Traffic Selectors specifying a single pair of addresses. The requestor is expected to respond by requesting an SA for only the specific traffic it is trying to forward. SINGLE_PAIR_REQUIRED errorは送信者が1つのアドレスのpairのTraffic Selectorのみを許容するため、CREATE_CHILD_SA requestを許容しないことを示す。requesterはforwardするtrafficのために、SAのrequestを応答することを期待する。 Few implementations will have policies that require separate SAs for each address pair. Because of this, if only some parts of the TSi and TSr proposed by the initiator are acceptable to the responder, responders SHOULD narrow the selectors to an acceptable subset rather than use SINGLE_PAIR_REQUIRED. 実装では、各アドレスのpairに別々のSAを必要とするpolicyがあってよい。そのため、initiatorから複数ペアのTSi/TSrが提案され、responderに許容される場合、responderはselectorの範囲を狭めるのではなく、SINGLE_PAIR_REQUIREDを使用すること。 2.9.1. Traffic Selectors Violating Own Policy When creating a new SA, the initiator needs to avoid proposing Traffic Selectors that violate its own policy. If this rule is not followed, valid traffic may be dropped. If you use decorrelated policies from [IPSECARCH], this kind of policy violations cannot happen. 新しいSAを作る際、initiatorは自分のpolicyに違反するTraffic Selectorを提案しないことが必要である。このルールに従わないと有効なtrafficがdropする可能性がある。[IPSECARCH]のポリシーを使用する場合はこのようなpolicy違反は起きない。 This is best illustrated by an example. Suppose that host A has a policy whose effect is that traffic to 198.51.100.66 is sent via host B encrypted using AES, and traffic to all other hosts in 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also that host B accepts any combination of AES and 3DES. これは例で示される。host Aはtraffic 198.51.100.66はhost Bを経由してAESで暗号化して送信する。他の198.51.100.0/24のhostへのtrafficは3DESで暗号化してhost B経由で送信する。host BはAES/3DESの任意の組み合わせを受け入れる。 If host A now proposes an SA that uses 3DES, and includes TSr containing (198.51.100.0-198.51.100.255), this will be accepted by host B. Now, host B can also use this SA to send traffic from 198.51.100.66, but those packets will be dropped by A since it requires the use of AES for this traffic. Even if host A creates a new SA only for 198.51.100.66 that uses AES, host B may freely continue to use the first SA for the traffic. In this situation, when proposing the SA, host A should have followed its own policy, and included a TSr containing ((198.51.100.0- 198.51.100.65),(198.51.100.67-198.51.100.255)) instead. host Aが3DES、TSr (198.51.100.0-198.51.100.255)の新しいSAを提案し、host Bが許容したとする。host BはこのSAで198.51.100.66からのtrafficを送信するが、Aでdropされる。なぜなら、そのtrafficはAESを使用する必要があるためである。host Aが198.51.100.66のためだけにAESの新しいSA作った場合でもhost Bはtrafficのために最初のSAを使用し続けてもよい。この場合、SAを提案したとき、host Aは下記のpolicyを維持し、TSrに下記を含める必要がある((198.51.100.0-198.51.100.65),(198.51.100.67-198.51.100.255)) 。 In general, if (1) the initiator makes a proposal for traffic X (TSi/TSr), do SA , and (2) for some subset X of X, the initiator does not actually accept traffic X with SA, and (3) the initiator would be willing to accept traffic X with some SA (!=SA), valid traffic can be unnecessarily dropped since the responder can apply either SA or SA to traffic X . 一般的に、(1)initiatorがSAにtraffic X（TSi/TSr）のproposalをした場合、 (2)Xのsubset X をinitiatorがSAでtraffic許容しない (3)initiatorがSA (!=SA)でtraffic X を許容する responderはtraffic X にSAかSA どちらでも適用することができるため、正当なtrafficがdropされる可能性がある。 2.10. Nonces The IKE_SA_INIT messages each contain a nonce. These nonces are used as inputs to cryptographic functions. The CREATE_CHILD_SA request and the CREATE_CHILD_SA response also contain nonces. These nonces are used to add freshness to the key derivation technique used to obtain keys for Child SA, and to ensure creation of strong pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated pseudorandom function (PRF). However, the initiator chooses the nonce before the outcome of the negotiation is known. Because of that, the nonce has to be long enough for all the PRFs being proposed. If the same random number source is used for both keys and nonces, care must be taken to ensure that the latter use does not compromise the former. IKE_SA_INITメッセージはそれぞれnonceを含む。nonceは暗号化への入力として使用される。CREATE_CHILD_SA requestとCREATE_CHILD_SA responseもnonceを含む。このnonceは新たなChild SA用のkey算出とDiffie-Hellman keyから安全な乱数を生成するために使用される。IKEv2のnonceはランダムに選択されること。サイズは128bit以上で、ネゴシエーションされたPRFの半分以上のキーサイズであること。ただし、ネゴシエーションの前にinitiatorがnonceを送信する。その際はサポートするPRFに対して十分な長さのnonceを選択すること。 2.11. Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses over which it runs. The IP addresses and ports in the outer header are, however, not themselves cryptographically protected, and IKE is designed to work even through Network Address Translation (NAT) boxes. An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. IKE functions identically over IPv4 or IPv6. IKEはUDP port 500/4500で動作し、同じIPアドレスでESP/AHも動作する。outer headerのIP addressとportはcryptographically protectされず、IKEはNAT box上でも動作するように設定されている。実装はsource portが500/4500でなくても受信を許容すること。また、そのaddress/portの要求に応答すること。responseのsource addressとportは受信したrequestに従って設定する。IKEはIPv4/IPv6で動作する。 2.12. Reuse of Diffie-Hellman Exponentials IKE generates keying material using an ephemeral Diffie-Hellman exchange in order to gain the property of perfect forward secrecy . This means that once a connection is closed and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the two endpoints cannot reconstruct the keys used to protect the conversation without doing a brute force search of the session key space. IKEはPFS（perfect forward secrecy）のためDiffie-Hellman鍵交換を使用して鍵を生成する。これは通信を傍受されても総当りでないと解読できないということである。 perfect forward secrecy：異なる暗号キーの対から生成したキーが、片方の暗号キーだけからは総当り以外で解読できないこと。 Achieving perfect forward secrecy requires that when a connection is closed, each endpoint MUST forget not only the keys used by the connection but also any information that could be used to recompute those keys. PFSの達成のためには接続が閉じられた時、接続で使用されたキーだけでなく再計算に使用する乱数なども消去する必要がある。 Because computing Diffie-Hellman exponentials is computationally expensive, an endpoint may find it advantageous to reuse those exponentials for multiple connection setups. There are several reasonable strategies for doing this. An endpoint could choose a new exponential only periodically though this could result in less-than- perfect forward secrecy if some connection lasts for less than the lifetime of the exponential. Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state. Diffie-Hellman exponentialsの計算は計算量が多いため、複数の接続setup時にDiffie-Hellman exponentialsを再利用してもよい。これにはいくつかの合理的理由がある。endpointはあるconnectionがexponentialのlifetimeより短いならばless-than-perfect forward secrecyとなるが、周期的に新しいexponetntialを選択することができる。また、exponentialは各connectionで使用されたのをトレースでき、関連するconnectionがcloseしたときに関連する情報が削除される。これにより、perfect forward secrecyを失うことなくexponentialを再利用することができる。 Whether and when to reuse Diffie-Hellman exponentials are private decisions in the sense that they will not affect interoperability. An implementation that reuses exponentials MAY choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the calculation. See [REUSE] for a security analysis of this practice and for additional security considerations when reusing ephemeral Diffie-Hellman keys. Diffie-Hellman exponentialを再利用するかどうかは相互運用性に影響はないので決定次第である。exponentialを再利用する実装は、計算を省略するため対向endpointの過去のexchangeで使用されたexponentialを記憶してよい。[REUSE]はephemeral Diffie-Hellman keyの再利用に関する議論とセキュリティ分析をしている。 2.13. Generating Keying Material In the context of the IKE SA, four cryptographic algorithms are negotiated an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF). The PRF is used for the construction of keying material for all of the cryptographic algorithms used in both the IKE SA and the Child SAs. IKE SAでは4つの暗号化アルゴリズムがネゴシエーションされる。 Encryption Algorithm、Integrity Protection Algorithm、Diffie-Hellman group、Pseudorandom funtion（PRF） PRFはIKE SA、Child SAのすべての暗号化アルゴリズムのkeying materialの生成に使用される。 We assume that each encryption algorithm and integrity protection algorithm uses a fixed-size key and that any randomly chosen value of that fixed size can serve as an appropriate key. For algorithms that accept a variable-length key, a fixed key size MUST be specified as part of the cryptographic transform negotiated (see Section 3.3.5 for the definition of the Key Length transform attribute). For algorithms for which not all values are valid keys (such as DES or 3DES with key parity), the algorithm by which keys are derived from arbitrary values MUST be specified by the cryptographic transform. encryption、integrity protectionはキー長が固定で、ランダムに選択されたその値がキーとして機能することを前提とする。可変長のキーを許容するアルゴリズムについては、固定キーサイズのtranfsormのネゴシエーションのときに規定すること（Section 3.3.5のKey Length transform attributeの定義参照）。全ての値がkeyにならないアルゴリズム（DESや3DESのkey parityなど）については、transformによって規定されること。 Kaufman, et al. Standards Track [Page 45] RFC 5996 IKEv2bis September 2010 For integrity protection functions based on Hashed Message Authentication Code (HMAC), the fixed key size is the size of the output of the underlying hash function. HMACにもとづくintegrity protectionは固定キーサイズがハッシュ関数の出力サイズになる。 It is assumed that PRFs accept keys of any length, but have a preferred key size. The preferred key size MUST be used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based on the HMAC construction, the preferred key size is equal to the length of the output of the underlying hash function. Other types of PRFs MUST specify their preferred key size. PRFは任意のキー長を許容するが、適切なkey長がある。適切なkey長はSK_d、SK_pi、SK_prに使用すること。HMACに基づくPRFはもとになるハッシュ関数の出力長に適切なkey長に等しい。他のPRFは適切なkey sizeを指定する必要がある。 Keying material will always be derived as the output of the negotiated PRF algorithm. Since the amount of keying material needed may be greater than the size of the output of the PRF, the PRF is used iteratively. The term prf+ describes a function that outputs a pseudorandom stream based on the inputs to a pseudorandom function called prf . keying materialはネゴシエーションされたPRFアルゴリズムの出力として導出される。key material sizeはPRFのサイズより大きくできるので、その場合はPRFを繰り返す。prf+はprfという擬似乱数関数(pseudorandom function)である。 In the following, | indicates concatenation. prf+ is defined as |は連結を表す。prf+は下記のように定義される。 prf+ (K,S) = T1 | T2 | T3 | T4 | ... where T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) ... This continues until all the material needed to compute all required keys has been output from prf+. The keys are taken from the output string without regard to boundaries (e.g., if the required keys are a 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC key, and the prf function generates 160 bits, the AES key will come from T1 and the beginning of T2, while the HMAC key will come from the rest of T2 and the beginning of T3). 必要なすべてのkeyのmaterialがprf+から出力されるまで続く。keyは境界に関係なく出力stringから取得される。 （key 256bitのAES key、160bit HMAC key、prf functionが160bitを生成する場合、AES keyはT1とT2、HMAC keyはT2とT3から計算される。） 256bit=32octet 160bit=20octet T1、T2、T3=20octet The constant concatenated to the end of each prf function is a single octet. The prf+ function is not defined beyond 255 times the size of the prf function output. prf+はprf関数の出力サイズの255倍を超えて定義しないこと。 2.14. Generating Keying Material for the IKE SA The shared keys are computed as follows. A quantity called SKEYSEED is calculated from the nonces exchanged during the IKE_SA_INIT exchange and the Diffie-Hellman shared secret established during that exchange. SKEYSEED is used to calculate seven other secrets SK_d used for deriving new keys for the Child SAs established with this IKE SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges; SK_ei and SK_er used for encrypting (and of course decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are used when generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr MUST be the preferred key length of the PRF agreed upon. shared keyは下記のように計算される。 SKEYSEEDはIKE_SA_INIT exchangeのnonceとDiffie-Hellmanで計算される。SKEYSEEDは7つのkeyを計算するために使用される。 SK_dはChild SAのkeyの計算に使う。 SK_ai、SK_arはIKE SA（Encrypted payload）の完全性保証の認証データ計算用のkey。 SK_ei、SK_erはIKE SA（Encrypted payload）の暗号化のkey。 SK_pi、SK_prはAuthentication payloadの生成に使用するkey。 SK_d、pi、prはネゴシエーションしたPRFの長さであること。 SKEYSEED and its derivatives are computed as follows SKEYSEEDと派生値は下記のように計算される。 SKEYSEED = prf(Ni | Nr, g^ir) {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr are taken in order from the generated bits of the prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman exchange. g^ir is represented as a string of octets in big endian order padded with zeros if necessary to make it the length of the modulus. Ni and Nr are the nonces, stripped of any headers. For historical backward-compatibility reasons, there are two PRFs that are treated specially in this calculation. If the negotiated PRF is AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], only the first 64 bits of Ni and the first 64 bits of Nr are used in calculating SKEYSEED, but all the bits are used for input to the prf+ function. SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_prはprf+で生成されるbitを順に取って作成される。 g^irはDiffie-Hellman鍵交換の共有秘密鍵。g^irはmodulusの長さにするため必要であれば0でpaddingしてビッグエンディアンのoctet文字として表現する。Ni/Nrはnonceで全てのheaderを取り除いたもの。下位互換のため、2つのPRFは特別な扱いで計算される。ネゴシエーションされたPRFがAES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128]の場合、Niの最初の64bitとNrの最初の64bitがSKEYSEEDの計算に使用され、すべてのbitがprf+の入力に使用される。 The two directions of traffic flow use different keys. The keys used to protect messages from the original initiator are SK_ai and SK_ei. The keys used to protect messages in the other direction are SK_ar and SK_er. 双方向のtrafficで異なる鍵が使われる。original initiatorからのmessageを保護するのはSK_ai/SK_eiである。逆方向からのmessageを保護するのはSK_ar/SK_erである。 2.15. Authentication of the IKE SA When not using extensible authentication (see Section 2.16), the peers are authenticated by having each sign (or MAC using a padded shared secret as the key, as described later in this section) a block of data. In these calculations, IDi and IDr are the entire ID payloads excluding the fixed header. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message (IKE_SA_INIT response) and end with the last octet of the last payload in the second message. Appended to this (for the purposes of computing the signature) are the initiator s nonce Ni (just the value, not the payload containing it), and the value prf(SK_pr, IDr ). Note that neither the nonce Ni nor the value prf(SK_pr, IDr ) are transmitted. Similarly, the initiator signs the first message (IKE_SA_INIT request), starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) are the responder s nonce Nr, and the value prf(SK_pi, IDi ). It is critical to the security of the exchange that each side sign the other side s nonce. EAP認証(Section 2.16参照)を使用しない場合、peerはそれぞれのデータブロックの署名（または後述するshared secret keyのMACをkeyとして使用して）によって認証をする。この計算にはID payloadの固定長ヘッダを除いたIDi /IDr が使用される。 Responderの場合、IKE_SA_INIT response(Message2)のヘッダの最初のSPI～最後のpayloadのoctetまでを署名する。署名するためinitiatorのnonce Ni（値だけでpaylaod全体は含まない）とprf(SK_pr、IDr)を結合する。Niとprf(SK_pr, IDr )のどちらかだけが送信されることに注意せよ。 同様にInitiatorはIKE_SA_INIT request(Message1)の最初のヘッダのSPI～最後のpayloadのoctetまでを署名する。署名するためresponderのnonce Nrとprf(SK_pi、IDi )を結合する。両側が相手のnonceで署名することがexchnageの機密性で重要である。 The initiator s signed octets can be described as initiatorの署名オクテットは下記で示される。 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload) The responder s signed octets can be described as responderの署名オクテットは下記で示される。 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfRespIDPayload RestOfRespIDPayload = IDType | RESERVED | RespIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload) Note that all of the payloads are included under the signature, including any payload types not defined in this document. If the first message of the exchange is sent multiple times (such as with a responder cookie and/or a different Diffie-Hellman group), it is the latest version of the message that is signed. このドキュメントに含まれないすべてのpayloadが署名に含まれることに注意せよ。exchnageの最初のメッセージが複数回送信される場合（responder cookieや異なるDiffie-Hellman group要求の場合）、最新（最後に送られた）のメッセージが署名に使用される。 Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload. The signature or MAC will be computed using algorithms dictated by the type of key used by the signer, and specified by the Auth Method field in the Authentication payload. There is no requirement that the initiator and responder sign with the same cryptographic algorithms. The choice of cryptographic algorithms depends on the type of key each has. In particular, the initiator may be using a shared key while the responder may have a public signature key and certificate. It will commonly be the case (but it is not required) that, if a shared secret is used for authentication, the same key is used in both directions. オプションでID payloadのディジタル署名の計算に使用される証明書、証明書 chainをmessage3、message4に含んでよい。署名またはMACはAuthentication payloadのAuth Method filedで指定されるアルゴリズムによって計算される。responderとinitiatorが同じ暗号アルゴリズムで署名をするという要件はない。暗号化アルゴリズムの選択はkey typeによって決まる。initiatorは共有鍵、responderは公開鍵と証明書となってもよい。必須ではないが、shared secretを認証に使用する場合は両方向で同じkeyを使用する。 Kaufman, et al. Standards Track [Page 48] RFC 5996 IKEv2bis September 2010 Note that it is a common but typically insecure practice to have a shared key derived solely from a user-chosen password without incorporating another source of randomness. This is typically insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method. (Applications using password-based authentication for bootstrapping and IKE SA should use the authentication method in Section 2.16, which is designed to prevent off-line dictionary attacks.) The pre- shared key needs to contain as much unpredictability as the strongest key being negotiated. In the case of a pre-shared key, the AUTH value is computed as 乱数を用いず、ユーザが選択したパスワードのみによるshared keyは危険であるということに注意すること。ユーザが選択したパスワードは辞書攻撃に対して安全ではない。off-line辞書攻撃を防ぐ認証方式はSection 2.16の認証方式を使用する必要がある。pre-shared keyは長いkeyがネゴシエーションされたときと同様の予測不可能正を含んでいる必要がある。pre-shared keyのAUTH valueは下記で計算される。 For the initiator AUTH = prf( prf(Shared Secret, Key Pad for IKEv2 ), ) For the responder AUTH = prf( prf(Shared Secret, Key Pad for IKEv2 ), ) where the string Key Pad for IKEv2 is 17 ASCII characters without null termination. The shared secret can be variable length. The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store the value prf(Shared Secret, Key Pad for IKEv2 ), which could not be used as a password equivalent for protocols other than IKEv2. As noted above, deriving the shared secret from a password is not secure. This construction is used because it is anticipated that people will do it anyway. The management interface by which the shared secret is provided MUST accept ASCII strings of at least 64 octets and MUST NOT add a null terminator before using them as shared secrets. It MUST also accept a hex encoding of the shared secret. The management interface MAY accept other encodings if the algorithm for translating the encoding to a binary string is specified. Key Pad for IKEv2 はnull終端なしの17文字 ASCII文字である。Shared secretは可変長である。shared secretがパスワードから導出される場合、IKEの実装は平文でパスワードを保存するのではなく、prf(Shared Secret, Key Pad for IKEv2 )として格納する。shared secretのため、management interfaceは少なくとも64 octetのnull終端を除いたASCII文字を許容すること。また、hexエンコーディングのshared secretを許容すること。バイナリ文字にエンコードするアルゴリズムが指定される場合、management interfaceはそれを許容してもよい。 There are two types of EAP authentication (described in Section 2.16), and each type uses different values in the AUTH computations shown above. If the EAP method is key-generating, substitute master session key (MSK) for the shared secret in the computation. For non-key-generating methods, substitute SK_pi and SK_pr, respectively, for the shared secret in the two AUTH computations. 2種類あるEAP authentication（Section 2.16参照）は上記と異なるAUTHを用いる。EAP methodがkey-generatingの場合はshared secretではなくmaster session key(MSK)を用いる。non-key-generating methodの場合は2つのAUTHの計算に使用するshared secretの代わりにSK_piとSK_prをそれぞれ用いる。 Kaufman, et al. Standards Track [Page 49] RFC 5996 IKEv2bis September 2010 2.16. Extensible Authentication Protocol Methods In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public-key-signature-based authentication of the responder to the initiator. These methods are often associated with mechanisms referred to as Legacy Authentication mechanisms. 公開鍵署名と共有鍵の認証に加え、IKEはRFC3748のEAPによる認証をサポートする。EAPは非対称（サーバがユーザを認証するために設計された）であり、対等ではない。EAPはinitiatorをresponderが認証するために使用され、公開鍵署名ベースの認証と組み合わせて使用されること。これらのmethodは Legacy Authentication mechanismに関連している。 While this document references [EAP] with the intent that new methods can be added in the future without updating this specification, some simpler variations are documented here. [EAP] defines an authentication protocol requiring a variable number of messages. Extensible Authentication is implemented in IKE as additional IKE_AUTH exchanges that MUST be completed in order to initialize the IKE SA. 新しいmethodは[EAP]に追加され、本ドキュメントでは単純なバリエーションのみ説明する。[EAP]は可変数のメッセージによる認証プロトコルを定義している。EAPはIKE SAを作成するために実行されるIKE_AUTH exchangeとしてIKEで実装される。 An initiator indicates a desire to use EAP by leaving out the AUTH payload from the first message in the IKE_AUTH exchange. (Note that the AUTH payload is required for non-EAP authentication, and is thus not marked as optional in the rest of this document.) By including an IDi payload but not an AUTH payload, the initiator has declared an identity but has not proven it. If the responder is willing to use an EAP method, it will place an Extensible Authentication Protocol (EAP) payload in the response of the IKE_AUTH exchange and defer sending SAr2, TSi, and TSr until initiator authentication is complete in a subsequent IKE_AUTH exchange. In the case of a minimal EAP method, the initial SA establishment will appear as follows initiatorはIKE_AUTH exchangeの最初のメッセージのAUTH payloadでEAPの使用要求を示す。AUTH paylaodは非EAP認証でも使用されるため、オプションとしては扱われないことに注意。IDiを含むがAUTH payloadを含まない場合、identityが認証されたことにはならない。respondeがEAPを使用すると決定した場合、IKE_AUTH exchangeにEAP paylaodで応じ、IKE_AUTH exchangeでinitiatorの認証が完了するまでSAr2、TSi、TSrの送信を続ける。最小のEAP手順では下記のようにSAが確立される。 Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni -- -- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} -- -- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} -- -- HDR, SK {EAP (success)} HDR, SK {AUTH} -- -- HDR, SK {AUTH, SAr2, TSi, TSr } Kaufman, et al. Standards Track [Page 50] RFC 5996 IKEv2bis September 2010 As described in Section 2.2, when EAP is used, each pair of IKE SA initial setup messages will have their message numbers incremented; the first pair of AUTH messages will have an ID of 1, the second will be 2, and so on. Section 2.2の通り、EAPを使用した場合、最初のAUTHメッセージのpairはmessage ID 1、次は2とmessage numberがインクリメントされる、 For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the initiator and responder to generate AUTH payloads in messages 7 and 8 using the syntax for shared secrets specified in Section 2.15. The shared key from EAP is the field from the EAP specification named MSK. This shared key generated during an IKE exchange MUST NOT be used for any other purpose. EAPでは認証のためshared keyが生成される。shared keyのsyntaxはSection 2.15で規定され、message 7と8のAUTH payloadから initiator/responder双方で生成され、使用される。EAPで共有されるキーはMSKという名前のEAPの仕様のものである。IKE exchangeで生成されたこのshared keyは他の目的では使用しないこと。 EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks [EAPMITM] if these EAP methods are used in other protocols that do not use a server-authenticated tunnel. Please see the Security Considerations section for more details. If EAP methods that do not generate a shared key are used, the AUTH payloads in messages 7 and 8 MUST be generated using SK_pi and SK_pr, respectively. shared keyを使用しないEAP methodは使用しないこと。server-authenticated tunnelを使用しないEAP methodを使用した場合、man-in-the-middle攻撃[EAPMITM]の対象となるため。詳細はSecurity Consideration section参照。shared keyを使用しないEAPを使用する場合、message7と8のAUTH payloadはSK_pi、SK_prから生成されること。 The initiator of an IKE SA using EAP needs to be capable of extending the initial protocol exchange to at least ten IKE_AUTH exchanges in the event the responder sends notification messages and/or retries the authentication prompt. Once the protocol exchange defined by the chosen EAP authentication method has successfully terminated, the responder MUST send an EAP payload containing the Success message. Similarly, if the authentication method has failed, the responder MUST send an EAP payload containing the Failure message. The responder MAY at any time terminate the IKE exchange by sending an EAP payload containing the Failure message. EAPを使用したIKE SAのinitiatorはresponderがリトライ/notification送信した場合、少なくとも10 IKE_AUTH exchange、initial protocol exchnageを延長できる必要がある。選択したEAP認証methodが成功した後、responderはEAP (success messageを含む)を送信する。同様に、認証methodが失敗した場合はresponderはEAP payload(failure messageを含む)を送信する。responderはいつでもEAP payload(failure messageを含む)によりIKE exchangeを終了できる。 Following such an extended exchange, the EAP AUTH payloads MUST be included in the two messages following the one containing the EAP Success message. 以下のようにEAP exchangeでは、EAP AUTH payloadは1つのEAP Success messageを含む2メッセージを送信すること。 When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity, if different from that in the IDi payload, has to be sent from the AAA server to the IKEv2 responder. initiatorがEAP認証を使用する場合、IDi payloadをAAAのルーティングと使用するEAP medhodの選択に使用してよい。IDiはEAPによって認証されるIDと異なってよい。policy、アクセス制御は実際にEAPで認証されたIDを用いること。多くの場合、EAPサーバはIKE responderと別のAAAサーバに実装される。認証されたIDがIDi payloadと異なる場合、認証されたIDはAAAサーバからIKEv2 responderに送信される。 Kaufman, et al. Standards Track [Page 51] RFC 5996 IKEv2bis September 2010 2.17. Generating Keying Material for Child SAs A single Child SA is created by the IKE_AUTH exchange, and additional Child SAs can optionally be created in CREATE_CHILD_SA exchanges. Keying material for them is generated as follows 一つのChild SAはIKE_AUTH exchangeで作成され、追加のChild SAはオプションでCREATE_CHILD_SA exchageで作成される。下記のようにkeying materialが作成される。 KEYMAT = prf+(SK_d, Ni | Nr) Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this request is the first Child SA created or the fresh Ni and Nr from the CREATE_CHILD_SA exchange if this is a subsequent creation. 最初のChild SAの場合はIKE_SA_INITのNi/Nrを使用し、追加のChild SAの場合はCREATE_CHILD_SAのNi/Nrが使用される。 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman exchange, the keying material is defined as オプションのDiffie-Hellman exchangeを含むCREATE_CHILD_SA exchnageは下記のように計算される。prf+は必要な鍵長になるまで繰り返される。 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) where g^ir (new) is the shared secret from the ephemeral Diffie- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros in the high-order bits if necessary to make it the length of the modulus). g^ir(new)はCREATE_CHILD_SA exchangeのDiffie-Hellman exchangeによる新しい共有秘密である。（必要なmodulus長にするため、必要ならば上位ビットを0で埋め、big endianでoctet stringで表される。） A single CHILD_SA negotiation may result in multiple Security Associations. ESP and AH SAs exist in pairs (one in each direction), so two SAs are created in a single Child SA negotiation for them. Furthermore, Child SA negotiation may include some future IPsec protocol(s) in addition to, or instead of, ESP or AH (for example, ROHC_INTEG as described in [ROHCV2]). In any case, keying material for each Child SA MUST be taken from the expanded KEYMAT using the following rules 1つのCHILD_SAネゴシエーションで複数のSAが作られる場合がある。ESP/AH SAはpait（各方向に1個ずつ）なので、単一のChild SAのネゴシエーションで2つのSAが作成される。さらに、Child SAネゴシエーションはEPS/AH以外に、今後の仕様を含められる(例えばROHC_INTEGなど)。いずれの場合もChild SAのkeying matrialは下記によりKEYMATから取得される。 o All keys for SAs carrying data from the initiator to the responder are taken before SAs going from the responder to the initiator. initiatorからresponderにデータを送信するための全てのkeyはresponderからinitiatorへのSAの前に作成される。 o If multiple IPsec protocols are negotiated, keying material for each Child SA is taken in the order in which the protocol headers will appear in the encapsulated packet. 複数のIPsecプロトコルがネゴシエーションされる場合、各Child SAのkeying materialはカプセル化されたprotocol headerの順に取り出される。 o If an IPsec protocol requires multiple keys, the order in which they are taken from the SA s keying material needs to be described in the protocol s specification. For ESP and AH, [IPSECARCH] defines the order, namely the encryption key (if any) MUST be taken from the first bits and the integrity key (if any) MUST be taken from the remaining bits. IPsec protocolが複数のキーを必要とする場合、keying materialを取得する順番はprotocolの仕様に記載される必要がある。ESP/AHは通常、encryption keyがあれば最初に取得し、integrity keyがあれば残ったbitから取得する。 Kaufman, et al. Standards Track [Page 52] RFC 5996 IKEv2bis September 2010 Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm, or negotiated in SA payloads (see Section 2.13 for description of key lengths, and Section 3.3.5 for the definition of the Key Length transform attribute). 各cryptographic algorithmはalgorithmで定義されるか、SA payloadでネゴシエーションされた固定bitのkeying materialを取得する。（Section 2.13にkeylengthの説明、Section 3.3.5にはKey Length transform attributeの説明を記載する。） 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA (see Sections 1.3.2 and 2.8). New initiator and responder SPIs are supplied in the SPI fields in the Proposal structures inside the Security Association (SA) payloads (not the SPI fields in the IKE header). The TS payloads are omitted when rekeying an IKE SA. SKEYSEED for the new IKE SA is computed using SK_d from the existing IKE SA as follows CREATE_CHILD_SA exchangeは既存のIKE SAのrekeyに使用される（Section 1.3.2、2.8参照）。新しいinitiator SPIとresponder SPIはIKE headerのSPI fieldでなく、SA payloadのProposalのSPI filedで提供される。IKE SAをrekeyするときTS payloadは省略される。新しいIKE SAのSKEYSEEDは下記のように既存のIKE SAのSK_dを使用して計算される。 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) where g^ir (new) is the shared secret from the ephemeral Diffie- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros if necessary to make it the length of the modulus) and Ni and Nr are the two nonces stripped of any headers. g^ir(new)はCREATE_CHILD_SA exchangeのDiffie-Hellman exchangeによる新しい共有秘密であり（必要なmodulus長にするため、必要ならば上位ビットを0で埋め、big endianでoctet stringで表される。）、Ni/Nrはheaderから取得された2つのnonceである The old and new IKE SA may have selected a different PRF. Because the rekeying exchange belongs to the old IKE SA, it is the old IKE SA s PRF that is used to generate SKEYSEED. 新旧のIKE SAが異なるPRFを選択してもよい。rekey exchangeは古いIKE SAで実施されるため、SKEYSEEDを生成するのに使用されるSAのPRFはold IKEである。 The main reason for rekeying the IKE SA is to ensure that the compromise of old keying material does not provide information about the current keys, or vice versa. Therefore, implementations MUST perform a new Diffie-Hellman exchange when rekeying the IKE SA. In other words, an initiator MUST NOT propose the value NONE for the Diffie-Hellman transform, and a responder MUST NOT accept such a proposal. This means that a successful exchange rekeying the IKE SA always includes the KEi/KEr payloads. IKE SAをrekeyする主な理由は、古いkeying materialが現在のkeyによって危殆化すること、またはその逆を防ぐためである。従って、実装はIKE SAのrekeyの場合、新しいDiffie-Hellman exchangeを実行すること。言い換えると、initiatorは NONE にしたDiffie-Hellman transformを提案しないこと。また、responderはそのようなproposalを許容しないこと。これは、IKE SAのrekayの成功したexchangeは常にKEi/KEr payloadを含むことを意味する。 The new IKE SA MUST reset its message counters to 0. 新しいIKE SAはmessage counterを0にリセットすること。 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new exchange, and using the new IKE SA s PRF. 新しいexchangeのSPIr、SPIr、Ni、Nrと新しいIKE SAのPRFが使われ、Section 2.14の方法でSK_d, SK_ai, SK_ar, SK_ei, and SK_erがSKEYSEEDが計算される。 2.19. Requesting an Internal Address on a Remote Network Most commonly occurring in the endpoint-to-security-gateway scenario, an endpoint may need an IP address in the network protected by the security gateway and may need to have that address dynamically assigned. A request for such a temporary address can be included in any request to create a Child SA (including the implicit request in message 3) by including a CP payload. Note, however, it is usual to only assign one IP address during the IKE_AUTH exchange. That address persists at least until the deletion of the IKE SA. endpoint-to-security-gatewayのシナリオでは保護されたネットワーク内のIPアドレスを動的に割り当てる必要になるシナリオが発生することが多い。一時的なアドレスの要求はCP payloadでChild SA作成の要求（message 3に含まれる）に含めることができる。IKE_AUTH exchangeで一つのアドレスのみを割り当てるのが一般的である。そのアドレスはIKE SAが削除されるまでは最低限、維持される。 This function provides address allocation to an IPsec Remote Access Client (IRAC) trying to tunnel into a network protected by an IPsec Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled address (and optionally other information concerning the protected network) in the IKE_AUTH exchange. The IRAS may procure an address for the IRAC from any number of sources such as a DHCP/BOOTP (Bootstrap Protocol) server or its own address pool. この機能はIPsecリモートアクセスサーバー(IRAS)によって、保護されたネットワークトンネルからのIPsecリモートアクセスクライアント(IRAC)へのアドレス割り当てを提供する。IKE_AUTH exchangeはIKE SAとChild SAを作成するため、IRACはIKE_AUTH exchangeでIRAC-controlled address（および保護されたネットワークに関するその他の情報（netmask等））を要求すること。 IRASはDHCP/BOOTP(Bootstrap Protocol)サーバーや独自のアドレスプールなどによりIRACにアドレスを割り当ててよい。 Initiator Responder ------------------------------------------------------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -- -- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr} In all cases, the CP payload MUST be inserted before the SA payload. In variations of the protocol where there are multiple IKE_AUTH exchanges, the CP payloads MUST be inserted in the messages containing the SA payloads. すべてのケースでCP payloadはSA payloadの前に設定されること、複数のIKE_AUTH exchangeを含む場合、CP payloadはSA payloadを含むメッセージの前に含まれること。 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but MAY contain any number of additional attributes the initiator wants returned in the response. CP(CFG_REQUEST)は少なくとも一つのINTERNAL_ADDRESS attributeを含むこと。それ以外にもinitiatorが応答で返送を必要とするattributeを含んでよい。 Kaufman, et al. Standards Track [Page 54] RFC 5996 IKEv2bis September 2010 For example, message from initiator to responder 例えば下記のメッセージがinitiatorからresponderに送信された場合。 CP(CFG_REQUEST)= INTERNAL_ADDRESS() TSi = (0, 0-65535,0.0.0.0-255.255.255.255) TSr = (0, 0-65535,0.0.0.0-255.255.255.255) NOTE Traffic Selectors contain (protocol, port range, address range). NOTE Traffic Selectorを含む。（protocol、portの範囲、addessの範囲） Message from responder to initiator resoonderからinitiatorへのメッセージ。 CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSr = (0, 0-65535,192.0.2.0-192.0.2.255) All returned values will be implementation dependent. As can be seen in the above example, the IRAS MAY also send other attributes that were not included in CP(CFG_REQUEST) and MAY ignore the non- mandatory attributes that it does not support. すべての戻り値は実装に依存する。上記の例のように、IRASはCP(CFG_REQUEST)に含まれていないattributeを送信してよいし、サポートしていないnon-mandatory attributeを無視してもよい。 The responder MUST NOT send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. responderはCP(CFG_REQUEST)をinitiatorから受信しない場合はCP(CFG_REPLY)を送信しないこと。IRASによる不要なlookupが必要ないように。 In the case where the IRAS s configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the Child SA creation to fail. The initiator can fix this by later starting a new Configuration payload request. There is no associated data in the FAILED_CP_REQUIRED error. IRASの設定がCPがIDi IRACの IRASの設定がCPがIDiのために使用されるが、IRACがCP(CFG_REQUEST)を送信するのに失敗した場合、IRASは要求に失敗し、Child SAの作成をFAILED_CP_REQUIREDを送信して終了する。FAILED_CP_REQUIREDはIKE SAに影響はない。Child SAの作成は失敗する。initiatorは後ほど新しいConfiguration payload requestを開始することで問題を解決する。FAILED_CP_REQUIREDにはデータは含まれない。 2.20. Requesting the Peer s Version An IKE peer wishing to inquire about the other peer s IKE software version information MAY use the method below. This is an example of a configuration request within an INFORMATIONAL exchange, after the IKE SA and first Child SA have been created. 対向peerのIKE SWバージョンを問い合わせる場合、IKEは下記の方法を使用してよい。IKE SAと最初のChild SAが作成された後にINFORMATIONAL exchangeで実施される例である。 Kaufman, et al. Standards Track [Page 55] RFC 5996 IKEv2bis September 2010 An IKE implementation MAY decline to give out version information prior to authentication or even after authentication in case some implementation is known to have some security weakness. In that case, it MUST either return an empty string or no CP payload if CP is not supported. IKEの実装では、実装にセキュリティの脆弱性があることがわかっている場合、バージョン情報を渡さなくてもよい。その場合、空の文字列を返すか、CPをサポートしていない場合はCP payloadを返さないこと。 Initiator Responder ------------------------------------------------------------------- HDR, SK{CP(CFG_REQUEST)} -- -- HDR, SK{CP(CFG_REPLY)} CP(CFG_REQUEST)= APPLICATION_VERSION( ) CP(CFG_REPLY) APPLICATION_VERSION( foobar v1.3beta, (c) Foo Bar Inc. ) 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. The general rule is that if a request is received that is badly formatted, or unacceptable for reasons of policy (such as no matching cryptographic algorithms), the response contains a Notify payload indicating the error. The decision whether or not to send such a response depends whether or not there is an authenticated IKE SA. IKE処理中には様々な種類のエラーが発生する。一般的には不正な形式、許容できないpolicy（マッチするcryptographic algorithmがない等）の要求を受信した場合、応答としてerrorを示すNotify payloadで返す。応答を送信するか否かの判断はIKE SAが存在するかに依存する。 If there is an error parsing or processing a response packet, the general rule is to not send back any error message because responses should not generate new requests (and a new request would be the only way to send back an error message). Such errors in parsing or processing response packets should still cause the recipient to clean up the IKE state (for example, by sending a Delete for a bad SA). パーサーエラー、応答パケットの処理エラーがあった場合の一般的ルールは、応答により新しいrequestを生成しないため、エラーメッセージを応答しないことである。パーサーエラーや応答パケット処理エラーなどでは受信者がIKE状態をクリーンアップするべきである（例えばbad SAのためにDeleteを送信する。）。 Only authentication failures (AUTHENTICATION_FAILED and EAP failure) and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a Delete payload. Other error conditions MAY require such an exchange if policy dictates that this is needed. If the exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED notification is not sent. 認証の失敗（AUTHENTICATION_FAILED and EAP failure）と不正なメッセージ形式（INVALID_SUNTAX）に限り、DELETE payloadを含むINFORMATIONAL exchange無しにIKE SAを削除する。その他のエラー条件によりpolicyで必要となった場合はexchangeが必要になる場合がある。exchangeがEAP Failureで終了する場合、AUTHENTICATION_FAILED notificationは送信されない。 2.21.1. Error Handling in IKE_SA_INIT Errors that occur before a cryptographically protected IKE SA is established need to be handled very carefully. There is a trade-off between wanting to help the peer to diagnose a problem and thus responding to the error and wanting to avoid being part of a DoS attack based on forged messages. 暗号で保護されたIKE SAが確立する前のエラーは注意して扱うべきである。peerの問題解析の手助けのための応答と、偽装メッセージによるDoS攻撃を防ぐことはトレードオフである。 Kaufman, et al. Standards Track [Page 56] RFC 5996 IKEv2bis September 2010 In an IKE_SA_INIT exchange, any error notification causes the exchange to fail. Note that some error notifications such as COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. Because all error notifications are completely unauthenticated, the recipient should continue trying for some time before giving up. The recipient should not immediately act based on the error notification unless corrective actions are defined in this specification, such as for COOKIE, INVALID_KE_PAYLOAD, and INVALID_MAJOR_VERSION. IKE_SA_INITでは様々なerror notificationによりexchangeが失敗する。 COOKIE、INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSIONなどのerror notificationは、以降のexchangeにより成功につながる可能しがあることに注意せよ。全てのerrorにおいて、認証は完了していないため、受信者はあきらめる前に何回かリトライしてよい。errorの受信者はしばらくリトライする。受信者はCOOKIE, INVALID_KE_PAYLOAD, and INVALID_MAJOR_VERSIONのようにerror notification後の動作が規定されていない場合、即座にerror notificationに対する動作をしないこと。 2.21.2. Error Handling in IKE_AUTH All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. Although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, that peer needs to treat the information with caution. 何らかの理由（無効な共有秘密、invalid ID、証明書の失効/期限切れなど）により認証失敗が発生したIKE_AUTH exchangeでは、すべてのエラーにAUTHENTICATION_FAILED notificationが通知される。responder側でエラーが発生した場合、notificationは保護され、通常はpayloadのみを含む（データは含まない）。IKE_AUTH messageはencrypted/integrity protectedされているが、この通知を受信したpeerが対向のpeerをまだ認証していない場合、peerはその情報を慎重に処理する必要がある。 If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is an exception for the general rule of not starting new exchanges based on errors in responses. initiatorでエラーが発生した場合は、INFORMATIONAL exchangeで他のpayload無しで分けて返されることがある。これはresponseのエラー時に新しいexchangeを開始してはいけれないルールの例外である。 Note, however, that request messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad payload contents), MUST be rejected in their entirety, and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification sent as a response. The receiver should not verify the payloads related to authentication in this case. request messageがunsupported critical payloadを含んでいる場合または全体のメッセージフォーマットが壊れている場合は、そのメッセージ自体をrejectし、UNSUPPORTED_CRITICAL_PAYLOAD Notification、INVALID_SYNTAX Notificationをそれぞれ返す。メッセージの受信者は認証関連のpaylaodを検証しないこと。 If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established; however, establishing the Child SA or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with authentication (IDr, CERT, and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. IKE_AUTHで認証が成功するとIKE SAが確立される。ただし、Child SAの確立またはconfiguration informationの要求が失敗する場合がある。この場合は自動的にIKE SAが削除されることはない。responderはそのようなerror notificationの送信をIKE_AUTH（IDr, CERT, AUTH）にpyggybackしてよい（FAILED_CP_REQUIRED、NO_PROPOSAL_CHOSENなど）。initiatorはそれによって認証を失敗としないこと。initiatorはpolicyによっては後でそのようなIKE SAを削除してもよい。 Kaufman, et al. Standards Track [Page 57] RFC 5996 IKEv2bis September 2010 In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened when processing a response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a Delete payload. Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them, such as by using the Vendor ID payload. IKE_AUTH exchange or （IKE_AUTHのresponse処理でエラー応答で発生した場合）それの直後のINFORMATIONAL exchangeでNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notificationが発生した場合のみ、Delete payload無しにIKE SAが削除されるor作成されない。 2.21.3. Error Handling after IKE SA is Authenticated After the IKE SA is authenticated, all requests having errors MUST result in a response notifying about the error. IKE SAが認証された後、エラーが発生したrequestにはエラーに関する通知のresponseが返されること。 In normal situations, there should not be cases where a valid response from one peer results in an error situation in the other peer, so there should not be any reason for a peer to send error messages to the other end except as a response. Because sending such error messages as an INFORMATIONAL exchange might lead to further errors that could cause loops, such errors SHOULD NOT be sent. If errors are seen that indicate that the peers do not have the same state, it might be good to delete the IKE SA to clean up state and start over. 通常は有効な応答としてエラーを期待してはいけない。INFORMATIONAL exchangeのようなエラーメッセージを送信するとエラーのループが発生する可能性があり、そのようなメッセージを送らないこと。エラーがpeerが同じ状態でないことを示している場合、IKE SAをクリーンアップするために削除してもよい。 If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit Delete payload. requestをパースするpeerがフォーマット異常（MACのチェックとwindowのチェック完了後）を検出し、INVALID_SYNTAX notificationを応答した場合、これは両方のpeerで致命的な問題であることを意味し、IKE SAをDelete payload無しに削除する。 2.21.4. Error Handling Outside IKE SA A node needs to limit the rate at which it will send messages in response to unprotected messages. ノードは保護されていない応答の送信メッセージrateを制限する必要がある。 If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and the message is not a request to start an IKE SA), this may be the result of a recent crash of the node. If the message is marked as a response, the node can audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node can audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from where it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain an INVALID_IKE_SPI Notify payload. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that the recipient has rebooted and forgotten the existence of an IKE SA. ノードがUDP port 500 or 4500でIKE SAのコンテキスト外(かつ、IKE SAの開始要求ではない)メッセージを受信した場合、これはノードのクラッシュの結果の可能性がある。メッセージが応答として認識される場合、ノードはそれをauditしてもよいが、応答してはいけない。メッセージが要求として認識される場合、ノードはそれをauditしてよく、応答してもよい。応答する場合、応答は同じIKE SPIとMessage IDでIPアドレスとポート宛に送信すること。応答は暗号化保護されず、INVALID_IKE_SPI Notify payloadを含むこと。INVALID_IKE_SPI notificationは認識できないIKEメッセージを宛先SPIで受信したことを示し、通常、受信者がリブートし、そのIKE SAを削除してしまったことを示す。 Kaufman, et al. Standards Track [Page 58] RFC 5996 IKEv2bis September 2010 A peer receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response that a genuine correspondent was tricked into sending. A node should treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a DoS attack. peerが保護されていないNotify payloadを受信した場合、応答せず、既存のSAの状態を変化させないこと。メッセージは偽造か応答メッセージが誤った可能性がある。ノードはそのようなメッセージ（ICMP destination unreachableなども）をSAの問題や、生存性チェック開始のためのヒントにするべきである。実装ではDoS攻撃にならないようにそのようなテストの頻度を制限すること。 If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. エラーがIKE requestのコンテキスト外（例：コンテキストがないSPIでESPメッセージを受信した場合）で発生した場合、ノードは問題内容のNotify payloadを含むINFORMATIONAL exchangeを開始すること。 A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA SHOULD send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions. IKE SAのIPアドレス（およびNAT traversalの場合はport）から怪しいメッセージを受信したnodeはSAでIKE Notify payloadを含むIKE INFORMATIONAL exchangeを送信すること。受信者はSAの状態を変えないこと、誤動作を検出するauditを実施してよい。 2.22. IPComp Use of IP Compression [IP-COMP] can be negotiated as part of the setup of a Child SA. While IP Compression involves an extra header in each packet and a compression parameter index (CPI), the virtual compression association has no life outside the ESP or AH SA that contains it. Compression associations disappear when the corresponding ESP or AH SA goes away. It is not explicitly mentioned in any Delete payload. IP Compressionの使用はChild SAのsetupの一部としてネゴシエーションできる。IP Compressionは各パケットに追加のheaderとcompression parameter index(CPI)が必要になるが、仮想的な compression association はそれを含むESP/AH SAのライフタイムの範囲外である。対応するESP/AH SAがなくなった時、compression associationも消える。compression associationの削除は明示的にDelete paylaodでは指定されない。 Negotiation of IP Compression is separate from the negotiation of cryptographic parameters associated with a Child SA. A node requesting a Child SA MAY advertise its support for one or more compression algorithms through one or more Notify payloads of type IPCOMP_SUPPORTED. This Notify message may be included only in a message containing an SA payload negotiating a Child SA and indicates a willingness by its sender to use IPComp on this SA. The response MAY indicate acceptance of a single compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT occur in messages that do not contain SA payloads. IP CompressionのネゴシエーションはChild SAの暗号パラメータ関連のネゴシエーションとは別のものである。Child SAを要求するnodeは1つ以上のIPCOMP_SUPPORTED typeのNotify payloadにより、1つ以上のcompression algorithを通知してもよい。このNotify messageはChild SAをネゴシエーションするSA payloadを含むメッセージにだけ含まれ、そのSAでIPCompを使うことを送信者が希望することを示す。応答は、type IPCOMP_SUPPORTEDのNotify payloadで1つの許容するcompression algorithmを示す。これらのpayloadはSA payloadが含まれないメッセージでは発生しないこと。 The data associated with this Notify message includes a two-octet IPComp CPI followed by a one-octet Transform ID optionally followed by attributes whose length and format are defined by that Transform ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED notifications to indicate multiple supported algorithms. A message accepting an SA may contain at most one. このNotify messageに関連付けられるデータは、2 octet のIPComp CPI、1 octetのTransform ID、オプションでTransform IDで定義されるattribute（length/format）を含んでいる。SAを提案するmessageは複数のアルゴリズムを示すため、複数のIPCOMP_SUPPORTED notificationを含んでよい。SAを許容するメッセージでは1つだけを含む。 Kaufman, et al. Standards Track [Page 59] RFC 5996 IKEv2bis September 2010 The Transform IDs are listed here. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Transform IDは下記に記載される。この値はRFC 4306発行時のものである。その他の値がその後追加されてもよい。[IKEV2IANA]の最新バージョンを参照せよ。 Name Number Defined In ------------------------------------- IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051 Although there has been discussion of allowing multiple compression algorithms to be accepted and to have different compression algorithms available for the two directions of a Child SA, implementations of this specification MUST NOT accept an IPComp algorithm that was not proposed, MUST NOT accept more than one, and MUST NOT compress using an algorithm other than one proposed and accepted in the setup of the Child SA. 複数のcompression algorithmを受け入れ、Child SAの2つの方向に異なるalgorithmを使用する議論がされいているが、この仕様の実装では提案されなかったIPComp algorithmを受け入れてはいけず、1つ以上を受け入れてはいけず、Child SAのsetup時に受け入れた1つのalgorithm以外を使用しないこと。 A side effect of separating the negotiation of IPComp from cryptographic parameters is that it is not possible to propose multiple cryptographic suites and propose IP Compression with some of them but not others. IPCompを暗号化パラメータのネゴシエーションと分離する副作用は、複数の暗号化suiteを提案し、IP Compressionをいくつかでは適用するが他では適用しないということができないことである。 In some cases, Robust Header Compression (ROHC) may be more appropriate than IP Compression. [ROHCV2] defines the use of ROHC with IKEv2 and IPsec. ケースによっては、Robust HEader Compression(ROHC)がIP Compressionより役に立つだろう。[ROHCV2]ではIKEv2とIPsecでのROCHの使用方法を定義している。 2.23. NAT Traversal Network Address Translation (NAT) gateways are a controversial subject. This section briefly describes what they are and how they are likely to act on IKE traffic. Many people believe that NATs are evil and that we should not design our protocols so as to make them work better. IKEv2 does specify some unintuitive processing rules in order that NATs are more likely to work. Network Address Translation(NAT) gatewayは議論すべき話題である。この章ではこれら(NAT gateway)がどのようにIKE trafficに影響するかを説明する。多くの人はNATはよいものではないので、NATを動作させるためにprotocolを設計するべきではないと信じている。IKEv2はNATが動作するようにいくつかの直感的ではない処理を規定している。 NATs exist primarily because of the shortage of IPv4 addresses, though there are other rationales. IP nodes that are behind a NAT have IP addresses that are not globally unique, but rather are assigned from some space that is unique within the network behind the NAT but that are likely to be reused by nodes behind other NATs. Generally, nodes behind NATs can communicate with other nodes behind the same NAT and with nodes with globally unique addresses, but not with nodes behind other NATs. There are exceptions to that rule. When those nodes make connections to nodes on the real Internet, the NAT gateway translates the IP source address to an address that will be routed back to the gateway. Messages to the gateway from the Internet have their destination addresses translated to the internal address that will route the packet to the correct endnode. 他の理由もあるが、NATはIPv4の不足により存在する。NAT配下のIP nodeはグローバル一意でないIPアドレスを持ち、そのアドレスはNAT配下では一意であり、しかしそのアドレスは他のNAT配下のノードで再利用される可能性がある。一般的には、NAT配下のnodeは同じNAT配下の他のnode、グローバル一意なアドレスのnodeと通信ができるが、他のNAT配下のnodeとは通信はできない。このルールには例外がある。これらのnodeがinternet上のnodeと通信をすると、NAT gatewayはsource IP addressをgatewayにルーティングされるアドレスに変換する。internetからgatewayへのメッセージはdestination addressを正しいendnodeへの内部アドレスを変換する。 NATs are designed to be transparent to endnodes. Neither software on the node behind the NAT nor the node on the Internet requires modification to communicate through the NAT. Achieving this transparency is more difficult with some protocols than with others. Protocols that include IP addresses of the endpoints within the payloads of the packet will fail unless the NAT gateway understands the protocol and modifies the internal references as well as those in the headers. Such knowledge is inherently unreliable, is a network layer violation, and often results in subtle problems. NATはendnodeに対して 透過 であるように設計されている。NAT配下のnodeのsoftwareかInternet上のnodeのどちらかはNATを介して通信するように変更する必要がある。この透過を実現することは、プロトコルによっては難しい。packetのpaylaodの中にendpointのIP addressを含むprotocolでは、NAT gatewayがprotocolを解釈してheaderと同様に内部情報を変更しないと問題が起こる。そのような情報を得ることは、信頼できず、ネットワーク層の違反であり、難しい問題である。 Opening an IPsec connection through a NAT introduces special problems. If the connection runs in transport mode, changing the IP addresses on packets will cause the checksums to fail and the NAT cannot correct the checksums because they are cryptographically protected. Even in tunnel mode, there are routing problems because transparently translating the addresses of AH and ESP packets requires special logic in the NAT and that logic is heuristic and unreliable in nature. For that reason, IKEv2 will use UDP encapsulation of IKE and ESP packets. This encoding is slightly less efficient but is easier for NATs to process. In addition, firewalls may be configured to pass UDP-encapsulated IPsec traffic but not plain, unencapsulated ESP/AH or vice versa. NATを通してIPsecをする場合の特殊な問題を紹介する。接続がtransport modeの場合、packetのIP addressの変更は、checksum NGになり、NATはcryptographically protectされているため、正しいchecksumに修正することができない。tunnel modeであっても、NATに透過的にAH/ESPのアドレスを変換する特殊なロジックが必要になり、そのロジックは信頼性がないなどするためルーティングで問題になる。そのため、IKEv2ではIKE/ESP packetにUDP encapsulationを使用する。このencodingは非効率的だが、NATの処理よりは簡単である。それに加え、fairewallはUDP-encapsulated IPsec trafficをESP/AHのように透過させるように設定することができる。 It is a common practice of NATs to translate TCP and UDP port numbers as well as addresses and use the port numbers of inbound packets to decide which internal node should get a given packet. For this reason, even though IKE packets MUST be sent to and from UDP port 500 or 4500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. This is because the ports may be modified as the packets pass through NATs. Similarly, IP addresses of the IKE endpoints are generally not included in the IKE payloads because the payloads are cryptographically protected and could not be transparently modified by NATs. TCP/UDP port番号だけでなく、アドレスを変換し、内部nodeを決定するために受信パケットのport番号を使用するのはNATの一般的な手法である。そのため、IKE packetはUDP port 500か4500で送信されなければならないが、NATではあらゆるポートから受け取り、受信したポートに応答する必要がある。これは、packetがNATを通過させるためポートが変更されてもよいからである。同様に、payloadは暗号化保護されており、NATでは書き換えできないため、IKE endpointのIPアドレスはIKE payloadに含まれていない。 Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec endpoint that discovers a NAT between it and its correspondent (as described below) MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). Port4500はUDPカプセル化ESP/IKEのために予約されている。NATを発見したIPsec endpointはport 4500または500からのパケットを送受信する。 An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending ESP with UDP encapsulation is not required, but understanding received UDP-encapsulated ESP packets is required. UDP encapsulation MUST NOT be done on port 500. If Network Address Translation Traversal (NAT-T) is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP-encapsulated ESP and non-UDP-encapsulated ESP packets at any time. Either side can decide whether or not to use UDP encapsulation for ESP irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST use UDP encapsulation for ESP. IKEを開始するときinitiatorはIKE/ESPのためにNATの有無に関わらずport 4500を使用してよい。両方がport 4500を使用していて、ESP送信にUDPカプセル化を必要としない場合でもUDPカプセル化受信時に理解できることが必要である。UDPカプセル化はport 500では使用しないこと。NATはサポートされると（IKE_SA_INITでNAT_DETECTION_*_IP payloadが交換された場合）、すべてのデバイスは任意のタイミングでUDPカプセル化/UDP非カプセル化のESPパケットを受信し、処理できること。どちらがESPでUDPカプセル化をしたかに関わらず、どちら側もUDPカプセル化を使用してよい。しかし、NATを検知した場合は両方ともESPのためにUDPカプセル化を使用すること。 The specific requirements for supporting NAT traversal [NATREQ] are listed below. Support for NAT traversal is optional. In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal. NAT traversalをサポートするための仕様要求は下記のとおり[NATREQ]。NAT traversalのサポートはオプションである。この章に限り、要求はNAT traversalをサポートする実装にのみ適用される。 o Both the IKE initiator and responder MUST include in their IKE_SA_INIT packets Notify payloads of type NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect if there is NAT between the hosts, and which end is behind the NAT. The location of the payloads in the IKE_SA_INIT packets is just after the Ni and Nr payloads (before the optional CERTREQ payload). IKEのinitiator/responderはIKE_SA_INITのNotofy payloadにNAT_DETECTION_SOURCE_IP、NAT_DETECTION_DESTINATION_IPを含めること。これらのpayloadはhost間にNATがあり、endがNAT配下にあることを検出したときに使用される。payloadの場所はIKE_SA_INITのNi/Nr payloadの後ろでOptionのCERTREQ paylaodの前である。 o The data associated with the NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port from which this packet was sent. There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a message if the sender does not know which of several network attachments will be used to send the packet. NAT_DETECTION_SOURCE_IP notificationに関連付けられるデータはそのパケットのSPI（headerの順）、IP address、portの各SHA-1 digestである。送信者がどのネットワークを使用してパケットを送信されるか知らない場合、複数のNAT_DETECTION_SOURCE_IP payloadがあってもよい。 o The data associated with the NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port to which this packet was sent. NAT_DETECTION_DESTINATION_IP notificationに関連付けれられるデータはそのパケットのSPI（headerの順）、IP address、portの各SHA-1 digestである。 o The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source or recipient IP address (respectively), address, and port, and if they don t match, it SHOULD enable NAT traversal. In the case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject the connection attempt if NAT traversal is not supported. In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that the system receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT and that system SHOULD start sending keepalive packets as defined in [UDPENCAPS]; alternately, it MAY reject the connection attempt if NAT traversal is not supported. NAT_DETECTION_SOURCE_IPまたはNAT_DETECTION_DESTINATION_IP notificationのどちらかの受信者はSHA-1 hash of the SPIs, source or recipient IP addressを比較し、それらが一致しない場合はNAT traversalを有効にする必要がある。NAT traversalをサポートしていない場合にNAT_DETECTION_SOURCE_IP payloadの全てのNAT_DETECTION_SOURCE_IP hashが不一致の場合、受信者は接続を拒絶してもよい。 Kaufman, et al. Standards Track [Page 62] RFC 5996 IKEv2bis September 2010 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches the expected value of the source IP and port found from the IP header of the packet containing the payload, it means that the system sending those payloads is behind a NAT (i.e., someone along the route changed the source address of the original packet to match the address of the NAT box). In this case, the system receiving the payloads should allow dynamic updates of the other systems IP address, as described later. NAT_DETECTION_SOURCE_IP payload(s)を受信し、期待するsource IP、portがpayloadのIP headerと不一致の場合、そのpayloadを送信したsystemはNAT配下にある（すなわち、ルーティングのため、NAT boxのアドレスに一致されるため、元のパケットのsource addressを変更する。）。この場合、payloadを受信したsystemは他のsystemのIP addressの動的な更新を許容する必要がある。 o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP payloads if present, and if they do not match the addresses in the outer packet, MUST tunnel all future IKE and ESP packets associated with this IKE SA over UDP port 4500. IKE initiatorはNAT_DETECTION_SOURCE_IP、NAT_DETECTION_DESTINATION_IPが存在した場合は確認すること。また、Outer packetのアドレスと一致しなかった場合、IKE SAに関連付けられるIKE/ESP packetをUDP port 4500でトンネリングする。 o To tunnel IKE packets over UDP port 4500, the IKE header has four octets of zero prepended and the result immediately follows the UDP header. To tunnel ESP packets over UDP port 4500, the ESP header immediately follows the UDP header. Since the first four octets of the ESP header contain the SPI, and the SPI cannot validly be zero, it is always possible to distinguish ESP and IKE messages. UDP port 4500でIKE packetをトンネルするために、IKE headerは4 octetの0 paddingがあり、その後、UDP headerが続く。UDP port 4500でESP packetをトンネルするために、ESP headerの後にUDP headerが続く。ESP headerの最初の4 octetはSPIで、SPIは0にすることはできないため、常にESP messageとIKE messageを区別できる。 o Implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected. 実装は、NATを検出していなかった場合でもUDPカプセル化ESPを処理すること。 o The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the Traffic Selectors associated with the exchange. In the case of transport mode NAT traversal, the Traffic Selectors MUST contain exactly one IP address, which is then used as the original IP address. This is covered in greater detail in Section 2.23.1. Transport modeのTCP、UDP packetのチェックサム計算([UDPENCAPS])に必要な元のsource/destication IP addressはexchangeによるTraffic Selectorから得られる。Transport modeのNAT traversalでは、Traffic Selectorは元のIP addressとして1つだけ含まれていること。これはSection 2.23.1に詳細が書かれている。 o There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). This will be apparent to a host if it receives a packet whose integrity protection validates, but has a different port, address, or both from the one that was associated with the SA in the validated packet. When such a validated packet is found, a host that does not support other methods of recovery such as IKEv2 Mobility and Multihoming (MOBIKE) [MOBIKE], and that is not behind a NAT, SHOULD send all packets (including retransmission packets) to the IP address and port in the validated packet, and SHOULD store this as the new address and port combination for the SA (that is, they SHOULD dynamically update the address). A host behind a NAT SHOULD NOT do this type of dynamic address update if a validated packet has different port and/or address values because it opens a possible DoS attack (such as allowing an attacker to break the connection with a single packet). Also, dynamic address update should only be done in response to a new packet; otherwise, an attacker can revert the addresses with old replayed packets. Because of this, dynamic updates can only be done safely if replay protection is enabled. When IKEv2 is used with MOBIKE, dynamically updating the addresses described above interferes with MOBIKE s way of recovering from the same situation. See Section 3.8 of [MOBIKE] for more information. NAT boxがまだ使用中のマッピングリストを削除する場合がある（例えば、keepalive intervalが長すぎる場合（無通信だがkeepしている場合。）やNAT boxがリブートした場合）。integrity protection検証をするパケットを受信したが、異なるportまたはaddressがSAの検証パケットに設定されている場合、これはhostにとって明らかである。このような検証パケットが検出されると、IKEv2 MobilityとMultihoming(MOBIKE)のようなリカバリー方法をサポートしておらず、NAT配下にないhostは、すべてのパケット(再送パケットを含む)をそのIP addressに送信し、SAのために新しいaddressとportの組み合わせを保存すること（つまり、addressを動的に更新すること）。NAT配下のhostは異なるport/addressの検証パケットの場合に動的アドレス更新をしないこと。それは、DoS攻撃になるためである（攻撃者は1パケットでコネクションを切断することができる。）。また、動的アドレス更新は新しいパケットの応答としてのみ実行されること。そうでないと、攻撃者は古い再送パケットでアドレスを戻すことができる。再送保護(replay protection)が有効な場合、動的アドレス更新を安全に行うことができる。IKEv2でMOBIKEを使用する場合、動的アドレス更新は、同じような状況からの復旧とMOBIKEに干渉する。詳細はSection 3.8の[MOBIKE]参照。 2.23.1. Transport Mode NAT Traversal Transport mode used with NAT Traversal requires special handling of the Traffic Selectors used in the IKEv2. The complete scenario looks like NAT Traversalで使用されるTransport modeは、IKEv2で使用されるTraffic Selectorの特別な処理を必要とする。完全なシナリオは下記のようになる。 +------+ +------+ +------+ +------+ |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| |node | ------ | A | ---------- | B | ------- | | +------+ +------+ +------+ +------+ (Other scenarios are simplifications of this complex case, so this discussion uses the complete scenario.) 他のシナリオはこのシナリオを単純化したケースなので、この完全なシナリオで議論する。 In this scenario, there are two address translating NATs NAT A and NAT B. NAT A is a dynamic NAT that maps the client s source address IP1 to IPN1. NAT B is a static NAT configured so that connections coming to IPN2 address are mapped to the gateway s address IP2, that is, IPN2 destination address is mapped to IP2. This allows the client to connect to a server by connecting to the IPN2. NAT B does not necessarily need to be a static NAT, but the client needs to know how to connect to the server, and it can only do that if it somehow knows the outer address of the NAT B, that is, the IPN2 address. If NAT B is a static NAT, then its address can be configured to the client s configuration. Another option would be to find it using some other protocol (like DNS), but that is outside of scope of IKEv2. このシナリオでは、2つの、アドレス変換をするNATがある。NAT AとNAT Bである。 NAT Aはクライアントのsource address IP1をIPN1にマッピングする動的NAT(dynamic NAT)である。 NAT Bは静的NAT(static NAT)で、IPN2への通信をgatewayのaddress IP2にマッピングする。つまり、destination addressのIPN2をIP2にマッピングする。これは、クライアントがIPN2に接続することでserverに接続できることを可能にする。NAT Bは必ずしも静的NATである必要はないが、クライアントはserverに接続する方法を知っている必要があり、NAT BのアドレスIPN2 addressを知っていればよい。NAT Bが静的NATである場合、アドレスはクライアントの設定で設定することができる。その他のオプションとして、そのアドレスを他のプロトコル(DNSなど)を使用して発見することもできるが、IKEv2のスコープ外である。 In this scenario, both the client and server are configured to use transport mode for the traffic originating from the client node and destined to the server. このシナリオでは、クライアントとサーバーともに、クライアントから発信され、サーバー宛のトラフィックにtransport modeが設定される。 When the client starts creating the IKEv2 SA and Child SA for sending traffic to the server, it may have a triggering packet with source IP address of IP1, and a destination IP address of IPN2. Its Peer Authorization Database (PAD) and SPD needs to have a configuration matching those addresses (or wildcard entries covering them). クライアントからサーバーにトラフィックを送信するIKEv2 SAとChild SAの作成を開始するときは、source IP address IP1、destination IP address IPN2をパケットがもつ。Peer Authorization Database(PAD)とSPDはこれらのアドレスにマッチングする設定（またはそれらをカバーするワイルドカード設定）を持っている必要がある。 Kaufman, et al. Standards Track [Page 64] RFC 5996 IKEv2bis September 2010 Because this is transport mode, it uses exactly same addresses as the Traffic Selectors and outer IP address of the IKE packets. For transport mode, it MUST use exactly one IP address in the TSi and TSr payloads. It can have multiple Traffic Selectors if it has, for example, multiple port ranges that it wants to negotiate, but all TSi entries must use the IP1-IP1 range as the IP addresses, and all TSr entries must have the IPN2-IPN2 range as IP addresses. The first Traffic Selector of TSi and TSr SHOULD have very specific Traffic Selectors including protocol and port numbers, such as from the packet triggering the request. Transport modeのため、Traffic SelectorのaddressとIKE packetのouter IP addressは同じアドレスを使用する。Transport modeでは、TSi/TSr payloadに1つだけあるアドレスを使用する。複数のTraffic Selectorがあり、複数のportがネゴシエーションされる場合、TSiはIP1-IP1の範囲（IP1のみ）がIPアドレスとしてあり、TSrはIPN2-IPN2の範囲（IPN2のみ）がIPアドレスとしてある必要がある。このようなリクエストpacketをトリガにした場合、特殊なTraffic Selectorをもつ。 NAT A will then replace the source address of the IKE packet from IP1 to IPN1, and NAT B will replace the destination address of the IKE packet from IPN2 to IP2, so when the packet arrives to the server it will still have the exactly same Traffic Selectors that were sent by the client, but the IP address of the IKE packet has been replaced by IPN1 and IP2. NAT AはIKE packetのsource addressをIP1からIPN1に置き換える。NAT BはIKE packetのdestination addressをIPN2からIP2に置き換える。そのため、パケットがserverに届いたとき、クライアントから送信されたのと同じTraffic Selectorを持っているが、IKE packetのIP addressはIPN1とIP2に置き換えられている。 When the server receives this packet, it normally looks in the Peer Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based on the ID and then searches the SPD based on the Traffic Selectors. Because IP1 does not really mean anything to the server (it is the address client has behind the NAT), it is useless to do a lookup based on that if transport mode is used. On the other hand, the server cannot know whether transport mode is allowed by its policy before it finds the matching SPD entry. サーバーがこのパケットを受信すると、通常どおり、IDに基づいてRFC 4301[IPSECARCH]のPeer Authorization Database(PAD)で検索し、Traffic Selectorに基いてSPDを検索する。IP1はサーバーにとって意味のないアドレスのため（NAT配下のクライアントが持っているアドレスのため）、Transport modeの場合はそのアドレスに基いて検索することは意味が無い。一方、SPD entryでマッチングを見つける前に、サーバーはそのポリシーでTransport modeが許可されているか知ることができない。 In this case, the server should first check that the initiator requested transport mode, and then do address substitution on the Traffic Selectors. It needs to first store the old Traffic Selector IP addresses to be used later for the incremental checksum fixup (the IP address in the TSi can be stored as the original source address and the IP address in the TSr can be stored as the original destination address). After that, if the other end was detected as being behind a NAT, the server replaces the IP address in TSi payloads with the IP address obtained from the source address of the IKE packet received (that is, it replaces IP1 in TSi with IPN1). If the server s end was detected to be behind NAT, it replaces the IP address in the TSr payloads with the IP address obtained from the destination address of the IKE packet received (that is, it replaces IPN2 in TSr with IP2). この場合、serverは始めにinitiaotrがtransport modeであるか確認し、Traffic Selectorのアドレスを置換する必要がある。古いTraffic Selector IPはチェックサムを後で計算するために保存する必要がある（元のsource addressとして記憶されるTSiのIP addressと元のdestination addressとして記憶されるTSrがある）。そして、対向がNAT配下にあることが検出された場合、サーバーは受信したIKE packetのsource addressから取得したIP addressをTSi payloadのIP addressで置換する（つまり、IPN1をTSiのIP1で置換する）。サーバー側がNAT配下にあることを検出した場合、受信したIKE packetのdestination addressから取得したIP addressをTSr payloadのIP addressで置換する（つまりTSrのIPN2をIP2に置換する）。 After this address substitution, both the Traffic Selectors and the IKE UDP source/destination addresses look the same, and the server does SPD lookup based on those new Traffic Selectors. If an entry is found and it allows transport mode, then that entry is used. If an entry is found but it does not allow transport mode, then the server MAY undo the address substitution and redo the SPD lookup using the original Traffic Selectors. If the second lookup succeeds, the server will create an SA in tunnel mode using real Traffic Selectors sent by the other end. アドレス置換の後、Traffic SelectorとIKE UDP source/destination addressは同じに見え、serverは新しいTraffic SelectorをもとにSPDの検索をする。エントリが見つかり、それがTransport modeを許可する場合、そのエントリが使用される。エントリが見つかったが、transport modeが許可されていない場合、serverはアドレス置換を基に戻し、元のTraffic SelectorでSPDの検索をやり直してよい。2回目の検索で成功した場合、serverは対向から送信されたTraffic Selectorを使用してtunnel modeでSAを作成する。 This address substitution in transport mode is needed because the SPD is looked up using the addresses that will be seen by the local host. This also will make sure the Security Association Database (SAD) entries for the tunnel exit checks and return packets is added using the addresses as seen by the local operating system stack. SPDはlocal hostが認識するaddressで検索されるため、このアドレス置換はtransport modeで必要である。また、Security Association Database(SAD)を作成し、localアドレスを設定したパケットを応答する。 The most common case is that the server s SPD will contain wildcard entries matching any addresses, but this also allows making different SPD entries, for example, for different known NATs outer addresses. 最も一般的なケースは、サーバーのSPDがどのアドレスにもマッチするワイルドカードを含むが（例えば、既知の異なるNATのouter addressのため）異なるSPDエントリーの作成は許容される。 After the SPD lookup, the server will do Traffic Selector narrowing based on the SPD entry it found. It will again use the already substituted Traffic Selectors, and it will thus send back Traffic Selectors having IPN1 and IP2 as their IP addresses; it can still narrow down the protocol number or port ranges used by the Traffic Selectors. The SAD entry created for the Child SA will have the addresses as seen by the server, namely IPN1 and IP2. SPDの検索の後、サーバーはSPDエントリに基いてTraffic Selectorを狭める。これは、既に置換したTraffic Selectorを使用し、IPN1とIP2をもつTraffic Selectorとして送り返す。さらにTraffic Selectorが使用するprotocol number、port rangeも狭めることができる。serverからはChild SAのためのSADエントリはIPN1とIP2をもつことになる。 When the client receives the server s response to the Child SA, it will do similar processing. If the transport mode SA was created, the client can store the original returned Traffic Selectors as original source and destination addresses. It will replace the IP addresses in the Traffic Selectors with the ones from the IP header of the IKE packet it will replace IPN1 with IP1 and IP2 with IPN2. Then, it will use those Traffic Selectors when verifying the SA against sent Traffic Selectors, and when installing the SAD entry. クライアントはChild SAへのサーバーの応答を受信すると同様の処理をする。Transport modeのSAが作成されている場合、クライアントは元の返信されたsource/destination addressとして元のTraffic Selectorを保存する。IKE packetのIP headerからTraffic SelectorのIP addressに置換される。IPN1をIP1、IP2をIPN2に置換される。送信したTraffic Selectorに対するSAの検証するとき、SADエントリーを作成するときにTraffic Selectorを使用する。 A summary of the rules for NAT traversal in transport mode is Transport modeにおけるNAT traversalのルールのサマリは下記の通り、 For the client proposing transport mode クライアントがtransport modeを提案した場合、 - The TSi entries MUST have exactly one IP address, and that MUST match the source address of the IKE SA. TSiは厳密に1つだけIPアドレスを持ち、それはIKE SAのsource addressと一致すること。 - The TSr entries MUST have exactly one IP address, and that MUST match the destination address of the IKE SA. TSrは厳密に1つだけIPアドレスを持ち、それはIKE SAのdestination addressと一致すること。 - The first TSi and TSr Traffic Selectors SHOULD have very specific Traffic Selectors including protocol and port numbers, such as from the packet triggering the request. 最初のTSi/TSr Traffic Selectorは、リクエストのパケットのport/protocl 番号をもつ。 - There MAY be multiple TSi and TSr entries. 複数のTSi/TSrエントリがあってもよい。 Kaufman, et al. Standards Track [Page 66] RFC 5996 IKEv2bis September 2010 - If transport mode for the SA was selected (that is, if the server included USE_TRANSPORT_MODE notification in its response) SAにtransport modeが選択された場合。（すなわち、サーバーがUSE_TRANSPORT_MODE notificationを応答した場合） - Store the original Traffic Selectors as the received source and destination address. 受信したsource/destination addressとして元のTraffic Selectorを保存する。 - If the server is behind a NAT, substitute the IP address in the TSr entries with the remote address of the IKE SA. サーバーがNAT配下にある場合、IKE SAのremote addressでTSrエントリのIPアドレスを置き換える。 - If the client is behind a NAT, substitute the IP address in the TSi entries with the local address of the IKE SA. clidentがNAT配下にある場合、IKE SAのlocal addressでTSiエントリのIPアドレスを置き換える。 - Do address substitution before using those Traffic Selectors for anything other than storing original content of them. This includes verification that Traffic Selectors were narrowed correctly by the other end, creation of the SAD entry, and so on. 元の内容を保存する以外には、Traffic Selectorを使う前にaddressの置換をする。これには、Traffic Selectorが対向から狭められたことの確認、SADエントリの作成が含まれる。 For the responder, when transport mode is proposed by client クライアントがtransport modeを提案した場合、responderは、 - Store the original Traffic Selector IP addresses as received source and destination address, in case undo address substitution is needed, to use as the real source and destination address specified by [UDPENCAPS], and for TCP/UDP checksum fixup. [UDPENCAPS]の「real source and destination address」として使用するためとTCP/UDP checksumの計算のために、置換されたIP addressを戻す必要がある場合のために受信したsource/destination addressとして、元のTraffic Selector IP addressを保存する。 - If the client is behind a NAT, substitute the IP address in the TSi entries with the remote address of the IKE SA. clidentがNAT配下にある場合、IKE SAのremote addressでTSiエントリのIPアドレスを置き換える。 - If the server is behind a NAT, substitute the IP address in the TSr entries with the local address of the IKE SA. サーバーがNAT配下にある場合、IKE SAのlocal addressでTSrエントリのIPアドレスを置き換える。 - Do PAD and SPD lookup using the ID and substituted Traffic Selectors. IDを使用したPAD/SPDの検索とTraffic Selectorの置換をする。 - If no SPD entry was found, or if found SPD entry does not allow transport mode, undo the Traffic Selector substitutions. Do PAD and SPD lookup again using the ID and original Traffic Selectors, but also searching for tunnel mode SPD entry (that is, fall back to tunnel mode). SPDエントリが見つからない場合か、SDPエントリがtransport modeを許容していない場合、Traffic Selectorの置換を基に戻す。IDと元のTraffic SelectorによるPAD/SPDの検索、tunnel modeのSPDエントリを検索をする。すなわち、tunnel modeでのフォールバックをする。 - However, if a transport mode SPD entry was found, do normal traffic selection narrowing based on the substituted Traffic Selectors and SPD entry. Use the resulting Traffic Selectors when creating SAD entries, and when sending Traffic Selectors back to the client. transport modeのSPDエントリが見つかった場合、置換したTraffic SelectorとSPDエントリに基いてTraffic Selectionを狭める。SADエントリを作成し、clientにTraffic Selectorを送信するときは、その結果のTraffic Selectorを使用する。 Kaufman, et al. Standards Track [Page 67] RFC 5996 IKEv2bis September 2010 2.24. Explicit Congestion Notification (ECN) When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1- based IPsec requires multiple operating modes and negotiation (see [ECN]). IKEv2 simplifies this situation by requiring that ECN be usable in the outer IP headers of all tunnel mode Child SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel mode SAs created by IKEv2 MUST support the ECN full- functionality option for tunnels specified in [ECN] and MUST implement the tunnel encapsulation and decapsulation processing specified in [IPSECARCH] to prevent discarding of ECN congestion indications. IPsec tunnelが[IPSECARCH-OLD]で規定される動作をする場合、tunnel 非カプセル化処理はECNの輻輳通知を破棄するため、ECNを使用することはOuter IP headerには適していない。IKEv1ベースのIPsecのためのIPsec tunnelへのECNは、複数のoperation modeとnegotiationが必要である[ECN]。IKEv2では、ECNがIKEv2で作成される全てのtunnel mode Child SAのOuter IP headerで使用可能とすることで簡略化してある。具体的には、IKEv2で作成される全てのtunnel mode SAのtunnel カプセル化/非カプセル化では、[ECN]で規定されたECN full-functionality optionをサポートし、ECNの輻輳通知の廃棄を防ぐため、[IPSECARCH]で規定されたtuunel カプセル化/非カプセル化の処理を実装すること。 2.25. Exchange Collisions Because IKEv2 exchanges can be initiated by either peer, it is possible that two exchanges affecting the same SA partly overlap. This can lead to a situation where the SA state information is temporarily not synchronized, and a peer can receive a request that it cannot process in a normal fashion. IKEv2 exchangeはどちらのpeerからも開始できるので、同じSAに影響する2 exchangeが競合する可能性がある。これは、一時的なSAの同期状態が不一致が引き起こされ、peerは通常の方法で処理できないrequestを受信する可能性がある。 Obviously, using a window size greater than 1 leads to more complex situations, especially if requests are processed out of order. This section concentrates on problems that can arise even with a window size of 1, and recommends solutions. window sizeが1より大きい要求が順序通り処理されないとき問題はより複雑になる。このSectionではwindow size 1のときの推奨される解決方法について述べる。 A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives a request that cannot be completed due to a temporary condition such as a rekeying operation. When a peer receives a TEMPORARY_FAILURE notification, it MUST NOT immediately retry the operation; it MUST wait so that the sender may complete whatever operation caused the temporary condition. The recipient MAY retry the request one or more times over a period of several minutes. If a peer continues to receive TEMPORARY_FAILURE on the same IKE SA after several minutes, it SHOULD conclude that the state information is out of sync and close the IKE SA. peerがrekeyのような一時的な状態のため、完了できないrequestを受信した場合、TEMPORARY_FAILURE notificationを送信すること。peerがTEMPORARY_FAILURE notificationを受信した場合、operationを即座にリトライしないこと。送信者の操作が完了できるように待つこと。受信者はrequestを数分後に何度かリトライしてよい。peerが数分後に同じIEK SA上でTEMPORARY_FAILUREを受信し続けた場合、状態がsyncしていないということでIKE SAを削除すること。 A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify payload, which is copied from the SPI field in the REKEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA (if it still exists) and send a request to create a new Child SA from scratch (if the Child SA does not yet exist). peerが存在しないChild SAへのrekey requestを受信したときにCHILD_SA_NOT_FOUND notificationを送信すること。initiatorがrekeyを試行したSAは、REKEY_SA notificationのSPI fieldからコピーし、Notify payloadのSPI fieldで示される。peerがCHILD_SA_NOT_FOUND notificationを受信した場合、即座にそのChild SA（また存在する場合）を削除し、新しいChild SAを新規に作成するrequestを送信する（まだChild SAができていなかったら）。 Kaufman, et al. Standards Track [Page 68] RFC 5996 IKEv2bis September 2010 2.25.1. Collisions while Rekeying or Closing Child SAs If a peer receives a request to rekey a Child SA that it is currently trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer receives a request to rekey a Child SA that it is currently rekeying, it SHOULD reply as usual, and SHOULD prepare to close redundant SAs later based on the nonces (see Section 2.8.1). If a peer receives a request to rekey a Child SA that does not exist, it SHOULD reply with CHILD_SA_NOT_FOUND. peerは閉じようとしてるChild SAのrekey requestを受信した場合、TEMPORARY_FAILUREを応答すること。 peerはrekeyしているChild SAのrekey requestを受信した場合、正常に応答し、Section 2.8.1のnoncesに従って重複したSAを削除すること。存在しないChild SAへのrekey requestを受信したpeerはCHILD_SA_NOT_FOUNDを応答すること。 If a peer receives a request to close a Child SA that it is currently trying to close, it SHOULD reply without a Delete payload (see Section 1.4.1). If a peer receives a request to close a Child SA that it is currently rekeying, it SHOULD reply as usual, with a Delete payload. If a peer receives a request to close a Child SA that does not exist, it SHOULD reply without a Delete payload. peerは閉じようとしているChild SAのclose requestを受信した場合、Delete payload無しに応答すること（Section 1.4.1参照）。peerはrekayしているChild SAのclose requestを受信した場合、Delete payloadで応答すること。peerが存在しないChild SAのclose requestを受信した場合、Delete payload無しに応答すること。 If a peer receives a request to rekey the IKE SA, and it is currently creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD reply with TEMPORARY_FAILURE. peerがIKE SAをrekeyする要求を受信したとき、そのIKE SAのChild SAがcreating/rekeying/closingしている場合、TEMPORARY_FAILUREを応答すること。 2.25.2. Collisions while Rekeying or Closing IKE SAs If a peer receives a request to rekey an IKE SA that it is currently rekeying, it SHOULD reply as usual, and SHOULD prepare to close redundant SAs and move inherited Child SAs later based on the nonces (see Section 2.8.2). If a peer receives a request to rekey an IKE SA that it is currently trying to close, it SHOULD reply with TEMPORARY_FAILURE. peerがrekey中のIKE SAのrekey requestを受信した場合、通常通り応答し、nonceに基づき重複SAを削除し、Child SAを移動すること（Section 2.8.2参照）。peerが削除中のIKE SAのrekey requestを受信した場合、TEMPORARY_FAILUREを応答すること。 If a peer receives a request to close an IKE SA that it is currently rekeying, it SHOULD reply as usual, and forget about its own rekeying request. If a peer receives a request to close an IKE SA that it is currently trying to close, it SHOULD reply as usual, and forget about its own close request. peerがrekey中のIKE SAのclose requestを受信した場合、通常通り応答しrekey requestは忘れること。peerがclose中のIKE SAのclose requestを受信した場合、通常通り応答し自身のclose requestは忘れること。 If a peer receives a request to create or rekey a Child SA when it is currently rekeying the IKE SA, it SHOULD reply with TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA when it is currently rekeying the IKE SA, it SHOULD reply as usual, with a Delete payload. peerはrekey中のIKE SAでChild SAのcreate or rekeyのrequestを受信した場合、TEMPORARY_FAILUREを応答すること。peerがrekay中のIKE SAでChild SAのdeleteを受信した場合、通常通りDelete payloadで応答すること。 3. Header and Payload Formats In the tables in this section, some cryptographic primitives and configuration attributes are marked as UNSPECIFIED . These are items for which there are no known specifications and therefore interoperability is currently impossible. A future specification may describe their use, but until such specification is made, implementations SHOULD NOT attempt to use items marked as UNSPECIFIED in implementations that are meant to be interoperable. このSectionの表ではいくつかの暗号プリミティブとconfiguration attributeは UNSPECIFIED になっている。既存の仕様書にない項目なので相互運用は不可能である。今後の仕様ではそれらを使用してよいが、相互運用可能な実装では UNSPECIFIED の項目は使用しないこと。 3.1. The IKE Header IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. When sent on UDP port 500, IKE messages begin immediately following the UDP header. When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zeros are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. Each IKE message begins with the IKE header, denoted HDR in this document. Following the header are one or more IKE payloads each identified by a Next Payload field in the preceding payload. Payloads are identified in the order in which they appear in an IKE message by looking in the Next Payload field in the IKE header, and subsequently according to the Next Payload field in the IKE payload itself until a Next Payload field of zero indicates that no payloads follow. If a payload of type Encrypted is found, that payload is decrypted and its contents parsed as additional payloads. An Encrypted payload MUST be the last payload in a packet and an Encrypted payload MUST NOT contain another Encrypted payload. IKEメッセージはport 500/4500でUDP datagramで送信する。UDPヘッダの情報は、IPアドレスとUDP portが応答パケットに使用されることを除けば無視される。UDP port 500で送信する場合、IKEメッセージはUDPヘッダの直後に設定される。UDP port 4500で送信する場合、IKEメッセージはUDPヘッダの後の4オクテットの0の後に開始する。この0はIKEメッセージの一部ではないので、IKEのlength、checksumには含まれない。すべてのIKEメッセージはIKE headerで始まる。略記はHDR。 ヘッダの後には1つ以上の、 Next Payload filedで示されるIKE payloadがある。さらに次のpayloadがある場合は、そのpayloadの Next Payload filedで示され、 Next Payload filedが0の場合は次のPayloadがないことを示す。Encrypted payloadは解読され、追加のpayloadとして解析される。Encrypted paylaodは最後のpayloadであり、Encrypted payloadはEncrypted payloadを含まないこと。 The responder s SPI in the header identifies an instance of an IKE Security Association. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers, including multiple sessions per peer. ヘッダー内のresponder SPIはIKE Security Accosicationを識別する。これにより、peer毎にセッションを多重化することができる。 All multi-octet fields representing integers are laid out in big endian order (also known as most significant byte first , or network byte order ). 整数を表す複数オクテットのfieldはビッグエンディアン、ネットワークバイトオーダー、最上位バイトが最初である。 Kaufman, et al. Standards Track [Page 70] RFC 5996 IKEv2bis September 2010 The format of the IKE header is shown in Figure 4. IKE headerのフォーマットをFigure 4に示す。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKE SA Initiator s SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKE SA Responder s SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | MjVer | MnVer | Exchange Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 IKE Header Format o Initiator s SPI (8 octets) - A value chosen by the initiator to identify a unique IKE Security Association. This value MUST NOT be zero. IKE Security Associationを識別するため、initiatorによって選択された値。0であってはならない。 o Responder s SPI (8 octets) - A value chosen by the responder to identify a unique IKE Security Association. This value MUST be zero in the first message of an IKE initial exchange (including repeats of that message including a cookie). IKE Security Associationを識別するため、responderによって選択された値。IKE initial exchangeの最初のメッセージでは0であること(cookieを含むメッセージの繰り返しを含む。)。 o Next Payload (1 octet) - Indicates the type of payload that immediately follows the header. The format and value of each payload are defined below. headerの後に続くpayload typeを示す。各payloadのフォーマットと値を以下に示す。 o Major Version (4 bits) - Indicates the major version of the IKE protocol in use. Implementations based on this version of IKE MUST set the major version to 2. Implementations based on previous versions of IKE and ISAKMP MUST set the major version to 1. Implementations based on this version of IKE MUST reject or ignore messages containing a version number greater than 2 with an INVALID_MAJOR_VERSION notification message as described in Section 2.5. IKEのメジャーバージョンを示す。本ドキュメントに基づく実装はIKEはメジャーバージョン2。前のIKEバージョン、ISAKAMPはメジャーバージョン1。Section 2.5のとおり、2より大きいメジャーバージョンにはINVALID_MAJOR_VERSION notification messageを通知しメッセージを拒否するか、無視することすること。 o Minor Version (4 bits) - Indicates the minor version of the IKE protocol in use. Implementations based on this version of IKE MUST set the minor version to 0. They MUST ignore the minor version number of received messages. IKEのマイナーバージョンを示す。本ドキュメントに基づく実装のIKEはマイナーバージョン0を設定すること。受信したマイナーバージョンは無視すること。 Kaufman, et al. Standards Track [Page 71] RFC 5996 IKEv2bis September 2010 o Exchange Type (1 octet) - Indicates the type of exchange being used. This constrains the payloads sent in each message in an exchange. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. typeを示す。この値により送信するpayloadが制限される。下記の表はRFC4306発行時点の値である。今後、他の値が追加されるかもしれない。最新の値は[IKEV2IANA]参照。 Exchange Type Value ---------------------------------- IKE_SA_INIT 34 IKE_AUTH 35 CREATE_CHILD_SA 36 INFORMATIONAL 37 o Flags (1 octet) - Indicates specific options that are set for the message. Presence of options is indicated by the appropriate bit in the flags field being set. The bits are as follows メッセージに設定される特別なオプションを示す。オプションは下記のbitフィールドで示される。 +-+-+-+-+-+-+-+-+ |X|X|R|V|I|X|X|X| +-+-+-+-+-+-+-+-+ In the description below, a bit being set means its value is 1 , while cleared means its value is 0 . X bits MUST be cleared when sending and MUST be ignored on receipt. 下記の説明では、setは1、clearedは0を意味する。Xは送信時にclearedされること、また受信側では無視すること。 * R (Response) - This bit indicates that this message is a response to a message containing the same Message ID. This bit MUST be cleared in all request messages and MUST be set in all responses. An IKE endpoint MUST NOT generate a response to a message that is marked as being a response (with one exception; see Section 2.21.2). このメッセージが同じMessage IDの応答であることを示す。このビットはrequest messageではclearedし、response messageではsetすること。IKEエンドポイントはresponseに対してresponseを生成しないこと。(例外はSection 2.21.2参照) * V (Version) - This bit indicates that the transmitter is capable of speaking a higher major version number of the protocol than the one indicated in the major version number field. Implementations of IKEv2 MUST clear this bit when sending and MUST ignore it in incoming messages. 送信者がmejaor version number fieldの番号より高いメジャーバージョンを使用できることを示す。IKEv2の実装では送信側はこのビットをclearedし、受信側はこれを無視すること。 * I (Initiator) - This bit MUST be set in messages sent by the original initiator of the IKE SA and MUST be cleared in messages sent by the original responder. It is used by the recipient to determine which eight octets of the SPI were generated by the recipient. This bit changes to reflect who initiated the last rekey of the IKE SA. IKE SAのinitiatorによりsetして送信され、responderが送信するときclearedされること。受信者に、受信者によって8ビットのSPIが生成されたかを判断するために使用される。IKE SA rekeyをした場合、rekeyを開始したユーザがinitiatorになる。 Kaufman, et al. Standards Track [Page 72] RFC 5996 IKEv2bis September 2010 o Message ID (4 octets, unsigned integer) - Message identifier used to control retransmission of lost packets and matching of requests and responses. It is essential to the security of the protocol because it is used to prevent message replay attacks. See Sections 2.1 and 2.2. 損失パケットの再送および要求/応答のメッセージのマッチングのために使用される。メッセージリプレイ攻撃を防ぐために不可欠。詳細はSection 2.1、2.2参照。 o Length (4 octets, unsigned integer) - Length of the total message (header + payloads) in octets. メッセージ(header+payload)のオクテット長。 3.2. Generic Payload Header Each IKE payload defined in Sections 3.3 through 3.16 begins with a generic payload header, shown in Figure 5. Figures for each payload below will include the generic payload header, but for brevity, the description of each field will be omitted. Section 3.3～Section 3.16で定義されたIKE payloadはFigure 5のgeneric payload headerではじまる。各payloadの図にはgeneric paylaodが含まれるが、記載の簡略化のため説明は省略する。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Generic Payload Header The Generic Payload Header fields are defined as follows Generic Payload Header filedは下記のように定義される。 o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides a chaining capability whereby additional payloads can be added to a message by appending each one to the end of the message and setting the Next Payload field of the preceding payload to indicate the new payload s type. An Encrypted payload, which must always be the last payload of a message, is an exception. It contains data structures in the format of additional payloads. In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload (instead of 0); conversely, the Next Payload field of the last contained payload is set to zero). The payload type values are listed here. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 次のpayload typeの識別子。このpaylodaが最後の場合、値は0になる。追加のpayloadを Next Payload に設定することでpayloadを繋げるchainingの機能を提供する。 Encrypted payloadは必ず最後のpayloadになる。これには追加のpayloadのデータ構造を含んでいる。Encrypted payloadのヘッダーのNext Payload fieldには最初に含まれるpayloadのpaylaod typeが設定される(0ではない)。そして、最後のpayloadのNext Payload fieldは0が設定される。（Encrypted paylaodの中には暗号化されたpayloadが続く的な意味。） Payload typeを下記に示す。下記はRFC4306発行時点のものである。最新の値は[IKEV2IANA]参照。 Kaufman, et al. Standards Track [Page 73] RFC 5996 IKEv2bis September 2010 Next Payload Type Notation Value -------------------------------------------------- No Next Payload 0 Security Association SA 33 Key Exchange KE 34 Identification - Initiator IDi 35 Identification - Responder IDr 36 Certificate CERT 37 Certificate Request CERTREQ 38 Authentication AUTH 39 Nonce Ni, Nr 40 Notify N 41 Delete D 42 Vendor ID V 43 Traffic Selector - Initiator TSi 44 Traffic Selector - Responder TSr 45 Encrypted and Authenticated SK 46 Configuration CP 47 Extensible Authentication EAP 48 (Payload type values 1-32 should not be assigned in the future so that there is no overlap with the code assignments for IKEv1.) IKEv1の割り当てと重複がないように、Payload type value 1-32は割り当てないこと。 o Critical (1 bit) - MUST be set to zero if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. MUST be set to one if the sender wants the recipient to reject this entire message if it does not understand the payload type. MUST be ignored by the recipient if the recipient understands the payload type code. MUST be set to zero for payload types defined in this document. Note that the critical bit applies to the current payload rather than the next payload whose type code appears in the first octet. The reasoning behind not setting the critical bit for payloads defined in this document is that all implementations MUST understand all payload types defined in this document and therefore must ignore the critical bit s value. Skipped payloads are expected to have valid Next Payload and Payload Length fields. See Section 2.5 for more information on this bit. 前のpayloadのNext Payload filedを理解できない場合、送信者が受信者にpaylaodを無視して欲しい場合、0を設定する。 送信者がPayload typeを理解できない場合、受信者にメッセージ全体を拒否して欲しい場合、1に設定すること。受信者がPaylaod Typeを理解している場合、受信者はこれを無視すること。このドキュメントで定義されたpayload typeの場合は0を設定すること。Critical bitはこのpayloadではなく、Next paylaodのtype codeに適用されることに注意せよ。このドキュメントで定義されたpayloadにCritical bitを設定しない理由は、実装ではこの文章に定義されたすべてのPayload Typeを理解する必要があるため、Critical bitは無視されるべきであるため。無視されたpayloadも正しいNext Payload TypeとPayload Lengthが設定されること。このビットの詳細についてはSection 2.5参照。 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on receipt. 0を設定し、受信側は無視すること。 o Payload Length (2 octets, unsigned integer) - Length in octets of the current payload, including the generic payload header. Generic payload headerを含む、このpaylaodのオクテット長。 Many payloads contain fields marked as RESERVED . Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 4-octet boundaries. 多くのpayloadは RESERVED fieldを含む。IKEv2のいくつかのpaylaodは4-octet アライメントされていない。 3.3. Security Association Payload The Security Association payload, denoted SA in this document, is used to negotiate attributes of a Security Association. Assembly of Security Association payloads requires great peace of mind. An SA payload MAY contain multiple proposals. If there is more than one, they MUST be ordered from most preferred to least preferred. Each proposal contains a single IPsec protocol (where a protocol is IKE, ESP, or AH), each protocol MAY contain multiple transforms, and each transform MAY contain multiple attributes. When parsing an SA, an implementation MUST check that the total Payload Length is consistent with the payload s internal lengths and counts. Proposals, Transforms, and Attributes each have their own variable-length encodings. They are nested such that the Payload Length of an SA includes the combined contents of the SA, Proposal, Transform, and Attribute information. The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains. Security Association paylaodはSAと表記され、Security Associationのattributeをネゴシエーションするために使用される。Security Association paylaodの組み立てには細心の注意を必要とする。SA payloadは複数のproposalを含んでもよい。1つ以上ある場合、よい順で並べること。proposalは単一のIPsec protocol(IKE、ESP/AH)を含み、各プロトコルは複数のtransformが含まれてよく、各transformには複数のattributeが含まれてよい。SAをパースするとき、実装はすべてのPayloda Lengthがpayload内のPayload Lengthと一致することを確認すること。Proposal、Transform、Attributeは可変長のエンコーディング形式をもっている。SAのPayload LengthはネストしたProposal、Transform、Attributeを含む。Proposalのlengthはそれに含まれるすべてのTransform、Attributeを含む。Transformのlengthはそれに含まれるすべてのAttributeを含む。 The syntax of Security Associations, Proposals, Transforms, and Attributes is based on ISAKMP; however, the semantics are somewhat different. The reason for the complexity and the hierarchy is to allow for multiple possible combinations of algorithms to be encoded in a single SA. Sometimes there is a choice of multiple algorithms, whereas other times there is a combination of algorithms. For example, an initiator might want to propose using ESP with either (3DES and HMAC_MD5) or (AES and HMAC_SHA1). Association、Proposal、Transform、Attirbuteのシンタックス(構文)はISKAMPにもとづいている。ただしセマンティクス(意味)はやや異なる。複雑化、階層化の理由は一つのSAで複数のアルゴリズムの組み合わせのエンコーディングを可能とするためである。複数のアルゴリズムを組み合わせることが可能である。例えば、initiatorは(3DES/HMAC_MD5) or (AES/HMAC_SHA1)でESPを提案できる。 One of the reasons the semantics of the SA payload have changed from ISAKMP and IKEv1 is to make the encodings more compact in common cases. SA paylaodがISAKMP、IKEv1から変更されている理由の一つはエンコードを単純にするためである。 The Proposal structure contains within it a Proposal Num and an IPsec protocol ID. Each structure MUST have a proposal number one (1) greater than the previous structure. The first Proposal in the initiator s SA payload MUST have a Proposal Num of one (1). One reason to use multiple proposals is to propose both standard crypto ciphers and combined-mode ciphers. Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and MUST either offer no integrity algorithm or a single integrity algorithm of none , with no integrity algorithm being the RECOMMENDED method. If an initiator wants to propose both combined- mode ciphers and normal ciphers, it must include two proposals one will have all the combined-mode ciphers, and the other will have all the normal ciphers with the integrity algorithms. For example, one such proposal would have two proposal structures. Proposal 1 is ESP with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity algorithm; Proposal 2 is AES-128 or AES-256 in GCM mode with an 8-octet Integrity Check Value (ICV). Both proposals allow but do not require the use of ESNs (Extended Sequence Numbers). This can be illustrated as Proposal構造体はProposal NumとIPsec protocol IDを含む。各構造体は前の構造体よりも1大きいProposal Numberが必要である。initiaorのSA payloadの最初のProposalはProposal Numが1であること。複数のproposalを使用する理由の一つはstandard crypto cipherとcombined-mode cipherの両方を提案できることである。Combined-mode cipherはintegrityとencryptionの両方を含む一つのencryption algorithmである。integrity algorithmはRECOMMENDEDのため、integrity algorithmなし or none のintegrity algorithmのみは提供しないこと。initiatorがcombined-mode cipherとnormal cipherの両方を提案する場合、両方をproposalに含めること。一つはすべてのcombined-mode cipherをもち、もう一つはintegrity algorithmをもつnormal cipherをすべてもつ。例えば、このようなproposalは2つのproposal構造をもつ。 Proposal1はESP with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity algorithmである。 Proposal2はAES-128 or AES-256 in GCM mode with an 8-octet Integrity Check Value (ICV)である。両方のproposalの提案は許容されるが、ESN(Extended Sequence Number)の使用は要求されない。 下記のように示される。 SA Payload | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | | 7 transforms, SPI = 0x052357bb ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 192 ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 256 ) | | | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) | +-- Transform ESN ( Name = ESNs ) | +-- Transform ESN ( Name = No ESNs ) | +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, | 4 transforms, SPI = 0x35a1d6f2 ) | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length = 128 ) | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length = 256 ) | +-- Transform ESN ( Name = ESNs ) +-- Transform ESN ( Name = No ESNs ) Each Proposal/Protocol structure is followed by one or more transform structures. The number of different transforms is generally determined by the Protocol. AH generally has two transforms Extended Sequence Numbers (ESNs) and an integrity check algorithm. ESP generally has three ESN, an encryption algorithm, and an integrity check algorithm. IKE generally has four transforms a Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, and an encryption algorithm. For each Protocol, the set of permissible transforms is assigned Transform ID numbers, which appear in the header of each transform. 各Proposal/Protocol構造には1つ以上のTransform構造が続く。Transformの数はProtocolによって決定される。 一般にAHには2つのTransformがある。Extended Sequence Number(ESN)、integrity check algorithm。 一般的にESPには3つのTransformがある。ESN、encryption algorithm、integrity check algorithm。 一般的にIKEには4つのTransformがある。Diffie-Hellman group、integrity check algorithm、PRF algorithm、encryption algorithm。各Protocolの許容するTransformは各Transform headerにあるTransform ID numberで割り当てられる。 If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple transforms with different Transform Types, the proposal is an AND of the different groups. For example, to propose ESP with (3DES or AES- CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and two Transform Type 3 candidates (one for HMAC_MD5 and one for HMAC_SHA). This effectively proposes four combinations of algorithms. If the initiator wanted to propose only a subset of those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as multiple transforms within a single Proposal. Instead, the initiator would have to construct two different Proposals, each with two transforms. 同じTransform Typeをもつtransformが複数ある場合、ProposalはそれらのTransformのORである。異なるTransform Typeをもつtransformが複数ある場合、ProposalはそれらのTransformのANDである。 例： (3DES or AES-CBC) and (HMAC_MD5 or HMAC_SHA)のESPのProposalでは、2つの Transform Typeを含む。Transform Type 1 (one for 3DES and one for AEC-CBC) and Transform Type 3 (one for HMAC_MD5 and one for HMAC_SHA)である。これは実際は4つのalgorithmの組み合わせを提案している。initiatorがそれらのsubsetを提案したい場合は複数のTranfformを含めない。代わりに、initiatorは2つのProposalに2つのTransformを構成する必要がある。 A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm and the attribute would specify the key size. Most transforms do not have attributes. A transform MUST NOT have multiple attributes of the same type. To propose alternate values for an attribute (for example, multiple key sizes for the AES encryption algorithm), an implementation MUST include multiple transforms with the same Transform Type each with a single Attribute. Transformは1つ以上のAttirbuteをもってよい。Transformのencryption algorithmが可変長キーの場合などはAttributeが必要である。Transformは特定のalgorithmを指定した場合、Attiributeでkey sizeを指定する。多くのTransformはAttributeをもたない。Transformは同じタイプのAttiribureを複数もなたないこと。Attiributeの候補を提案する場合(例：AESで複数のキーサイズ)、実装は、一つのTransformに一つのAttributeを含めること。 Note that the semantics of Transforms and Attributes are quite different from those in IKEv1. In IKEv1, a single Transform carried multiple algorithms for a protocol with one carried in the Transform and the others carried in the Attributes. TransformとAttirbuteのセマンティクス(意味)がIKEv1と異なることに注意せよ。IKEv1では、一つのTransformが複数のalgorithm、別のTransformがAttiributeを送信する。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Security Association Payload o Proposals (variable) - One or more proposal substructures. The payload type for the Security Association payload is thirty-three (33). 1つ以上のProposal構造。Security Association payloadのpayload typeは33である。 3.3.1. Proposal Substructure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 2 | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Proposal Substructure o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the last Proposal Substructure in the SA. This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA. The value (2) corresponds to a payload type of Proposal in IKEv1, and the first four octets of the Proposal structure are designed to look somewhat like the header of a payload. SAの最後のProposal Substructureであることを示す。このシンタックス(構文)はISAKMPから継承されている。ただし、最後のProposalはSAのlengthから特定できるため不要である。 2はIKEv1におけるProposalのpayload typeで、Proposal structureの最初の4オクテットがpayloadのheaderになるように設計されている。 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on receipt. 0を設定し、受信者はこれを無視すること。 o Proposal Length (2 octets, unsigned integer) - Length of this proposal, including all transforms and attributes that follow. 以降に続くすべてのTransform、Attirbuteを含むProposalのLength。 o Proposal Num (1 octet) - When a proposal is made, the first proposal in an SA payload MUST be 1, and subsequent proposals MUST be one more than the previous proposal (indicating an OR of the two proposals). When a proposal is accepted, the proposal number in the SA payload MUST match the number on the proposal sent that was accepted. SA payloadの最初のProposalは1であること。その後のproposalは1より大きいこと（2つのproposalのORであることを示す）。proposalが許容されたときに、SA payloadのProposal Numberは許容されて送信されたProposal numberと一致していること。 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier for the current negotiation. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. 現在ネゴシエーションしているIPsecのprotocol IDを示す。下記の表の値はRFC4306発行時のものである。他の値が追加される可能性もある。最新の値については[IKEV2IANA]参照。 Kaufman, et al. Standards Track [Page 78] RFC 5996 IKEv2bis September 2010 Protocol Protocol ID ----------------------------------- IKE 1 AH 2 ESP 3 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field MUST be zero; the SPI is obtained from the outer header. During subsequent negotiations, it is equal to the size, in octets, of the SPI of the corresponding protocol (8 for IKE, 4 for ESP and AH). initial IKE SAネゴシエーションではこの値は0であること。SPIはouter headerから取得する。ネゴシエーションにより対応するプロトコルのSPIのオクテットサイズが設定される(IKE 8、ESP/AH 4)。 o Num Transforms (1 octet) - Specifies the number of transforms in this proposal. このProposalにおけるTransformの数。 o SPI (variable) - The sending entity s SPI. Even if the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload. When the SPI Size field is zero, this field is not present in the Security Association payload. 送信側のSPI。SPIのサイズが4オクテットの倍数でない場合でもpayloadではパディングしないこと。SPI Size fieldが0の場合はSecurity Association payloadにはこのフィールドは存在しない。 o Transforms (variable) - One or more transform substructures. 1つ以上のTransform構造。
https://w.atwiki.jp/mahjlocal/pages/2182.html
読み ごひゃくてんぼう 種別 その他の用語 別名 解説 点棒の一種だが、標準的なセットには入っていない。 これを使用する場合には、通常100点棒が10本のところを、100点棒5本＋500点棒1本とする。 模様は製造業者などによってさまざまある。 現在のデザインの点棒が登場する以前の古い500点棒については旧式点棒を参照。 また、デノミの小さいブー麻雀やアールシーアール麻雀では最大デノミの点棒として採用されている。 ブー雀荘では、 100点棒→20点棒 1000点棒→100点棒 5000点棒、10000点棒（同一視）→500点棒 とデノミが小さくされている。 成分分析 500点棒の46%は汗と涙(化合物)で出来ています。500点棒の30%は鉄の意志で出来ています。500点棒の13%は華麗さで出来ています。500点棒の8%は媚びで出来ています。500点棒の3%はビタミンで出来ています。 採用状況 全自動卓を使用するMリーグでは500点棒が使われている。色は緑。対局開始時、1人につき500点棒が1本配られる（その他は10000点棒1本、5000点棒2本、1000点棒4本、100点棒5本、マイナス10000点棒2本）。 参照
https://w.atwiki.jp/mcz3001d/pages/33.html
HR500シリーズ (発売されている機種：KD-36HR500,KD-32HR500,KD-28HR500) 製品発表ニュースリリース http //www.sony.jp/CorporateCruise/Press/200308/03-0828/ 修理事例 修理事例 テレビが写ンなくなりました！ SONYのWEGA KD-28HR500 その２28HR500 その３28HR500 関連リンク・FDトリニトロンベガ KD-28HR500 (28) のクチコミ掲示板 FDトリニトロンベガ KD-28HR500 (28) のクチコミ掲示板 もうすぐ丸6年目に突入 MCZ3001D問題 KD-28HR500,KD-32HR500,KD-36HR500はMCZ3001D問題該当機種。 KD-28HR500のMCZ3001の実装数は3個。 KD-32HR500のMCZ3001の実装数は3個。 KD-36HR500のMCZ3001の実装数は3個。 機種型番 症状 結果 関連レスNo.など 全機種有用情報(HD800)(HD900)(KD-28HR500) 765 ：It s＠名無しさん：2011/12/24(土) 18 14 55.50KD-28HR500（2003年10月発売）、本日MCZの無償交換修理をして貰いました＠愛知県 MCZ交換の場合、無償修理で対応しなさいと通達されているのは、今日現在、液晶TVのうちMCZを使用している機種全てと、ブラウン管TVだとHD900（2002年9月発売）あたりかそれ以降のモデルとの事でした。それ以前の機種については、同じMCZ3001使用機種でも、もう無償にはならないそうです。保安部品保有期限（8年？）と無償修理の期間とは関係が無いそうですが、HR500も何時頃まで無償修理の対象になるかはこちらでは分からないとの事。 763氏のHD800はもう対象外だったのかな？ まあ、修理依頼を検討されている方は早目の行動が吉かと。尚、保証書等の提示は必要ありませんでしたが、修理受付窓口（TEL）ではTVの型式・購入時期等を聞かれた後、出張費他で2万円ちょっとの費用が必要になる旨同意させられます。また、修理作業の際リモコンを使用するので、忘れずに準備（電池は新しいものに（笑））しましょう。掃除機、エアダスター等があれば完璧。MCZを3個交換の他、色ズレ調整、チップ抵抗追加（又は交換）でメモリースティック対応容量を増加（2GBまで）してくれました。感謝。以上、どなたかの参考にでもなれば幸いです。 763 機種型番 症状 結果 関連レスNo.など KD-28HR500 246 ：It s＠名無しさん：2009/02/23(月) 10 23 32やっぱレス見まくると、9回点滅は無償みたいですね…今日サービスマンが来るんですが、朝の電話で、ネットで調べ不具合の旨を伝えると、その場合が多いけど別の場合もあるので開けてみないと解らないとの事でした。昼に来るけど修理に二万もかけてられない…どうなるのでしょう…ｶﾞｸﾌﾞﾙ レス250参照 250～252,257 KD-28HR500 250 ：It s＠名無しさん：2009/03/04(水) 23 10 30 246です。朝９時過ぎに電話があったので、修理人にネットの書き込みを伝えると、不具合が多いけど、実際見ないと解らないとの事。２時辺りに到着。機体をばらし、ホコリも丁寧に取ってくれた。作業を見て、さすがと思って見てました。あれよあれよとIC三つ交換。テレビは映って、修理側専用リモコンで点滅1～9回の何回に異常があったかを示す画面を出して、自分の場合は⑨の所に①が。それをにし、作業終了。わざわざ来てくれたので、缶ビールをあげようとして、酒好きですか？って聞いたら、呑みませんからって早々と帰っちゃいました。 - 246,251～252,257 KD-28HR500 251 ：It s＠名無しさん：2009/03/05(木) 01 14 19br() サービスマンは大抵車で来てるんだから、酒勧めるなよｗ - 246,250,252,257 KD-28HR500 252 ：It s＠名無しさん：2009/03/05(木) 02 39 32そういうときはペットボトルお茶とか渡すんだよ - 246,250～251,257 KD-28HR500 257 ：It s＠名無しさん：2009/03/07(土) 21 31 29 246ですおじさんだったので家とかで呑むかなぁと… 買って五年ですが、テレビつけると、バチッていうのが気になったので、それを言ったら直った後に画面見て、確かに全体白がかってるし、両サイドがぼやけてきてるって言われました。そこで薦められたのが、ヤマダ電機の保険？家全体の家電が対象だからと…まぁ、良いこと聞いたなぁ的な… - 246,250～252 KD-32HR500 114 ：It s＠名無しさん：2008/08/14(木) 07 39 449回点滅きて画面が出なくなった サービスマンが来たときにしばらく電源を抜いていたせいなのか一瞬だけ映った。そしたら「この状態はICのせいではなく、コンデンサーの劣化によるものなので有料になる、念のためICも変えていくけど」と言われてしまい1万4千円位取られました。9回点滅した場合は電源抜かないで待ち原因がICなのかコンデンサーなのかわからなくしたほうが良いかも - KD-32HR500 134 ：It s＠名無しさん：2008/09/15(月) 18 52 139回点滅ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!! - - KD-32HR500 138 ：It s＠名無しさん：2008/09/19(金) 00 46 44スタンバイ5回点滅→9回になり購入店に電話→翌日、サービス来る。デカイ為、2名来た。 作業指示書には社告指定品と書かれてあった。修理明細にはやはりIC MCZ3001DB 3コ交換とあり - KD-32HR500 412 ：It s＠名無しさん：2009/11/28(土) 16 27 0132HR500 9回点滅 これから修理くる～無償かなぁ。お金おろしてないしw 有償なら一緒に下のコンビニのATMまで行ってもらうとするかw レス413参照 413 KD-32HR500 413 ：412：2009/11/28(土) 17 41 54412です。1時間くらいで32HR500の修理完了しました。やっぱりMCZの件で、３つ交換。無償でやってもらいました。すごく良いおっちゃんで、色々教えてもらったり。おっちゃんの持っていた伝票を覗くと、『告知修理』と書いてあったです。これと同じ種類のテレビは、中のプラスチックが弱いんだってさ。さてと、昨日のタモリ倶楽部見るとするか。 - 412 KD-32HR500 667 ：It s＠名無しさん：2010/07/09(金) 19 45 28この前からランプ8回点滅で電源入らなくなった04年製32HR500 このスレにきてみたら無償修理終わったみたいだったから、半田工具から部品まで揃え修理に挑戦、ICソケット化×3してMCZ3001DB取り付け完了。無事映像もでた。7月3,4日の二日もかかっていまった、しかし疲れた．．．難しかったのは分解と底プラスチックフレームの裏にあるMCZあとMCZが載っていたサブ基盤の２個のコンデンサー(ESMQ161VSN222MR40S)の僅かな膨張発見、通販していることも確認。この交換はそのうちやることに。 - KD-36HR500 HD800のレス385参照 - - KD-36HR500 248 ：It s＠名無しさん：2009/02/28(土) 22 44 57- KD-36HR500 本日MCZ ３個取替え無償でした。 - KD-??HR500 156 ：It s＠名無しさん：2008/10/08(水) 10 40 18漏れも先日hr500がこの不具合で起動しなくなったんだが無料で修理してくれたわ - - KD-??HR500 278 ：It s＠名無しさん：2009/04/26(日) 09 17 38HR500使ってますが、最近電源入れてからテレビが映るまで結構時間がかかるようになってきた 嫁の話だと、今朝は映るまで30分以上かかったみたいだし 電源ON→カチカチ音がずっと続く→テレビがつく こんな感じで、このスレの症状とは違うみたいだけど修理で直るのだろうか… - 279～282,284,KV-21DA75のカチカチ問題参照 KD-??HR500 279 ：It s＠名無しさん：2009/04/26(日) 17 25 41 278 なおる。 - 278,280～282,284 KD-??HR500 280 ：It s＠名無しさん：2009/04/27(月) 22 58 50 278 コンデンサの故障だろうね。サービスマン次第で無償修理か約15000円コースかってところだね。 - 278～279,281～282,284 KD-??HR500 281 ：It s＠名無しさん：2009/04/27(月) 23 17 59まあ、フライバックトランスとCRTの劣化・故障じゃなければ大体直るな。っていうかブラウン管で地デジいけるやつも売ってたのか。 - 278～280,282,284 KD-??HR500 282 ：It s＠名無しさん：2009/04/30(木) 15 10 29 279 280 281 レスありがとうございます 今週の土曜日にサービスマンがやってくるので、需要無いかもですが、レポートしたいと思います - 278～281,284 KD-??HR500 284 ：It s＠名無しさん：2009/05/02(土) 14 43 23 278です 先程修理完了しましたが、原因はICでした サブでも同じICが使われている様で、無償の対象でした - 278～282 KD-??HR500 440 ：It s＠名無しさん：2010/01/23(土) 23 06 14HR500で9回点滅ｷﾀ－！サポセンに電話→有償修理と言われる→修理してもらう→支払い代金は0円こんな流れでおｋ？ 03年製だけど無料なのかなぁ？ - 442～443 KD-??HR500 442 ：It s＠名無しさん：2010/01/24(日) 01 28 32 4402万近くお金出してまで修理したくない場合は、MCZ以外の交換はしないようにってサービスマンに言っておくといいかも - 440,443 KD-??HR500 443 ：It s＠名無しさん：2010/01/25(月) 12 52 45 440過去レスにある鳥取みたいにボラれた例もあるからそれが良いかもね - 440,442 ランプ点滅回数とその内容 ランプ点滅回数 内容 1 2 3 4 5 6 7 8 9 電源不良