約 6,776,477 件
https://w.atwiki.jp/p2rdj/pages/682.html
神格 Bestiary 1 ゴグンタ［混沌にして悪］ Gogunta 沼地の歌 出典 Bestiary 45ページ 「沼地の歌」ゴグンタは水陸両性のもの、ボガード、そして沼地のデーモン・ロードである。ゴグンタはボガードに女神として信仰されている。ボガードは彼女のことを神に昇格したモボゴであると信じているが、学者によれば彼女は元はヘズロウであり、ダゴンの恩寵を得たものだという。この学説を裏付けるように彼女の領土、悪臭放つ塩沼はダゴンの大海の領土の中にある。ゴグンタは巨大な多頭の蛙の姿で現れ、目はおろか下までも無数にある。しかしボガードは彼女のことを巨大なボガードの女王として描く。 分類 デーモン・ロード 布告 溺れさせてクリーチャーを生贄とせよ、沼地で戯れ歌え、水陸両性のものを食らい助けよ 不義 他の神を信仰するボガードに慈悲を与える 関心のある範囲 水陸両性のもの、ボガード、沼地 信者の属性 混沌にして悪 信奉者の利益 神泉 危害 信仰技能 〈威圧〉 好む武器 ウィップ 領域 飽食、力、暴君、水 クレリックの呪文 1レベル：ジャンプ、3レベル：スティンキング・クラウド、5レベル：ブラック・テンタクルズ ツリーレイザー［混沌にして悪］ Treerazer 爆破された小湖の王 出典 Bestiary 312ページ 爆破された小湖の王、ツリーレイザーは自然の汚染と腐敗のデーモン・ロードに至ろうとするものである。デーモン・ロードに成り代わろうとして失敗した後に追放されたシス＝ヴサグによって排斥された従者あるいは落とし子だと多くのものに信じられている。ツリーレイザーはデーモン・ロードに至ろうとするものであり、真なるデーモン・ロードの力を備えてはいない。しかし彼はかつてエルフの国キョニンの南端にあった腐臭の沼、タングルブライアの中での物理的な存在感を持つ。そのため、そのような存在の中でゴラリオンに最も強い利害関係を持つ特筆すべき存在かもしれない。彼はキョニン国内とその近隣の熱狂的な信者に奉じられているが、ゴラリオンにはその昇格の際に彼の好意を得ようと、彼を解放しようと活動する信者の一派が見られる。ツリーレイザーの宗教印は半分に割られた血を流す枯れ木だ。 区分 デーモン・ロード 布告 植物の命を悪と菌類の繁茂で堕落させよ、エルフを殺せ、腐肉と菌類で宴を行え 不義 エルフを赦す、木を植える、自然の植物の成長を促す 関心のある範囲 自然の汚染と腐敗 信者の属性 中立にして悪、混沌にして悪 信者の利益 信仰能力値 【筋力】もしくは【耐久力】 神泉 治癒もしくは危害 信仰技能 〈自然〉 好む武器 バトル・アックス 領域 破壊、自然、悪夢、暴君 クレリックの呪文 1レベル：グリム・テンドリルズ、3レベル：ウォール・オヴ・ソーンズ、6レベル：タングリング・クリーパーズ Bestiary 2 イデルシウス［混沌にして悪］Ydersius 出典 Bestiary 2 237ページ The serpentfolk god is not dead, but in his decapitated state, he might as well be. Reduced to a feral, animalistic existence, Ydersius is even less aware of his legacy than the lowest of the aapoph. Ydersius’s symbol is a snake’s skull surrounded by a skeletal ouroboros. 分類 Other Gods 布告 seek to return Ydersius to life, fulfill your passions, conquer your foes with no mercy, achieve glory for serpentkind 不義 put the needs of others above those of serpentfolk, aid the spawn of Azlant 関心のある範囲 destiny, fate, and the aging process. 信者の属性 LE, NE, CE 信奉者の利益 神泉 危害 信仰技能 〈ペテン〉 好む武器 ダガー 領域 大望、飽食、力、闘魂 クレリックの呪文 1レベル：マジック・ファング、5レベル：クラウドキル、6レベル：パープル・ワーム・スティング フォロワーズ・オヴ・フェイト［秩序にして中立］Followers of Fate 出典 Bestiary 2 185ページ On the Material Plane, some mortals worship norns as deities, while others, especially witches and bards, admire them as patrons or muses. Those who uphold norns as deities are known as Followers of Fate. Norns do little to discourage this veneration, but neither do they go out of their way to support such worship. Clerics who venerate norns might worship a specific norn or norn triumvirate, or all norns as a whole, but they gain the same benefits regardless of their choice. The religious symbol of Followers of Fate is a pair of shears cutting a golden thread, and their areas of concern are destiny, fate, and the aging process. 分類 Other Gods 布告 make predictions of the future, offer advice and guidance to those in positions of power, provide comfort to the elderly 不義 apologize for making an incorrect prediction, disrespect mothers, accept payment for fortune-telling 関心のある範囲 destiny, fate, and the aging process. 信者の属性 LG, LN, LE 信奉者の利益 神泉 治癒もしくは危害 信仰技能 〈伝承学〉 好む武器 大鋏 領域 家族、運命、知識、真実 クレリックの呪文 1レベル：マインドリンク、3レベル：スリーフォールド・アスペクト、5レベル：プライング・アイ Bestiary 3 アーリマン（ディヴの王）［中立にして悪］Ahriman 出典 Bestiary 3 68ページ The dread shadow known as Ahriman counts servants mainly among div as well as a scattering of followers throughout the mortal realm. 分類 Other Gods 布告 Foil rulers, the proud, and the powerful; ruin anything created by mortals 不義 create arts or crafts, serve a mortal, assist in mortal aims except to subvert and corrupt them 信者の属性 LE, NE, CE 信奉者の利益 神泉 危害 信仰技能 〈ペテン〉 好む武器 ウィップ 領域 闇、死、破壊、欺き クレリックの呪文 1レベル：イル・オーメン、3レベル：ノンディテクション、5レベル：クラッシング・ディスペア グリーン・マン［中立］Green Man 出典 Bestiary 3 119ページ Individual green men are lesser deities, capable of granting spells to those who worship them. Green men typically only allow intelligent plants—such as leshys—to be their clerics. If another creature proves to be a friend of plants, after a thorough personal vetting, a green man wholeheartedly accepts this strange fleshy worshipper into the fold. While individual green men have different edicts and anathema befitting their personalities, and some neutral good or neutral evil green men might have further changes, the following is a baseline most worshippers of green men follow. 分類 Other Gods 布告 discover or create new forms of plant life, foster the growth and well-being of flora, preserve areas of natural wilderness 不義allow flagrant abuse of plant life to go unpunished, damage natural environments, harm plant life except in the pursuit of saving greater plant life 信者の属性 NG, N, NE 信奉者の利益 神泉 治癒 信仰技能 〈自然〉 好む武器 シックル 領域 治癒、力、自然、守護 クレリックの呪文 1レベル：サモン・プラント・オア・ファンガス、2レベル：エンタングル、6レベル：タングリング・クリーパーズ ニャルラトホテプ（闇をさまようもの）［混沌にして悪］Nyarlathotep 出典 Bestiary 3 122ページ Nyarlathotep is often venerated by grioths in a bat-like incarnation with a three-lobed burning eye known as the Haunter in the Dark. His symbol is a circle with wing-shaped arms. 分類 Outer Gods and Great Old Ones 布告 Create darkness, encourage authorities to bring the apocalypse 不義 none 信者の属性 NE, CE 信奉者の利益 神泉 危害 信仰技能 〈伝承学〉 好む武器 ククリ 領域 闇、知識、悪夢、欺き クレリックの呪文 1レベル：グリム・テンドリルズ、4レベル：ナイトメア、5レベル：サモン・エンティティ
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/sanosoft/pages/122.html
PHP7.3のインストール (Amazon Linux 2) amazon-linux-extrasを利用して、PHP7.3をインストールします。 1. amazon-linux-extrasによるインストール (1) phpのインストール まずインストールすることのできるソフトウェアおよびバージョンを確認します。 $ sudo amazon-linux-extras 0 ansible2 available \ [ =2.4.2 =2.4.6 =2.8 =stable ] 2 httpd_modules available [ =1.0 =stable ] 3 memcached1.5 available \ [ =1.5.1 =1.5.16 =1.5.17 ] 5 postgresql9.6 available \ [ =9.6.6 =9.6.8 =stable ] 6 postgresql10 available [ =10 =stable ] 9 R3.4 available [ =3.4.3 =stable ] 10 rust1 available \ [ =1.22.1 =1.26.0 =1.26.1 =1.27.2 =1.31.0 =1.38.0 =stable ] 11 vim available [ =8.0 =stable ] 15 php7.2 available \ [ =7.2.0 =7.2.4 =7.2.5 =7.2.8 =7.2.11 =7.2.13 =7.2.14 =7.2.16 =7.2.17 =7.2.19 =7.2.21 =7.2.22 =7.2.23 =7.2.24 =7.2.26 =stable ] 17 lamp-mariadb10.2-php7.2 available \ [ =10.2.10_7.2.0 =10.2.10_7.2.4 =10.2.10_7.2.5 =10.2.10_7.2.8 =10.2.10_7.2.11 =10.2.10_7.2.13 =10.2.10_7.2.14 =10.2.10_7.2.16 =10.2.10_7.2.17 =10.2.10_7.2.19 =10.2.10_7.2.22 =10.2.10_7.2.23 =10.2.10_7.2.24 =stable ] 18 libreoffice available \ [ =5.0.6.2_15 =5.3.6.1 =stable ] 19 gimp available [ =2.8.22 ] 20 docker=latest enabled \ [ =17.12.1 =18.03.1 =18.06.1 =18.09.9 =stable ] 21 mate-desktop1.x available \ [ =1.19.0 =1.20.0 =stable ] 22 GraphicsMagick1.3 available \ [ =1.3.29 =1.3.32 =1.3.34 =stable ] 23 tomcat8.5 available \ [ =8.5.31 =8.5.32 =8.5.38 =8.5.40 =8.5.42 =8.5.50 =stable ] 24 epel=latest enabled [ =7.11 =stable ] 25 testing available [ =1.0 =stable ] 26 ecs available [ =stable ] 27 corretto8 available \ [ =1.8.0_192 =1.8.0_202 =1.8.0_212 =1.8.0_222 =1.8.0_232 =1.8.0_242 =stable ] 28 firecracker available [ =0.11 =stable ] 29 golang1.11 available \ [ =1.11.3 =1.11.11 =1.11.13 =stable ] 30 squid4 available [ =4 =stable ] 31 php7.3 available \ [ =7.3.2 =7.3.3 =7.3.4 =7.3.6 =7.3.8 =7.3.9 =7.3.10 =7.3.11 =7.3.13 =stable ] 32 lustre2.10 available \ [ =2.10.5 =2.10.8 =stable ] 33 java-openjdk11 available [ =11 =stable ] 34 lynis available [ =stable ] 35 kernel-ng available [ =stable ] 36 BCC available [ =0.x =stable ] 37 mono available [ =5.x =stable ] 38 nginx1 available [ =stable ] 39 ruby2.6 available [ =2.6 =stable ] 40 mock available [ =stable ] 41 postgresql11 available [ =11 =stable ] 42 php7.4 available [ =stable ] 43 livepatch available [ =stable ] 44 python3.8 available [ =stable ] 45 haproxy2 available [ =stable ] 46 collectd available [ =stable ] 47 aws-nitro-enclaves-cli available [ =stable ] 48 R4 available [ =stable ] 49 kernel-5.4 available [ =stable ] 50 selinux-ng available [ =stable ] 51 php8.0 available [ =stable ] 52 tomcat9 available [ =stable ] 53 unbound1.13 available [ =stable ] 54 mariadb10.5 available [ =stable ] 55 kernel-5.10 available [ =stable ] 56 redis6 available [ =stable ] 57 ruby3.0 available [ =stable ] 58 postgresql12 available [ =stable ] 59 postgresql13 available [ =stable ] 60 mock2 available [ =stable ] 61 dnsmasq2.85 available [ =stable ] ここで31の「php7.3」の最新バージョンの「7.3.13」をインストールします。 $ sudo amazon-linux-extras install php7.3=7.3.13 (2) php-develのインストール 「epel」、「remi」リポジトリをインストールする方法は、yumのリポジトリの追加登録方法【Amazon Linux 2】を参照して下さい。 $ sudo yum install --enablerepo=epel,remi,remi-php73 php-devel 2. 関連モジュールのインストール (1) libmcryptのインストール $ sudo yum install --enablerepo=epel libmcrypt (2) libargon2のインストール php-pdoをインストールする場合に必要です。 $ sudo yum install --enablerepo=epel libargon2 $ sudo yum install --enablerepo=epel libargon2-devel 3. PHPの設定 (1) PHPのモジュールのインストール 追加でPHPのモジュールをインストールします。 $ sudo yum install php-mysqlnd $ sudo yum install php-mbstring $ sudo yum install php-gd $ sudo yum install php-xml $ sudo yum install php-xmlrpc $ sudo yum install php-opcache $ sudo yum install php-pecl-zip $ sudo yum install php-pear $ sudo yum install php-pecl-mcrypt (2) php.iniの編集 $ sudo vi /etc/php.ini expose_php = Off max_execution_time = 60 error_reporting = E_ALL ~E_NOTICE ~E_DEPRECATED ~E_STRICT ; Log errors to specified file. PHP s default behavior is to leave this value ; empty. ; http //php.net/error-log ; Example ;error_log = php_errors.log ; Log errors to syslog. ;error_log = syslog ※php-fpmを利用している場合には、エラーログは「/var/log/php-fpm/www-error.log」に書き込まれます。（当初はこのファイルは存在しません。エラーが発生すると自動的に作成されます。） 「/etc/php-fpm.d/www.conf」にログファイル名が記載されています。 post_max_size = 20M upload_max_filesize = 20M date.timezone = "Asia/Tokyo" session.gc_maxlifetime = 7200 mbstring.language = Japanese mbstring.internal_encoding = UTF-8 mbstring.http_input = pass mbstring.http_output = pass (4) Apacheの再起動 Apacheを再起動して、PHPを有効にします。 $ sudo systemctl restart httpd.service (5) php-fpmサービスの起動 $ sudo systemctl enable php-fpm.service $ sudo systemctl restart php-fpm.service 4. HTMLページをPHPとして動作させる場合の設定 通常、HTMLページをPHPとして動作させる場合には、.htaccessに FilesMatch \.html$ AddHandler application/x-httpd-php /FilesMatch と記述すれば動作するはずですが、php-fpmを利用している場合には、設定が無効になる場合があります。 その場合には、以下のように設定します。 (1) .htacces 「/etc/httpd/conf.d/php.conf」において # Redirect to local php-fpm (no mod_php in default configuration) IfModule !mod_php5.c IfModule !mod_php7.c (略) FilesMatch \.(php|phar)$ SetHandler "proxy unix /run/php-fpm/www.sock|fcgi //localhost" /FilesMatch /IfModule /IfModule というような記述があります。 そこで、同様にfpmに処理を引き渡す必要があるので、以下のように.htaccessを記述します。 FilesMatch \.html$ SetHandler "proxy unix /run/php-fpm/www.sock|fcgi //localhost" /FilesMatch (2) /etc/php-fpm.d/www.conf デフォルトでは、PHPコードを実行可能なファイル拡張子が「.php」のみに制限されているため、「.html」も使用できるように設定します。 ; Limits the extensions of the main script FPM will allow to parse. This can ; prevent configuration mistakes on the web server side. You should only limit ; FPM to .php extensions to prevent malicious users to use other extensions to ; exectute php code. ; Note set an empty value to allow all extensions. ; Default Value .php ;security.limit_extensions = .php .php3 .php4 .php5 .php7 の箇所の「security.limit_extensions」の項目を以下のように変更します。 security.limit_extensions = .php .html php-fpmを再起動します。 # systemctl restart php-fpm.service
https://w.atwiki.jp/thunderstone/pages/54.html
Magical Aura/マジック・オーラ カードタイプ：Village/村 エキスパンション：Thunderstone/サンダーストーン 英語版 Card Name Number Class Cost Gold Weight Light VP Text MAGICAL AURA 8 SPELL 4 2 DUNGEON All Weapons become Weight 0.Draw one card. 日本語版 カード名 枚数 分類 コスト 金貨値 重量 明かり 勝利点 テキスト マジック･オーラ 8 呪文 4 2 ダンジョン：すべての武器は重さ0になる。カード1枚を引く。 カード解説/CARD GLOSSARY エラッタ 日本語版「精霊獣の怒り」付属の仕切りカード名称が「マジカル･オーラ」になっている カード分析 所感 英語はMagical Aura。日本語はなぜかマジック･オーラ。仕切りカードのミスはここから来ている。 呪文としては珍しい金貨値2持ち。 村では金貨値、ダンジョンでは1枚ドローなので、購入によるマイナス要素は少ない。あとは重量軽減の効果を活かせるデッキにできるかどうか。 全体化してドローの付いたIron Rations/保存食と考えると、立ち位置がわかりやすい。 重量武器の質と、英雄達の体力次第で有効度が上下する。基本的に使い勝手がよいとはいえないが、構成次第では輝かせることも不可能ではない。 重さ0の武器は体力が0になっていても持てる。また、体力がマイナスになっても実質0として扱うルールがあるため、Revenant/レヴナントや、Lich Lord/リッチ･ロードなどマイナス修正の大きい相手には有用となることも。 シナジー Nightblade/ナイトブレード：重さ3以下の鋭利武器は5種しかないが、マジック･オーラを使用することでそれ以外の鋭利武器でもボーナスが得られるようになる。Claymore/クレイモアを振り回す暗殺者･･･ロマンですな。 Frost Giant Axe/フロスト･ジャイアント･アックス：あえて体力値の高い英雄を採用せずに、アックスのドローを最大限に活かす。 アンチシナジー Polearm/ポールアーム：体力が増すわけでもなく、もともと軽いので重量軽減効果もおいしくない。 得意なモンスター 苦手なモンスター Thunderstone Advance対応版 ※Download Thunderstone Print and Play企画版。 http //www.alderac.com/thunderstone/2012/05/26/download-thunderstone-print-and-play/ 参照。 Card Name Number Class Cost Gold Weight Light VP Text Magical Aura 8 Spell･Support 4 2 Dungeon All weapon Weights become 0. Draw 1 card. 能力自体はクラシック版から変更無し。Support属性が付いたくらい。
https://w.atwiki.jp/s1865_chp/pages/29.html
Individual Defense Individual DefenseSummary Advance preparationPreparation of each individual Federation members to work together. Enemy forces Summary When you start, you are attacked by NPCs, and you earn points for each defense. Wave 25 is available, and it ends when the defense fails three times. While defending, you will not be attacked by other players. (You cannot be attacked either). Better to do this before the unit is damaged by KE. By cooperating with other members of the federation by coordinating the date and time of the event, you can aim for high points. Advance preparation Preparation of each individual If a main unit or hero is dispatched to a resource site, it should be collected. If you do not want to damage the Thunder God unit, retreat to a resource area. Federation members to work together. Move the fortress to a larger location. Relocate base to surround support skill holders. Build strengthening and weakening facilities according to Wave. (after start) Enemy forces Wave Type EnemyLv Soldiers Interval Elapsedtime TimeRemaining Skils 1 Army 77 9 - - 34 00 2 Navy 78 15 1 05 1 05 32 55 3 Air Force 79 21 1 05 2 10 31 50 4 Army 80 27 1 05 3 15 30 45 5 Navy 81 33 1 05 4 20 29 40 Units+10 6 Air Force 82 42 1 05 5 25 28 35 7 Army 83 51 1 05 6 30 27 30 8 Navy 84 60 1 05 7 35 26 25 9 Air Force 85 69 1 05 8 40 25 20 Facility 10 Army 86 78 1 05 9 45 24 15 11 Navy 87 90 1 05 10 50 23 10 12 Air Force 88 102 1 05 11 55 22 05 13 Army 89 114 1 05 13 00 21 00 14 Navy 90 126 1 05 14 05 19 55 15 Air Force 91 138 1 45 15 50 18 10 16 Army 92 153 1 45 17 35 16 25 17 Navy 93 168 1 45 19 20 14 40 18 Air Force 94 183 1 45 21 05 12 55 Energymatrix 19 Army 95 198 1 45 22 50 11 10 20 Navy 96 213 1 45 24 35 9 25 21 Air Force 98 238 1 45 26 20 7 40 Poseidon 22 Army 100 263 1 45 28 05 5 55 23 Navy 102 290 1 45 29 50 4 10 速攻転移 24 Air Force 104 320 2 05 31 55 2 05 25 Army 106 500 2 05 34 00 0 00 DMG+30%
https://w.atwiki.jp/dominions3/pages/26.html
Blood Lv0 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Bleed 0 戦闘 1 1 水中可 1ユニットに毒耐性を無視する毒ダメージを与えます Sanguine Heritage 0 儀式 3 3 44 死2血2を持つ吸血鬼の指揮官Vampire Countを召喚します LA Ulm Lv1 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Blood Burst 1 戦闘 1 2 鎧と魔法防御を無視し狭い範囲にダメージを与えます Blood Heal 1 戦闘 1 1 術者自身のHPを50回復します Reinvigoration 1 戦闘 1 1 術者自身の疲労を回復します Sabbath Master 1 戦闘 1 1 術者はSabbath Slaveを使用した術者に疲労を分散します Sabbath Slave 1 戦闘 1 1 術者はSabbath Masterを使用した術者の疲労の一部を肩代わりします Summon Imp 1 戦闘 1 1 戦闘中、飛行能力を持つImpを5体召喚します Blood Boil 1 戦闘 1 1 0 水中可 敵に鎧無視のダメージを与えます Blood Slaveの消費なしで使用できます Bind Bone Fiends 1 儀式 1 1 3 アンデッドユニットBone Fiendsを3体召喚します Bind Spine Devil 1 儀式 2 3 毒の爪を持つSpine Devilを召喚します Bind Harlequin 1 儀式 1 1 下等なデーモンDemon Jesterを召喚します LA Marignon Summon Rakshasas 1 儀式 1 10 大食いで火に弱いが強靭なデーモンRakshasaを3体召喚します EA LankaMA Bandar LogLA Patala Orgy 1 儀式 1 1 1 潜伏と誘惑の能力を持つ指揮官Satyrと6体の弱い兵士Maenadを召喚します LA Pythium Lv2 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Banish Demon 2 戦闘 1 1 デーモン1体を消滅させようと試みます Agony 2 戦闘 2 1 一定範囲に鎧無視の弱いダメージと恐怖を与え士気を低下させます Hell Power 2 戦闘 3 3 魔法スキル、ステータス、疲労回復、魔法抵抗を得るかわりHorror Markを受け、Horrorに襲われます Bind Fiend 2 儀式 2 5 毒の爪と飛行能力を持つFiend of Darknessを1体召喚します Bowl of Blood 2 儀式 2 2 Blood magic 9の能力でMagic siteの探索をします Bind Beast Bats 2 儀式 1 8 毒の牙を持ち飛行するデーモンBeast Batを3体召喚します EA MictlanMA MictlanLA Mictlan Feast of Flesh 2 儀式 1 1 50 大食いで火に弱いが強靭なデーモンPraghasaを15体召喚します EA LankaMA Bandar LogLA Patala Lv3 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Leeching Touch 3 戦闘 1 0 水中可 接近したユニットに鎧無視のダメージを与え自身のHPと疲労を回復します Pain Transfer 3 戦闘 2 0 術者の受けたダメージを近くのBlood Slaveのダメージに変換します Cross Breeding 3 儀式 1 1 15 20+α体の様々な合成生物を作ります州がLuck scaleに傾いているほど良い結果を得やすくなります Bind Devil 3 儀式 2 2 7 周囲を燃やし飛行能力を持つDevilを召喚します Bind Frost Fiend 3 儀式 2 2 6 周囲を凍らせ飛行能力と氷の遠距離攻撃を持つFrost Fiendを召喚します Summon Asrapas 3 儀式 2 11 Berserkを持つデーモンAsrapaを5体召喚します EA LankaMA Bandar LogLA Patala Summon Se irim 3 儀式 2 33 Berserkを持つSacredなデーモンSe irを8体召喚します荒地でしか召喚できません EA HinnomMA AshdodLA Gath Lv4 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Hellfire 4 戦闘 1 2 1 2つの地獄の炎で一定範囲にダメージを与えます Blood Lust 4 戦闘 2 1 全ての味方デーモンのStrngthを4上昇させます Call Lesser Horror 4 戦闘 2 2 2 戦闘中、翼と生命力吸収、恐怖の能力を持つLesser Horrorを召喚しますHorrorはこちらにも攻撃してきます Bind Serpent Fiend 4 儀式 1 5 翼と毒の牙を持つSerpent Fiendを召喚します Bind Storm Demon 4 儀式 2 2 7 翼と雷の遠隔攻撃を持つStorm Demonを召喚します Bind Demon Knight 4 儀式 2 2 5 重装備の地獄の騎士Demon Knightを召喚します Rain of Toads 4 儀式 3 1 10 指定した州に蛙の雨を降らせ反乱を40上げ、Misfortuneに2傾け、5%の確率でユニットを病気にします Bind Jaguar Fiends 4 儀式 1 1 13 素早く飛びまわる翼の生えたジャガーOzelotlを3体召喚します EA MictlanMA MictlanLA Mictlan Summon Rakshasa Warriors 4 儀式 2 25 より重装備をしたRakshasaの戦士Rakshasa Warriorを5体召喚します EA LankaMA Bandar LogLA Patala Summon Shedim 4 儀式 3 1 32 電撃を操り嵐の中で強くなるデーモンShedを3体召喚します荒地でしか召喚できません EA HinnomMA AshdodLA Gath Lv5 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Hellbind Heart 5 戦闘 2 1 Charmと同じように敵1ユニットを味方にします Bloodletting 5 戦闘 4 4 戦場全てのユニットから生命力を吸収します Awaken Dark Vines 5 儀式 1 3 12 移動は遅いがHPの高いDark Vinesを2体召喚します Send Lesser Horror 5 儀式 2 3 9 指定した州を1体のLesser Horrorに攻撃させます Bind Succubus 5 儀式 4 66 翼と誘惑、生命力吸収能力を持つ指揮官Succubusを召喚します Horde from Hell 5 儀式 4 44 指定した州にDevilの指揮官とImp25体を召喚します Summon Sandhyabalas 5 儀式 2 1 30 闇の中で強くなり魔法の武器も装備するが火に非常に弱いデーモンSandhyabalaを3体召喚します EA LankaMA Bandar LogLA Patala Contact Civateteo 5 儀式 2 2 25 死1血1聖2の魔法を持つ霊体の指揮官Civateteoを召喚します EA MictlanMA MictlanLA Mictlan Lv6 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Harm 6 戦闘 2 1 一定範囲に鎧無視の弱いダメージを与えます 時々Chest Woundを負わせます Call Horror 6 戦闘 3 3 3 戦闘中、翼と生命力吸収、恐怖の能力を持つHorrorを召喚しますHorrorはこちらにも攻撃してきます Bind Ice Devil 6 儀式 3 3 88 6体のIce Devilのうち1体を指揮官として召喚します Rejuvenate 6 儀式 4 10 水中可 術者を10歳若返らせます Infernal Disease 6 儀式 5 5 水中可 病気を撒き散らすDisease Demonにその土地の指揮官を暗殺させます Ritual of Five Gates 6 儀式 5 28 Fiend of Darkness、Devil、Frost Fiend、Storm Demon、Demon Knightをそれぞれ1体召喚します Contact Tlahuelpuchi 6 儀式 2 25 死1緑1血2の魔法と暗殺能力を持つ指揮官Tlahuelpuchiを召喚します EA MictlanMA MictlanLA Mictlan Summon Dakini 6 儀式 2 1 50 多彩な魔法とBlood Vengeanceを持つ指揮官Dakiniを召喚します EA LankaMA Bandar LogLA Patala Bind Tzitzimitl 6 儀式 2 2 10 射程の長い魔法攻撃を放つデーモンTzitzimitlを召喚します EA MictlanLA Mictlan Illwinter 6 儀式 5 3 120 世界中をColdに傾けていき、また敵の土地に霜の巨人や狼が攻撃を仕掛けます EA NiefelheimMA JotunheimLA Utgard Lv7 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Leech 7 戦闘 1 1 狭い範囲に鎧無視のダメージを与え術者を回復させます Blood Rain 7 戦闘 3 3 敵味方全てのユニットの士気を4下げます Blood Rite 7 儀式 2 2 33 飛行、Immortal能力を持つVampireを8+α体召喚します Father Illearth 7 儀式 3 4 85 第三のKing of Elemental Earthであり地4血3の魔法を持つ指揮官Father Illearthを召喚します Send Dream Horror 7 儀式 3 4 15 指定した州に潜伏し、発見されるまで州の不安を増加させていくHorrorの一種Defiler of Dreamsを召喚します Curse of Blood 7 儀式 3 4 77 死3血3の魔法を持つ指揮官Vampire Lordを召喚します Bind Arch Devil 7 儀式 4 2 99 5体のArch Devilのうち1体を指揮官として召喚します Dome of Corruption 7 儀式 4 4 20 75%の確率で敵の魔法から州を守り相手の魔術師にFeeblemindedを与えるドームを余分に費やしたGem分持続させます Astral Corruption 7 儀式 6 6 166 Blood以外の儀式魔法や魔法道具作成をした魔術師をHorrorが攻撃するようになります自国の魔術師でも襲撃されます Summon Samanishada 7 儀式 3 1 35 闇の中で強くなり高い潜伏能力と暗殺能力を持つ指揮官Samanishadaを召喚します EA LankaMA Bandar LogLA Patala Contact Onaqui 7 儀式 4 101 高い魔力と潜伏能力を持つ指揮官Onaquiと8体のBeast Batを召喚します EA MictlanMA MictlanLA Mictlan Reascendance 7 儀式 4 1 88 火3死3血3の魔法と魔法武器を持つ強力な指揮官Fallen Angelを召喚します LA Marignon Lv8 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Life for a Life 8 戦闘 3 1 1ユニットに大きな鎧無視のダメージを与えます Rush of Strength 8 戦闘 3 1 味方全員のStrengthを4高めます Improved Cross Breeding 8 儀式 2 2 20 40+α体の様々な合成生物を作ります州がLuck scaleに傾いているほど良い結果を得やすくなります Send Horror 8 儀式 3 4 15 指定した州を1体のHorrorに攻撃させます Bind Heliophagus 8 儀式 5 111 4体のHeliophagusのうち1体を指揮官として召喚します Three Red Seconds 8 儀式 5 120 指定した州に城を建てます The Looming Hell 8 儀式 7 150 自国のDominion下の敵ユニットはDevilに率いられ指揮官を攻撃するようになります Summon Davanas 8 儀式 5 75 4つの腕を持つ巨人Danavaを3体召喚します EA LankaMA Bandar LogLA Patala Summon Mandeha 8 儀式 5 2 133 高い魔法スキルを持ち戦場に闇を齎す力も持つRakshasaの指揮官Mandehaを召喚します EA LankaMA Bandar LogLA Patala Rain of Jaguars 8 儀式 6 2 40 素早く飛びまわる翼の生えたジャガーOzelotlを8+α体召喚します EA MictlanMA MictlanLA Mictlan Lv9 名称 Lv 使用 主属性 副属性 ジェム 水中判定 概要 専用 Blood Vengeance 9 戦闘 1 1 術者は受けたダメージを無効化し攻撃者にそのまま返すようになります攻撃者が魔法抵抗に成功しない限り常に発生します Infernal Prison 9 戦闘 3 1 2 敵1体をInfernoへ追放します 追放されたユニットは脱出できるまで住人から攻撃を受けます Claws of Kokytos 9 戦闘 3 1 2 敵1体をKokytosへ追放します 追放されたユニットは脱出できるまで住人から攻撃を受けます Horror Seed 9 儀式 4 5 20 指定した州の兵の一人にHorror Seedを植え付けます宿主が死ぬとHorrorが現れ周囲の全てを攻撃します Infernal Forces 9 儀式 5 2 50 Devilを7体+αとImpを20体召喚します Infernal Tempest 9 儀式 5 2 50 Storm Demonを7+α体召喚します Forces of Ice 9 儀式 5 2 50 Frost Fiendを8+α体召喚します Infernal Crusade 9 儀式 5 2 50 Demon Knightを10+α体召喚します Forces of Darkness 9 儀式 6 50 Fiend of Darknessを14+α体召喚します Bind Demon Lord 9 儀式 8 150 4体のDemon Lordのうち1体を指揮官として召喚しますLordはそれぞれ全く違う能力を持ちます Release Lord of Civilization 9 儀式 8 177 6体の堕天使Grigoriのうち1体を指揮官として召喚しますそれぞれが異なる魔法スキルを持ちます EA Hinnom
https://w.atwiki.jp/sumabyono/pages/29.html
魔法のチュートリアル。 魔法には色々な種類があるが、どれもマナを消費する。 テレポートして薬を飲み、右奥の部屋にいるディグルを魔法で倒そう。 訳文 タイトル 魔法 もしあなたが光の魔術師なら、どうして魔法のミサイルなんてつくります？ スタート時 1頁目 英雄の何人かは、鉄と鋼の戦いを選びました。……ときに、厳しい時には、時々木の武器とスパゲッティですが。 他の人々は頭を使うような、奇妙な魔法の術を選択しました。 今回のチュートリアルの主題はこれです。 2頁目 魔法の呪文は、戦闘スキルを使用するのと同じ方法で使えます。 魔法はペットを召喚したり、あなたを危険にさらしたり遠ざけたりと、大抵はあなたの人生をより良いものにします。 3頁目 例えば、あなたの進歩を阻む巨大な堀を考えてみましょう。 エクスクリッドのテレポーテーションを使用すると、堀の反対側に移動することができます。 4頁目 まず、あなたのスキルベルトでそれをクリックして呪文を装備します。 魔法をセットした後 5頁目 今すぐ堀の反対側を右クリックしてテレポートし、レバーを引いてチュートリアルを続行します。 テレポートしてレバーを操作した後 6頁目 呪文はマナを消費します。 消費されたマナの量は、画面下部の青いマナ・バーで強調表示されます。 7頁目 マナを取り戻すには、SPACEキーを押すか、酒を飲むことで回復します。 下水ブリュを見つけて、あなたのベルトに置き、右クリックして飲んでください。 ポーションを飲んだ後 8頁目 下水醸造所は高品質のアルコールではありません。 しかし、あなたのシステムでは酔っ払っているターンごとに、あなたは通常よりも速い速度でマナを取り戻します。 具体的にいうと、毎ターンのマナ1点ほど。 9頁目 酒酔いアイコンは、リフレッシュされるまでの時間を表しています。 10頁目 次の部屋には、ディグルがいます。 魔法使いとして、あなたは弱くてちっぽけで、直接戦えば生き残ることはできません。 代わりに、あなたの魔法の力でディグルを爆破してください。 11頁目 まず、パイロキネシスの呪文をあなたのスキルベルトに装備してクリックします。 魔法をセットした後 12頁目 次に、マウスで右クリックして、そのディグルを爆破してください。 原文 タイトル Magic If you re the Sorceror of Light, why are you casting magic missile? スタート時 1頁目 Some heroes choose fight with steel - or, when times are tough, weapons of wood and occasionally spaghetti. Others have chosen the cerebral, sagely art of magic - and this is the subject of today s tutorial. 2頁目 Magic spells are used in the same way as you use combat skills. Magic can summon pets, transport you in and out of danger, and generally make your life better. 3頁目 For instance, consider the giant moat blocking your progress. By using Xeuclid s Translation, you can move to the other side of the moat. 4頁目 First, equip the spell by clicking on it in your skill belt. 魔法をセットした後 5頁目 Now RIGHT-click on the other side of the moat to teleport, and pull the lever to continue the tutorial. テレポートしてレバーを操作した後 6頁目 Spells consume mana. The amount of mana consumed is highlighted on the blue Mana bar at the bottom of the screen. 7頁目 To regain mana, you can either wait by hitting SPACE, or you can drink booze. Go find the Sewer Brew, then place it in your belt and RIGHT-click to drink it. ポーションを飲んだ後 8頁目 Sewer Brew is not a high-quality from of alcohol. However, every turn that you still have booze in your system, you will regain mana at a faster rate than you would normally - specifically, one point of mana every turn. 9頁目 The Fuelled by Booze icon indicates how long you will remain refreshed. 10頁目 The next room contains a Diggle. As a wizard, you are weak and puny, and would not survive a direct confrontation. Instead, blow him up with your magical powers. 11頁目 First, equip the Pyrokinesis spell in your skill belt by clicking on it. 魔法をセットした後 12頁目 Next, blow up that Diggle by RIGHT-clicking on with the mouse.
https://w.atwiki.jp/diablo3_2ch/pages/25.html
Witch Doctor Skills 更新される方へ お手数ですが、更新前にスキル更新方針を参照するようお願いします。 Active SkillPhysical RealmPoison Dart Plague of Toads Zombie Charger Corpse Spiders Firebats Firebomb Locust Swarm Acid Cloud Wall of Zombies Spirit RealmHaunt Horrify Spirit Walk Soul Harvest Spirit Barrage Mass Confusion SupportSummon Zombie Dog Grasp of the Dead Hex Sacrifice Gargantuan Big Bad Voodoo Fetish Army Passive SkillCircle of Life Vermin Spiritual Attunement Gruesome Feast Blood Ritual Zombie Handler Pierce the Veil Rush of Essence Vision Quest Fierce Loyalty Death Trance Tribal Rites Active Skill Physical Realm Poison Dart Unlocked at level 1 Fires a deadly poison dart that deals 46-67 poison damage and an additional 57 poison damage over 2 seconds. Cost 176 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Plague of Toads Unlocked at level 2 Release a handful of toads that deal 71-99 Poison damage to enemies they come in contact with. Cost 211 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Zombie Charger Unlocked at level 5 Call forth a reckless, suicidal zombie that deals 71-99 Poison damage to all enemies in its way. Cost 229 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Corpse Spiders Unlocked at level 7 Summon 4 spiders to attack nearby enemies for 7-21 physical damage. Cost 282 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Firebats Unlocked at level 9 A swarm of fiery bats burn enemies in front of you for 57-85 Fire damage per second. Cost 352 Mana per second Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Firebomb Unlocked at level 11 Lob an explosive skull that deals 64-78 Fire damage to all enemies within 8 yards. Cost 264 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Locust Swarm Unlocked at level 19 Summon a plague of locusts to assault enemies, dealing 25 Poison damage per second for 3 seconds. The locusts will jump to additional nearby targets. Cost 352 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Acid Cloud Unlocked at level 22 Acid falls down dealing an initial 57-78 Poison damage followed by 14 Poison damage per second to enemies who remain in the area. Cost 528 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Wall of Zombies Unlocked at level 27 A line of zombies emerge from the ground, attacking nearby enemies for 21-36 physical damage per second for 5 seconds. Cost 352 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Spirit Realm Haunt Unlocked at level 4 Haunt an enemy with a spirit dealing 355 Arcane damage over 17 seconds. If the target dies, the spirit will automatically haunt another nearby enemy. You may have up to 3 Haunt effects active at once. Cost 106 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Horrify Unlocked at level 8 Don a spectral mask that horrifies all enemies within 12 yards, causing them to run in fear for 5 seconds. Cooldown 20 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Spirit Walk Unlocked at level 12 Enter the spirit realm for 3 seconds. While in the spirit realm, your movement is unhindered. Your link to the spirit realm will end if you cast any spell or your physical body sustains 50% of your maximum health in damage. Cost 176 Mana Cooldown 15 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Soul Harvest Unlocked at level 14 Feed on the life force of up to 5 nearby enemies within 15 yards. Gain 126 Attack for each affected enemy. This effect lasts 30 seconds. Cooldown 15 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Spirit Barrage Unlocked at level 21 Bombard a target with a spirit bolt that deals 36-71 physical damage. Cost 141 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Mass Confusion Unlocked at level 24 Incite paranoia in enemies, causing some to fight for you for 8 seconds. Cooldown 60 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Support Summon Zombie Dog Unlocked at level 1 Summons 3 zombie dogs from the depths to fight by the Witch Doctor s side. Cost 176 Mana Cooldown 60 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Grasp of the Dead Unlocked at level 3 Hands reach out from the ground slowing enemy movement by 50% and dealing 21 physical damage per second for 8 seconds. Cost 53 Mana Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Hex Unlocked at level 6 Summon a Fetish Shaman for 8 seconds that will hex enemies into chickens. Hexed enemies are unable to perform offensive actions and take 20% additional damage. Cost 176 Mana Cooldown 10 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Sacrifice Unlocked at level 16 All of your zombie dogs explode, each dealing 107-178 physical damage to all enemies within 12 yards. Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Gargantuan Unlocked at level 18 Summon a large zombie follower to fight for you. The Gargantuan swings for 18-25 physical damage with every swing. Cost 528 Mana Cooldown 120 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Big Bad Voodoo Unlocked at level 25 Summon a fetish to begin a ritual dance that increases the attack, casting and movement speeds of all allies in the area by 15% for 20 seconds. Cooldown 120 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Fetish Army Unlocked at level 29 Summon an army of Fetish creatures to fight by your side for 20 seconds. Dagger-wielding fetishes attack for 14-25 physical damage. Cooldown 120 seconds Alabaster 効果 Crimson 効果 Golden 効果 Indigo 効果 Obsidian 効果 Passive Skill Circle of Life Unlocked at level 10 Gain 10% of your maximum Mana whenever you are healed by a health globe. Vermin Unlocked at level 10 Your Plague of Toads, Corpse Spiders and Firebats abilities do 20% more damage. Spiritual Attunement Unlocked at level 13 Maximum Mana is increased by 20%. Regenerate 1% of your maximum Mana per second. Gruesome Feast Unlocked at level 15 Gain 10% Attack for 10 seconds whenever you are healed by a health globe. This effect can stack up to 5 times. Blood Ritual Unlocked at level 17 50% of Mana costs are paid with Life. In addition, you regenerate 1% of your maximum Life per second. Zombie Handler Unlocked at level 19 You can have 4 Zombie Dogs out at once. The health of your Zombie Dogs and Gargantuan are increased by 60%. Pierce the Veil Unlocked at level 20 All of your damage is increased by 20% but your Mana costs are increased by 30%. Rush of Essence Unlocked at level 23 Spirit spells return 125% of their Mana cost over 10 seconds. Spirit spells are • Haunt • Horrify • Soul Harvest • Spirit Barrage • Spirit Walk Vision Quest Unlocked at level 25 Anytime you have 4 or more skills on cooldown your mana regeneration is increased by 100%. Fierce Loyalty Unlocked at level 26 All your pets gain 100% of the benefit of your thorns items. Death Trance Unlocked at level 28 Reduce damage by 20% whenever you are below 50% of your maximum Life. Tribal Rites Unlocked at level 30 The cooldowns of your Fetish Army, Big Bad Voodoo and Hex abilities are reduced by 25%.
https://w.atwiki.jp/arma3editor/pages/6.html
Arma 3 Cars Config Guidelines ARMA３における車両作成、改造におけるガイドラインを翻訳しましたので作成等にご利用下さい。 専門用語が有るので、日本語、英語共に不自由な人間が翻訳していると言う事をご理解ください。 文章そのままだと日本語的に理解し辛いので、意訳+注釈です。 ※実際にmoddingした訳ではなく、読んで意訳しただけなので、実際の意味と違う可能性が ありますのでご注意ください。 ワープロモード：参照http //www54.atwiki.jp/arma3editor/pages/4.html Arma 3 Cars Config Guidelines Arma 3 Cars Config Guidelines ARMA3の車両に関するコンフィグガイドライン Contents 内容 1 Intro 最初に 2 Additional functionality compared to A2/OA ARMA2、OAとの違い 3 Model requirements {p3d} p3d形式の"model"の条件 4 Model config changes {model.cfg} model.cfgの変更点 5 New config parameters {config.cpp} config.cppの新しいパラメータ 5.1 Basic parameters 基本パラメータ 5.1.1 Differential parameters パラメーターの違い 5.1.2 Engine parameters エンジン用パラメータ 5.2 Wheel parameters ホイール用パラメータ 5.2.1 General parameters 一般的なパラメータ 5.2.2 Wheel PX parameters ホイールPXパラメータ 5.2.3 Wheel simulation parameters ホイールシュミレーションパラメータ 5.2.4 Suspension parameters サスペンションパラメータ 5.2.5 Tire parameters タイヤパラメータ 5.3 Floating and sinking 浮く、沈む（水の上等） 5.4 PhysX 3 integration PhysX3 統合 5.4.1 Anti-roll bars アンチロールバー 5.4.2 Complex gearbox 複雑なギアボックス 5.4.3 Gearbox parameters ギアボックスパラメータ 5.4.4 Different amount of torque 個別のトルクの量 5.5 IK for hands and legs 乗車時、キャラクタの手足の位置 5.6 Picture in Picture for screens and mirrors スクリーンとミラーにピクチャーインピクチャー（画像の中に別の画像を表示する）する方法 ※要約すると、車両にバックミラーやモニター等に表示させる記述 5.7 Random visual variants ランダムにビジュアルを変化させる ※ハッチバック等、スポーンする度にテクスチャが違うアレ 5.7.1 Random variants script ランダムに表示させる為のスクリプト 5.8 Reflectors, markerlights and beacons 反射板、マーカーライト、ビーコン 5.8.1 Reflectors 反射板 5.8.2 Markerlights マーカーライト 5.8.3 Beacons ビーコン 6 Basic config hints 基本的なコンフィグのヒント 6.1 Diagnostics 診断（作成した車両のテスト） 6.2 Suspension サスペンション 6.3 Gearbox ギアボックス 7 Reference 参照場所 Intro 初めに 101 - How to set up a car for Arma 3 ARMA3用の車の作り方 Please be aware of our Arma 3 modding license http //community.bistudio.com/wiki/Arma_3_Modding_License ARAM3用MOD作成に関するライセンス規定を確認してください。 Additional functionality compared to A2/OA ARAM2、OAとの違い PhysX 3 integration ○PhysX３と統合 IK for hands/legs ○車両乗車時の手足の位置 Picture in Picture - Render to texture ○PiP テクスチャーのレンダー Random visual variants (textures, accessories, doors) ○ランダムでビジュアルの変化 ※テクスチャー、アクセサリー（バリエーション的なもの）、ドアをスポーン時にランダム表示 Floating and sinking ○水上での浮き沈み Reflectors, markerlights and beacons ○反射板、マーカーライト、ビーコン Model requirements {p3d} p3dモデルに関する必須項目 A new PhysX lod ○新しいPhysX LOD There needs to be a lod (4e13) consisting of convex components as simple as possible, some 60 faces shall be sufficient for most cars 作成には単純な構造のものが必要です。ただ、大半は60面程あれば車両を作成するには十分です。 ※私の知識不足で、LOD(4e13)がexで40trillionなのか、それ以外の「何か」なのか良く解りません。 Current public Oxygen version doesn t support showing correct name of this lod and displays only Geometry instead. Don t be afraid of having two geometries, it s going to be fixed with new tools. Oxygen(BIツール名)では、このLODの名前を表示できません。代わりにジオメトリだけを示します。（使用に問題なし）この問題は新しいツールで解消する予定です。 Just the main body of car should be in this lod, wheels are added by engine later 車両の基本部分は、上記のLODで構成される必要があります。 作成する順番はエンジン→ホイールの順に追加していきます。 Memory lod メモリーLOD There should be an axis for each wheel named wheel_X_Y_axis (X is position of wheel from front, Y is 1 for left and 2 for right), the name is defined in selected wheel as center ホイールの軸（中心）をwheel_X_Y_axisという名前で定義される必要があります。それぞれ（X,Y）でホイールの中心位置を定義します。 車両の正面から見た状態でホイールの位置をXの部分に記入します。Yは左右同じです（じゃないと傾くので）。 There should be a point at the edge of each wheel named wheel_X_Y_bound which is used to determine wheel radius (distance from wheel axis is used for this) - there is no other need than placing the point at the edge, even memory points for tracks could be used for this, the name is defined in selected wheel as boundary ホイール（タイヤ含めた）の大きさを測定するのに必要です。何かというと、ホイール外径の一カ所だけ指定すればwheel_X_Y_axisを中心として円を判定してくれます。 wheel_X_Y_boundのX、Yに何処でも良いので、外径部分の座標を指定します。 ※公式の解説画像ではホイールの中心から垂直方向の地面を座標定義してます。 ○注釈 ホイールの中心から外輪の距離を定義。 ・wheel_X_Y_axis ホイールの中心 ・wheel_X_Y_bound ホイールの半径（中心からの距離） ※多分、wheel_X_Y_boundの「X または Y」のどちらかをホイールの半径分入力すれば良いと思います。Yが無難ですが。 physx bound.jpg Mirrors and screens should have their camera position defined in pipX_pos and direction in pipX_dir - parameters pointPosition and pointDirection in class RenderTargets ミラーとスクリーン（車載モニター）はカメラの位置（pipX_pos）と向き（pipX_dir）で定義する必要があります。 ※ミラーは実際に反射しているのではなく、カメラ機能を使って擬似的に「反射してる様に」見えるだけ。なので、「ミラー」を使うと当然、左右反転するようです。 Reflectors should have their position defined in LightCarHeadYXX (Y is a side - R/L, XX is a number) and direction defined in LightCarHeadYXX_end 反射器は LightCarHeadYXXで定義する必要があります。LightCarHeadYXX_end でその方向を定義します。Yは左右それぞれの横軸、XXは定義した番号です。 Mirrors and screens should have RTT texture #(argb,256,512,1)r2t(rendertargetX,1.0) - where X in rendertarget should be a number ミラーとスクリーンはRTTテクスチャを #(argb,256,512,1)r2t(rendertargetX,1.0)で指定します。Xは定義した番号を記入します。 Randomly generated accessories should have their selections independent on all other selections (mainly the main body and all the glass selections), glass as a part of hide-able accessory should be handled as two separate selections ランダムに発生するアクセサリーパーツは全て独立した部品である必要があります。 アクセサリの一部分を隠すように扱うには、２つの部分に分割（離れて）する必要があります。 ※ここ良く解りません。すいません。多分ですが、車両にオブジェクトを貼り付ける場合、車体に埋めると内部から見える場合があるので、 はみ出てた部分を隠したいなら部分を別パーツとして定義する必要があるという意味かと思われます。 Beacons and markerlights should have their material set to emit light ビーコンとマーカーライトは、発光させるために設置しなければなりません。 Spare wheel should have defined selections for it, texture underneath and correct hitpoints like a normal wheel スペアホイール（予備タイヤ）に交換できるようにするには定義する必要があります。予備タイヤの耐久性（壊れやすさ）は標準タイヤと同じ数値です。 ※交換なので、エンジニアの修理とは別です。 Man-held turrets shouldn t be hidden when destroying them without destroying the whole vehicle - IK issues would crash the game ターレット（銃座）の乗員が乗っている状態（と定義して）でターレットを隠すように指定した場合、ゲームがクラッシュします（IK定義の関連） ただし、車両が「完全に破壊（ドカーンって燃えた）」された状態であれば、問題ありません。 ※車両がアライブの状態で「見えないターレット」を定義して使うとクラッシュするという事かと思われます。多分。 Model config changes {model.cfg} model.cfgの変更点 Only the dampers are affected by the changes, best way to set them is to place an axis with the length of moveable part alongside the damper and set offsets to +-0.5 ダンパー（サスペンション）は凹凸路面などの影響を受けて可動します。そのため、定義する際に「ダンパーの中心から±0.5ほどオフセットするといいと思います。 Example {model.cfg} class Wheel_1_1_Damper { type="translation"; source="damper"; selection="wheel_1_1_damper_land"; axis="posun wheel_1_1"; animPeriod = 1; minValue="0"; maxValue="1"; offset0= "0.5"; offset1= "-0.5"; memory=1; }; ●●●●●●●●●●●●訳 28/Oct/2013●●●●●●●●●●●●●●●●●●●● Sections for hiddenSelectios[] should be set in model.cfg hiddenSelectios[]の部分はmodel.cfgで定義する必要があります。 New config parameters {config.cpp} config.cppの新しい追加パラメータについて Basic parameters 基本パラメータ Following parameters are defined in vehicle class. vehicle classという定義内で以下のパラメーターを使います。 ※config.cppの車両に関する定義部分にviecle classという場所があるので、そのクラスを定義する際に使用するという事。 string (required) simulation = "carx"; float 0.0 dampersBumpCoef = 0.3; Differential parameters 他と異なるパラメータ string; accepable values "all_open", "all_limited", "front_open", "front_limited", "rear_open", "rear_limited" "all_limited" differentialType = "all_limited"; float 0.5 frontRearSplit = 0.5 float 1.3 frontBias = 1.3; float 1.3 rearBias = 1.3 float 1.3 centreBias = 1.3 float 10.0 clutchStrength = 10.0; float 0.01 switchTime = 1.01; Engine parameters エンジンパラメータ float (required) enginePower = 600; float 600 which is cca 6000 rounds per minute. maxOmega = 600; float value calculated from enginePower according to http //en.wikipedia.org/wiki/Horsepower#Relationship_with_torque peakTorque = 600; float, float, float 0.08, 2.0, 0.35 dampingRateFullThrottle = 0.08; dampingRateZeroThrottleClutchEngaged = 2.0; dampingRateZeroThrottleClutchDisengaged = 0.35; Array[i][2] where i = number of samples, maximum 8; {{0.0, 0.8}, {0.33, 1.0}, {1.0, 0.8}} torqueCurve[] = {{0.0, 0.8}, {0.33, 1.0}, {1.0, 0.8}}; Wheel parameters ホイールパラメータ This parameters relates to each wheel. In the vehicle class, there has to be subclass called Wheels, which contains subclass for every wheel the vehicle has. These are the parameters that could be defined in that subclasses. このパラメータはそれぞれのホイールに関する項目です。vehicle classはwheelsというサブ（隷下）クラス（viecle classがメインクラス）が必要です。 要は、車両に付いている全てのホイール（タイヤ）をサブクラスという定義でそれぞれ設定できるパラメータです。 General parameters 一般的なパラメータ string "" boneName = "wheel_1_1"; bool (required) steering = true; string "right" side = "left"; Wheel PX parameters ホイールPXパラメータ memory point (required) center = "wheel_1_1_axis"; memory point (required) boundary = "wheel_1_1_bound"; float 0.3*(raidus of the wheel) width = "0.2"; float 10.0 mass = 150; float 0.5 * WheelMass * WheelRadius * WheelRadius MOI = 40; float 0.1 dampingRate = 0.1; float 2500 maxBrakeTorque = 7500; float 2*maxBrakeTorque maxHandBrakeTorque = 0 Wheel simulation parameters ホイールシミュレーションパラメータ Array[3] {0, -1, 0} suspTravelDirection[] = {0, -1, 0}; memory point center suspForceAppPointOffset = "wheel_1_1_axis"; memory point suspForceAppPointOffset tireForceAppPointOffset = "wheel_1_1_axis"; Suspension parameters サスペンションパラメータ float 0.15 maxCompression = 0.15; mMaxDroop = 0.15; float vehicleMass/numberOfWheels sprungMass = 2066; float sprungMass*5,0*5,0 springStrength = 51653; float 0,4*2*sqrt(springStrength*sprungMass) springDamperRate = 8264; Tire parameters タイヤパラメータ float 10000 longitudinalStiffnessPerUnitGravity = 10000; float, float 25, 180 latStiffX = 25; latStiffY = 180; Array[3][2] {{0, 1}, {0.5, 1}, {1,1}} frictionVsSlipGraph[] = {{0, 1}, {0.5, 1}, {1,1}}; Floating and sinking 浮き沈み（水で） WaterLeakiness should be amount of water in liters that goes into selected object per second. This is set to zero by engine for all vehicles with simulation of a ship or having canFloat = 1 (unless they are toppled of destroyed, then config value takes precedence). WaterLeakiness = 10; seems to be a good value to start with for all kinds of vehicles no matter the size (which is a bit spooky, but it works). 浸水具合は指定パーツをℓ/secで定義します。浸水具合によってエンジンが止まります。ただ、船又はcanFloat=1と定義されたものは完全にブッ壊されない限り浮いてます。 最初はWaterLeakiness＝10と定義して、どのぐらい水に浸かったらエンジンがブッ壊れるかテストすると良いでしょう。 PhysX 3 integration PhysX3で統合 WheelMask ホイールマスク thrustDelay is time in second in which thrust goes from 0 to 1 when standing still (doesn t affect driving car during change of gears), 0.2 seems to be a reasonable value. You may want to tweak this to higher values if wheels slide during initial acceleration. キー入力をしてから実際に車輪が動作するまでの遅延をthrustDelayで定義します。スラストが0→1になるまでの数値です。0.2位が妥当と思われます。もし１にしたら一瞬で加速します。 brakeIdleSpeed is speed in m/s under which the brakes are automatically applied to the vehicle. This speed should be reasonably low, higher value would mean strange breaking of slow cars, too low value would cause inability to stop the car. 1秒当たりのブレーキの定義です。 brakeIdleSpeedはm/secで定義します。この数値は低めに設定した方が良いです。高めに設定すると不自然な急ブレーキになります。 逆に異常に低すぎると止まれません。 idleRpm sets the idle RPM of engine. Primary use is for sound engine アイドリング時の回転数をidleRpmで定義します。停車時のエンジン音に関係します。 redRpm sets the maximum for engine RPM, should be according to maxOmega (see later) エンジンの最高回転数（レブリミット）をredRpmで定義します。後記のmaxOmegaに関係しています。 Anti-roll bars アンチロールバー Anti-roll bars is the system in vehicle that should prevent it to do a barrel-roll during sharper turns. Using ARB enables us to make center of mass realistically high and cause cars to roll down the steep slopes if placed sideways to the slope. It works the same way as the real ones - system computes difference of applied weight to wheels in pair and tries to compensate difference by applying opposite forces. アンチロールバーは急激なターンとか無茶な運転等で横転するのを防ぎます。錘みたいな物です。なので、横転しやすい車両も作れます。以下がそのパラメータ。 antiRollbarForceCoef is a coefficient of applied force, could be taken as strength of the system. Setting this value to zero disables ARB (and all next values), which is good for civilian vehicles, higher values reduce not only the risk of rolling, but effects of suspension. この数字を0にすると動かなくなります。逆にantiRollbarForceCoefの数字を高くすると横転しやすいどころか止まれません。 antiRollbarForceLimit is the highest strength of ARB applied to vehicle. We may want to roll the car at certain situations (full van taking sharp hand-brake turn at high speed), tunning without diag mode is almost impossible because we are not able to imagine forces needed (values are rather low, 2 should be high enough for most of vehicles) 高速移動中に急ハンドルで横転させたいとか、そういう時に必要になります。 antiRollbarSpeedMin and antiRollbarSpeedMax are limits of applied force coefficient. Coefficient is 0 at speeds lower than antiRollbarSpeedMin, interpolates to antiRollbarForceCoef at antiRollbarSpeedMax and is set to antiRollbarForceCoef for any higher speeds. This allows cars to drive on steep slopes using their radial speed, falling of the hill once they stop and rolling over at too high speeds (where coefficient doesn t grow and force is limited by the limit). antiRollbarForceCoefの上下限をantiRollbarSpeedMinとantiRollbarSpeedMaxで定義します。 Complex gearbox 複雑なギアボックス All PhysX 3 vehicles use complex gearbox to give some data to PhysX gearbox PhysX3の車両は全部ギアボックスが搭載されてます。 Complex gearbox settings is inside class complexGearbox which is a subclass of vehicle class ギアボックスのセッティングはcomplexGearboxというサブクラスで、viecle classの隷下です。 GearboxRatios[] is an array of gear names and gear ratios starting with reverse gear (with negative ratios), neutral gear (which should have zero ratio) and forward ratio (eg {"R1",-3.231,"N",0,"D1",2.462,"D2",1.870,"D3",1.241,"D4",0.970,"D5",0.711};). Gear names are not used in retail version, they are just for epevehicle diagnostics R1がバックで、Nニュートラル（数字入れたら勝手に前進します）、D1、D2・・・となります。GearboxRatios[]で定義すれば何ギアでも可能ですがギア比が訳解らなくなるので程々に。 TransmissionRatios[] is an array of transmission ratios in the same format as gearboxRatios. Most of cars have only one transmission ratio, some heavy trucks may have two. The final ratio of engine is gearboxRatio * TransmissionRatio, that means transmissionRatios shouldn t be multiplicates of each other and gearbox ratios to prevent the same final ratio for two different gears. 普通は１つ定義すれば良いですが、大型トラックは２つ定義が必要でしょう。 ※良く解らん・・・・ gearBoxMode is set to full-auto by engine gearBoxModeはエンジンによってフルオートでセットされます（・・は？ イミフ） moveOffGear defines what gear an automatic or semi-automatic gearbox will move off from stationary in. 1 by default. この定義（moveOffGear）はオートマもしくはセミオートでギアボックスが静止状態から発車します。（動作にギア操作を入れるかどうか）標準（普段通りの操作）は１です。 driveString, neutralString and reverseString define displayed strings for driving forward, neutral and backward. この３つ（driveString, neutralString, reverseString）は前進、キー無操作、後進を表示させるために定義を紐づけします。 ※これを入れればギアがドライブ（D)、ニュートラル（N)、バック（R)のどの状態かHUDに表示されるようです。 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ {config.cpp} class complexGearbox { GearboxRatios[] = {"R1",-3.231,"N",0,"D1",2.462,"D2",1.870,"D3",1.241,"D4",0.970,"D5",0.711}; TransmissionRatios[] = {"High",4.111}; // Optional defines transmission ratios (for example, High and Low range as commonly found in offroad vehicles) moveOffGear = 1; // defines what gear an automatic or semi-automatic gearbox will move off from stationary in. 1 by default. driveString = "D"; // string to display in the HUD for forward gears. neutralString = "N"; // string to display in the HUD for neutral gear. reverseString = "R"; // string to display in the HUD for reverse gears. }; －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ Gearbox parameters ギアボックスパラメータ Some gearbox parameters are defined outside of class complexGearbox, they are mainly to setup automatic gearbox 幾つかのギアボックスパラメータはcomplexGearboxのクラス外で定義します。サブクラスでは有りません。 通常、オートマ用のギアボックスに使用します。 changeGearMinEffectivity[]Value of minimal gear effectivity to hold current gear. If there is better gear and effectivity is below this value then change gear. It is an array of effectivities ordered by gears in complex gearbox. Neutral should have rather low effectivity (0.15 seems to be a good value), drive gears should have rather high value (around 0.95) to prevent switching gears too often switchTimeThe switch time describes how long it takes (in seconds) for a gear change to be completed. RPM interpolate to optimal value for the new gear at current speed during the changing of gears. The time should be rather low, around 0.3 s, to keep the momentum of the car. latencyis the minimum time (in seconds) that must pass between each gear change that is initiated by the autobox. This should be set to value higher than switchTime. Setting this time too low makes some issues with changing gears - the car slows down a lot Different amount of torque coefficients for different speeds of Slow, Forward and Fast are now configurable slowSpeedForwardCoefis set to 0.3 by default normalSpeedForwardCoefis set to 0.85 by default default speed coefficient for fast movement is 1 meaning that full throttle is applied and maximal speed is maxSpeed of the vehicle (it is going to apply less throttle upon reaching the limit) IK for hands and legs It s not Inverse Kinematics in fact, but as close to it as possible. A soldier should have IK defined for hands and legs by default Each vehicle pose using IK should haveleftHandIKCurve[]andrightHandIKCurve[]set to 1 Driver should havedriverLeftHandAnimNameanddriverRightHandAnimNamedefined as drive wheel bone of the vehicle (drivewheelby default) Gunner should havegunnerLeftHandAnimNameandgunnerRightHandAnimNamedefined on handles of the gun, or shaking bone of the weapon shall be sufficient (usually something likeotocHlaven_shake) Double check names of bones if the game crashes upon loading this vehicle and call stack points to IK. Wrong definition causes CTD all the time and removing the bone causes the same (eg. by hiding it). Picture in Picture for screens and mirrors All sources for textures to be rendered on are defined inclass RenderTargetswhich is a subclass of vehicle class Each source is a separate subclass with unique name parameterrenderTargetdefines which texture shall the source be mapped at (only therendertargetXpart is used) class CameraView1is a subclass of this source and contains all the parameters for rendered scene pointPositionandpointDirectionshould be respective memory points in model renderQualityis in range from 0 to 2 and defines quality of rendering for said source renderVisionModedefines the vision mode - 0 = HDR, 1 = NightVision, 2 = ThermalVision, 3 = Color, 4 = Mirror fovdefines field of view of this source {config.cpp} class RenderTargets { class LeftMirror { renderTarget = "rendertarget0"; class CameraView1 { pointPosition = "PIP0_pos"; pointDirection = "PIP0_dir"; renderQuality = 2; renderVisionMode = 0; fov = 0.7; }; }; }; Random visual variants Randomization of variants is done by script ran upon start of mission via init event handler The car should inheritclass EventHandlers EventHandlers {config.cpp} init event handler should be changed to something like this init="(_this select 0) execVM ""\pathToCar\scripts\scriptName.sqf"""; Don t forget to hide all the added accessories upon destruction of vehicle, they are usually in proxies, this is handled by killed event handler {config.cpp} killed = "_this call (uinamespace getvariable BIS_fnc_effectKilled ); _this select 0 animate [""RandomAnimation"",0]; Random variants script All random settings should be done on server side to prevent different car looks for different users {script.sqf} if (isLocal) then {_rnd1 = floor random Y; _this setVariable ["BIS_randomSeed1", _rnd1, TRUE]; _this animate ["RandomAnimation", X];}; Ystands for the number of random variants Even all the animations should be handled server-side to ease clients,RandomAnimationshall be replaced by any animation needed to be randomly chosen,Xstands for animation phase {script.sqf} waitUntil {!(isNil {_this getVariable "BIS_randomSeed1"})}; _randomSeed1 = _this getVariable "BIS_randomSeed1"; Random textures shall be taken with this statement {script.sqf} _this setObjectTexture [0, ["\pathToCar\Data\variant_1_co.paa", ...,"\\pathToCar\Data\variant_Y_co.paa"] select _randomSeed1]; Reflectors, markerlights and beacons Reflectors Reflectors need to be defined inclass Reflectors Default cars should have two reflectors defined as separate subclasses inside class Reflectors. These two classes should differ only inposition,direction,hitpointandselection. Position and direction are self-descriptive, they use memory points in mode, hitpoint is the name of selection in hitpoint lod in model, selection is a visual selection in resolution lods. Most of reflectors should haveuseFlareset to 1, they are bright enough to have a flare. Size of this flare is defined byflareSize, value should be rather low, around 0.1 seems to be good for start. class Attenuationinside each reflector subclass defines behavior of light from distance. Attenuation is combination ofconstant,linearandquadraticcoefficient,startis a distance from position where attenuation starts to work (the light is at it s full strength if distance is lower than start). aggregateReflectors[]outside of Reflectors class is used to ease computing of too many light sources and combines light together. Both reflectors should be aggregated for a default car but feel free to experiment. Just run some FPS test after testing non-standard settings. Markerlights Markerlights are purely model side based on assigned emissive materials Beacons Beacons consist of two parts on model side - emissive one and unlit one. The emissive one is hidden by default by an user controller and periodically hidden by time controller in model.cfg Config contains only user actions to turn beacons off/on by hiding/unhiding them, this is insideclass UserActions UserActions There should be two actions per beacons set - one to turn them off and other to turn them on, each as a subclass of UserActions {config.cpp} class UserActions UserActions { class beacons_start { userActionID = 50; displayName = "Beacons start"; displayNameDefault = ""; position = "mph_axis"; radius = 1.8; animPeriod = 2; onlyForplayer = false; condition = "this animationPhase ""BeaconsStart"" 0.5 AND Alive(this) AND driver this == player"; statement = "this animate [""BeaconsStart"",1];"; }; class beacons_stop beacons_start { userActionID = 51; displayName = "Beacons stop"; condition = "this animationPhase ""BeaconsStart"" 0.5 AND Alive(this) AND driver this == player"; statement = "this animate [""BeaconsStart"",0];"; }; }; Basic config hints Diagnostics Drive around as much as possible, preferably using real islands. Use Stratis airstrip for acceleration, gear change and sinking of vehicle purposes Path from Jay Cowe to Airstation Mike-26 on Stratis is great to test uphill performance of the car and AI driving skills Whole Chernarus is excellent playground to test vehicles Suspension Easier way to set up suspension is to have center of mass centered according to wheels. Non-centered center of mass is more interesting for driving performance, just be sure to make center of mass centered at least in left-to-right axis. Each wheel could have different suspension parameters but try to keep them the same for wheel pairs. You may try to use ARB if the car sways a lot sideways during turns. This causes lesser side sway but doesn t reduce bumping of suspension when accelerating and breaking. Gearbox Real gearbox ratios have extremely good results for higher speeds and are realistic for lower speeds. But it is better to use some lower values for lower gears to improve acceleration Look out for too big steps between gear ratios, this may prove to be problematic with steeptorqueCurve- engine would change gear later than expected and sound would go fubar dampingRateZeroThrottleClutchEngagedanddampingRateZeroThrottleClutchDisengagedcould be the same, this works really well for FWD cars - engine would slow them down way too much and lock the wheels when only directional arrow is pressed Reference This page is discussedon the BI forums 名前 コメント
https://w.atwiki.jp/touhoukashi/pages/6033.html
【登録タグ Stack あ アトミカ・トカマク -ATOMICA TOKAMAK- 暁Records 曲 業火マントル 霊知の太陽信仰 ～ Nuclear Fusion】 【注意】 現在、このページはJavaScriptの利用が一時制限されています。この表示状態ではトラック情報が正しく表示されません。 この問題は、以下のいずれかが原因となっています。 ページがAMP表示となっている ウィキ内検索からページを表示している これを解決するには、こちらをクリックし、ページを通常表示にしてください。 /** General styling **/ @font-face { font-family Noto Sans JP ; font-display swap; font-style normal; font-weight 350; src url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/10/NotoSansCJKjp-DemiLight.woff2) format( woff2 ), url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/9/NotoSansCJKjp-DemiLight.woff) format( woff ), url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/8/NotoSansCJKjp-DemiLight.ttf) format( truetype ); } @font-face { font-family Noto Sans JP ; font-display swap; font-style normal; font-weight bold; src url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/13/NotoSansCJKjp-Medium.woff2) format( woff2 ), url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/12/NotoSansCJKjp-Medium.woff) format( woff ), url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2972/11/NotoSansCJKjp-Medium.ttf) format( truetype ); } rt { font-family Arial, Verdana, Helvetica, sans-serif; } /** Main table styling **/ #trackinfo, #lyrics { font-family Noto Sans JP , sans-serif; font-weight 350; } .track_number { font-family Rockwell; font-weight bold; } .track_number after { content . ; } #track_args, .amp_text { display none; } #trackinfo { position relative; float right; margin 0 0 1em 1em; padding 0.3em; width 320px; border-collapse separate; border-radius 5px; border-spacing 0; background-color #F9F9F9; font-size 90%; line-height 1.4em; } #trackinfo th { white-space nowrap; } #trackinfo th, #trackinfo td { border none !important; } #trackinfo thead th { background-color #D8D8D8; box-shadow 0 -3px #F9F9F9 inset; padding 4px 2.5em 7px; white-space normal; font-size 120%; text-align center; } .trackrow { background-color #F0F0F0; box-shadow 0 2px #F9F9F9 inset, 0 -2px #F9F9F9 inset; } #trackinfo td ul { margin 0; padding 0; list-style none; } #trackinfo li { line-height 16px; } #trackinfo li nth-of-type(n+2) { margin-top 6px; } #trackinfo dl { margin 0; } #trackinfo dt { font-size small; font-weight bold; } #trackinfo dd { margin-left 1.2em; } #trackinfo dd + dt { margin-top .5em; } #trackinfo_help { position absolute; top 3px; right 8px; font-size 80%; } /** Media styling **/ #trackinfo .media th { background-color #D8D8D8; padding 4px 0; font-size 95%; text-align center; } .media td { padding 0 2px; } .media iframe nth-of-type(n+2) { margin-top 0.3em; } .youtube + .nicovideo, .youtube + .soundcloud, .nicovideo + .soundcloud { margin-top 0.75em; } .media_section { display flex; align-items center; text-align center; } .media_section before, .media_section after { display block; flex-grow 1; content ; height 1px; } .media_section before { margin-right 0.5em; background linear-gradient(-90deg, #888, transparent); } .media_section after { margin-left 0.5em; background linear-gradient(90deg, #888, transparent); } .media_notice { color firebrick; font-size 77.5%; } /** Around track styling **/ .next-track { float right; } /** Infomation styling **/ #trackinfo .info_header th { padding .3em .5em; background-color #D8D8D8; font-size 95%; } #trackinfo .infomation_show_btn_wrapper { float right; font-size 12px; user-select none; } #trackinfo .infomation_show_btn { cursor pointer; } #trackinfo .info_content td { padding 0 0 0 5px; height 0; transition .3s; } #trackinfo .info_content ul { padding 0; margin 0; max-height 0; list-style initial; transition .3s; } #trackinfo .info_content li { opacity 0; visibility hidden; margin 0 0 0 1.5em; transition .3s, opacity .2s; } #trackinfo .info_content.infomation_show td { padding 5px; height 100%; } #trackinfo .info_content.infomation_show ul { padding 5px 0; max-height 50em; } #trackinfo .info_content.infomation_show li { opacity 1; visibility visible; } #trackinfo .info_content.infomation_show li nth-of-type(n+2) { margin-top 10px; } /** Lyrics styling **/ #lyrics { font-size 1.06em; line-height 1.6em; } .not_in_card, .inaudible { display inline; position relative; } .not_in_card { border-bottom dashed 1px #D0D0D0; } .tooltip { display flex; visibility hidden; position absolute; top -42.5px; left 0; width 275px; min-height 20px; max-height 100px; padding 10px; border-radius 5px; background-color #555; align-items center; color #FFF; font-size 85%; line-height 20px; text-align center; white-space nowrap; opacity 0; transition 0.7s; -webkit-user-select none; -moz-user-select none; -ms-user-select none; user-select none; } .inaudible .tooltip { top -68.5px; } span hover + .tooltip { visibility visible; top -47.5px; opacity 0.8; transition 0.3s; } .inaudible span hover + .tooltip { top -73.5px; } .not_in_card span.hide { top -42.5px; opacity 0; transition 0.7s; } .inaudible .img { display inline-block; width 3.45em; height 1.25em; margin-right 4px; margin-bottom -3.5px; margin-left 4px; background-image url(https //img.atwikiimg.com/www31.atwiki.jp/touhoukashi/attach/2971/7/Inaudible.png); background-size contain; background-repeat no-repeat; } .not_in_card after, .inaudible .img after { content ; visibility hidden; position absolute; top -8.5px; left 42.5%; border-width 5px; border-style solid; border-color #555 transparent transparent transparent; opacity 0; transition 0.7s; } .not_in_card hover after, .inaudible .img hover after { content ; visibility visible; top -13.5px; left 42.5%; opacity 0.8; transition 0.3s; } .not_in_card after { top -2.5px; left 50%; } .not_in_card hover after { top -7.5px; left 50%; } .not_in_card.hide after { visibility hidden; top -2.5px; opacity 0; transition 0.7s; } /** For mobile device styling **/ .uk-overflow-container { display inline; } #trackinfo.mobile { display table; float none; width 100%; margin auto; margin-bottom 1em; } #trackinfo.mobile th { text-transform none; } #trackinfo.mobile tbody tr not(.media) th { text-align left; background-color unset; } #trackinfo.mobile td { white-space normal; } document.addEventListener( DOMContentLoaded , function() { use strict ; const headers = { title アルバム別曲名 , album アルバム , circle サークル , vocal Vocal , lyric Lyric , chorus Chorus , narrator Narration , rap Rap , voice Voice , whistle Whistle (口笛) , translate Translation (翻訳) , arrange Arrange , artist Artist , bass Bass , cajon Cajon (カホン) , drum Drum , guitar Guitar , keyboard Keyboard , mc MC , mix Mix , piano Piano , sax Sax , strings Strings , synthesizer Synthesizer , trumpet Trumpet , violin Violin , original 原曲 , image_song イメージ曲 }; const rPagename = /(?=^|.*