RFC5996(IKEv2)_2

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の署名オクテットは下記で示される。

The responder's signed octets can be described as:
responderの署名オクテットは下記で示される。

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に示す。

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を送信する。

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構造。

「RFC5996(IKEv2)_2」をウィキ内検索

最終更新：2015年09月16日 00:36

今日	- 人
昨日	- 人
合計	- 人

Codeまとめby長谷川

メニュー

リンク

他のサービス

カウンター

更新履歴

RFC5996(IKEv2)_2