3.10.1. Notify Message Types
Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process.
Notification informationはSAを確立できなかった理由を示すエラーメッセージを示すことができる。また、SA databaseを管理する処理(process)がpeer処理(process)との通信で希望するstatus dataも示すことができる。
The table below lists the Notification messages and their
corresponding values. The number of different error statuses was
greatly reduced from IKEv1 both for simplification and to avoid
giving configuration information to probers.
下表はNotification messageとそれに対応する値を示す。error statusの数は、簡略化、設定情報を調査者(probers)に与えるのを避けるため、IKEv1から大幅に減少された。
Types in the range 0 - 16383 are intended for reporting errors. An
implementation receiving a Notify payload with one of these types
that it does not recognize in a response MUST assume that the
corresponding request has failed entirely. Unrecognized error types
in a request and status types in a request or response MUST be
ignored, and they should be logged.
Type 0～16383はエラーを通知するために使用される。実装が認識しないNotify payload typeを受信した場合、対応するリクエストが失敗したと想定すること。request内の認識できないerror type、request or responseの認識できないstatus typeは無視し、ログに記録すること。
Notify payloads with status types MAY be added to any message and
MUST be ignored if not recognized. They are intended to indicate
capabilities, and as part of SA negotiation, are used to negotiate
non-cryptographic parameters.
status typeを持つNotify payloadは任意のメッセージに追加してよく、識別できない場合は無視すること。機能を示したり、SAネゴシエーションの一部として非暗号化パラメータをネゴシエーションするのに使用される。
More information on error handling can be found in Section 2.21.
error処理についてはSection 2.21を参照。
The values in the following table are only current as of the
publication date of RFC 4306, plus two error types added in this
document. Other values may have been added since then or will be
added after the publication of this document. Readers should refer
to [IKEV2IANA] for the latest values.
下表はRFC4306のものと、このドキュメントで追加されたものである。最新の値は[IKEV2IANA]参照。
NOTIFY messages: error types Value
-------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1
See Section 2.5.
INVALID_IKE_SPI 4
See Section 2.21.
INVALID_MAJOR_VERSION 5
See Section 2.5.
INVALID_SYNTAX 7
Indicates the IKE message that was received was invalid because
some type, length, or value was out of range or because the
request was rejected for policy reasons. To avoid a DoS
attack using forged messages, this status may only be
returned for and in an encrypted packet if the Message ID and
cryptographic checksum were valid. To avoid leaking information
to someone probing a node, this status MUST be sent in response
to any error not covered by one of the other status types.
To aid debugging, more detailed error information should be
written to a console or log.
type、length、値が範囲外またはポリシーリジェクトにより受信したIKEメッセージのrequestが拒否されて無効であったことを示す。偽造メッセージによるDoS攻撃を避けるため、Massage IDと暗号化checksumが有効だった場合にのみ、暗号化パケットで送信してもよい。ネットワークスキャンしている人に情報を漏れないようにするため、このステータスを他のエラーでカバーできないエラーとして送信すること。デバッグの支援のため、詳細な情報をコンソールに表示したりログに残してもよい。
INVALID_MESSAGE_ID 9
See Section 2.3.
INVALID_SPI 11
See Section 1.5.
NO_PROPOSAL_CHOSEN 14
None of the proposed crypto suites was acceptable. This can be
sent in any case where the offered proposals (including but not
limited to SA payload values, USE_TRANSPORT_MODE notify,
IPCOMP_SUPPORTED notify) are not acceptable for the responder.
This can also be used as "generic" Child SA error when Child SA
cannot be created for some other reason. See also Section 2.7.
提案されたcrypto suiteのいずれも許容しない。responderにofferするproposalが無い場合(SA payload value、USE_TRANSPORT_MODE notify、USE_TRANSPORT_MODE notify、それ以外も含む)にも使用してよい。Child SAが作成できない場合の一般的なChild SA errorに使用してもよい(Section 2.7を参照)。
INVALID_KE_PAYLOAD 17
See Sections 1.2 and 1.3.
AUTHENTICATION_FAILED 24
Sent in the response to an IKE_AUTH message when, for some reason,
the authentication failed. There is no associated data. See also
Section 2.21.2.
認証に失敗した場合、IKE_AUTHメッセージの応答として送信される。関連するデータは無い。
SINGLE_PAIR_REQUIRED 34
See Section 2.9.
NO_ADDITIONAL_SAS 35
See Section 1.3.
INTERNAL_ADDRESS_FAILURE 36
See Section 3.15.4.
FAILED_CP_REQUIRED 37
See Section 2.19.
TS_UNACCEPTABLE 38
See Section 2.9.
INVALID_SELECTORS 39
MAY be sent in an IKE INFORMATIONAL exchange when a node receives
an ESP or AH packet whose selectors do not match those of the SA
on which it was delivered (and that caused the packet to be
dropped). The Notification Data contains the start of the
offending packet (as in ICMP messages) and the SPI field of the
notification is set to match the SPI of the Child SA.
ノードはSelectorが設定したSAと一致しないESP/AHパケットを受信した場合、IKE INFORMATIONAL exchangeで送信してよい。Notification Dataは問題のパケットの開始(ICMPパケットのように：port unreachableみたいな)とChild SAのSPIに一致するSPI filedが含まれる。
TEMPORARY_FAILURE 43
See section 2.25.
CHILD_SA_NOT_FOUND 44
See section 2.25.
NOTIFY messages: status types Value
-------------------------------------------------------------------
INITIAL_CONTACT 16384
See Section 2.4.
SET_WINDOW_SIZE 16385
See Section 2.3.
ADDITIONAL_TS_POSSIBLE 16386
See Section 2.9.
IPCOMP_SUPPORTED 16387
See Section 2.22.
NAT_DETECTION_SOURCE_IP 16388
See Section 2.23.
NAT_DETECTION_DESTINATION_IP 16389
See Section 2.23.
COOKIE 16390
See Section 2.6.
USE_TRANSPORT_MODE 16391
See Section 1.3.1.
HTTP_CERT_LOOKUP_SUPPORTED 16392
See Section 3.6.
REKEY_SA 16393
See Section 1.3.3.
ESP_TFC_PADDING_NOT_SUPPORTED 16394
See Section 1.3.1.
NON_FIRST_FRAGMENTS_ALSO 16395
See Section 1.3.1.
3.11. Delete Payload
The Delete payload, denoted D in this document, contains a protocol-
specific Security Association identifier that the sender has removed
from its Security Association database and is, therefore, no longer
valid. Figure 17 shows the format of the Delete payload. It is
possible to send multiple SPIs in a Delete payload; however, each SPI
MUST be for the same protocol. Mixing of protocol identifiers MUST
NOT be performed in the Delete payload. It is permitted, however, to
include multiple Delete payloads in a single INFORMATIONAL exchange
where each Delete payload lists SPIs for a different protocol.
Delete payloadはDと表現され、送信者がSecurity Association Databaseから削除するSecurity Associatin identifierを含む。Figure 17はDelete payloadのフォーマットである。Delete payloadには複数のSPIを送信できるが、各SPIは同じプロトコルであること。異なるprotocol identifierがDelete payloadに複数含まれないこと。一つのINFORMATIONAL exchangeで異なるprotocol identifierをもつ複数のDelete payloadが含まれることは許容される。
Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but
no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the
IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI
is the SPI the sending endpoint would expect in inbound ESP or AH
packets.
IKE SAの削除は、Protocol ID 1(IKE)を含み、SPIを含まない。Child SA(2 for AH, 3 for ESP)の削除はSPIを含む。
The Delete payload is defined as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Num of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index(es) (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Delete Payload Format
o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3
for ESP.
o SPI Size (1 octet) - Length in octets of the SPI as defined by the
protocol ID. It MUST be zero for IKE (SPI is in message header)
or four for AH and ESP.
protocol IDのSPIオクテット長。IKEの場合は0であること。AH、ESPは4であること。
o Num of SPIs (2 octets, unsigned integer) - The number of SPIs
contained in the Delete payload. The size of each SPI is defined
by the SPI Size field.
Delete payloadに含まれるSPIの数。各SPIのサイズはSPI Size fieldで定義される。
o Security Parameter Index(es) (variable length) - Identifies the
specific Security Association(s) to delete. The length of this
field is determined by the SPI Size and Num of SPIs fields.
削除するSecrutiy AssociationのID。SPI Size field、Num of SPIでこのフィールド長は決まる。
The payload type for the Delete payload is forty-two (42).
Delete payloadのpayload typeは42である。
3.12. Vendor ID Payload
The Vendor ID payload, denoted V in this document, contains a vendor-
defined constant. The constant is used by vendors to identify and
recognize remote instances of their implementations. This mechanism
allows a vendor to experiment with new features while maintaining
backward compatibility.
Vendor ID payload、(Vと表記される)は、ベンダー定義の定数が含まれる。この定数はベンダーによって使用される。このメカニズムによりベンダーは後方互換を維持しながら新しい機能を使うことができる。
A Vendor ID payload MAY announce that the sender is capable of
accepting certain extensions to the protocol, or it MAY simply
identify the implementation as an aid in debugging. A Vendor ID
payload MUST NOT change the interpretation of any information defined
in this specification (i.e., the critical bit MUST be set to 0).
Multiple Vendor ID payloads MAY be sent. An implementation is not
required to send any Vendor ID payload at all.
Vendor ID payloadはデバッグの補助やプロトコル拡張に使用される。Vendor ID payloadは他の相互運用性に影響を与えないこと(例：Criticalは0に設定すること)。複数のVendor ID payloadが送信されてよい。
A Vendor ID payload may be sent as part of any message. Reception of
a familiar Vendor ID payload allows an implementation to make use of
private use numbers described throughout this document, such as
private payloads, private exchanges, private notifications, etc.
Unfamiliar Vendor IDs MUST be ignored.
Vendor ID payloadは任意のメッセージに含めてよい。対応しないVendor ID payloadは無視すること。
Writers of documents who wish to extend this protocol MUST define a
Vendor ID payload to announce the ability to implement the extension
in the document. It is expected that documents that gain acceptance
and are standardized will be given "magic numbers" out of the Future
Use range by IANA, and the requirement to use a Vendor ID will go
away.
このプロトコルを拡張する場合、拡張機能を実装する能力のためにVendor ID payloadを定義すること。機能が標準化された場合、Vendor IDは不要となり、IANAに番号が割り振られる。
The Vendor ID payload fields are defined as follows:
Vendor ID Payloadは下記のように定義される。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Vendor ID (VID) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Vendor ID Payload Format
o Vendor ID (variable length) - It is the responsibility of the
person choosing the Vendor ID to assure its uniqueness in spite of
the absence of any central registry for IDs. Good practice is to
include a company name, a person name, or some such information.
If you want to show off, you might include the latitude and
longitude and time where you were when you chose the ID and some
random input. A message digest of a long unique string is
preferable to the long unique string itself.
標準化されていないVendor IDを使用する場合、保証は使用者が行う。会社名、個人名などの情報を含めるのが望ましい。必要があればIDと乱数を選択した経緯と時刻を含めても良い。一意の長い文字列よりもそのメッセージダイジェストを設定したほうがよい。
Vednor ID。IDが標準で使用されていないことを保証するのは本payload使用者の責任である。会社名、個人名などの情報を含めるのが望ましい。長い文字列よりも長い文字列のメッセージダイジェストの方が望ましい。
The payload type for the Vendor ID payload is forty-three (43).
3.13. Traffic Selector Payload
The Traffic Selector payload, denoted TS in this document, allows
peers to identify packet flows for processing by IPsec security
services. The Traffic Selector payload consists of the IKE generic
payload header followed by individual Traffic Selectors as follows:
Traffic Selector paylaod(TS)により、ピアがIPsec security serviceで処理するフローを識別する。Traffic Selector payloadは以下のようにIKE generic payload headerと個々のTraffic Selectorで構成される。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Traffic Selectors> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Traffic Selectors Payload Format
o Number of TSs (1 octet) - Number of Traffic Selectors being
provided.
提供されるTraffic Selectorの数。
o RESERVED - This field MUST be sent as zero and MUST be ignored on
receipt.
0を設定し、受信側は無視すること。
o Traffic Selectors (variable length) - One or more individual
Traffic Selectors.
1以上の個別のTraffic Selector。
The length of the Traffic Selector payload includes the TS header and
all the Traffic Selectors.
Traffic Selector payloadのlengthにはTSヘッダとすべてのTraffic Selectorが含まれる。
The payload type for the Traffic Selector payload is forty-four (44)
for addresses at the initiator's end of the SA and forty-five (45)
for addresses at the responder's end.
initiarotのTraffic Selector payloadは44、responderは45である。
There is no requirement that TSi and TSr contain the same number of
individual Traffic Selectors. Thus, they are interpreted as follows:
a packet matches a given TSi/TSr if it matches at least one of the
individual selectors in TSi, and at least one of the individual
selectors in TSr.
TSi/TSrを同じ数含む必要はない。つまり、TSiの個々のセレクタのうち、少なくとも一つのTSi/TSrが一致する場合、パケットはそのTSi/TSrに一致する。
For instance, the following Traffic Selectors:
例えば下記のTS
TSi = ((17, 100, 198.51.100.66-198.51.100.66),
(17, 200, 198.51.100.66-198.51.100.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255),
(17, 400, 0.0.0.0-255.255.255.255))
would match UDP packets from 198.51.100.66 to anywhere, with any of
the four combinations of source/destination ports (100,300),
(100,400), (200,300), and (200, 400).
198.51.100.66から任意のアドレスへ送信されるUDPパケットは、source/dest portの組が(100,300),(100,400), (200,300), (200, 400)のいずれかにマッチする。
Thus, some types of policies may require several Child SA pairs. For
instance, a policy matching only source/destination ports (100,300)
and (200,400), but not the other two combinations, cannot be
negotiated as a single Child SA pair.
そのため、policyによっては複数のChild SA pairを必要とする。例えば、source/dstが(100,300)、(200,400)のみに一致するポリシーは他の2つの組み合わせに一致しないため、1つのChild SA pairではネゴシエーションできない。
3.13.1. Traffic Selector
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type |IP Protocol ID*| Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port* | End Port* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Starting Address* ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ending Address* ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Traffic Selector
*Note: All fields other than TS Type and Selector Length depend on
the TS Type. The fields shown are for TS Types 7 and 8, the only two
values currently defined.
TS TypeとSelector Length以外のfieldはTS typeによって異なる。TS typeは7、8のみが今のところ定義される。
o TS Type (one octet) - Specifies the type of Traffic Selector.
Traffic Selectorのタイプが規定される。
o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (such as UDP, TCP, and ICMP). A value of zero means
that the protocol ID is not relevant to this Traffic Selector --
the SA can carry all protocols.
IPプロトコルIDを指定する(例：UDP、TCP、ICMP)。0はプロトコルIDに依存せず、すべてのプロトコルに適用されることを示す。
o Selector Length - Specifies the length of this Traffic Selector
substructure including the header.
ヘッダを含めたTraffic Selector構造のlength。
o Start Port (2 octets, unsigned integer) - Value specifying the
smallest port number allowed by this Traffic Selector. For
protocols for which port is undefined (including protocol 0), or
if all ports are allowed, this field MUST be zero. ICMP and
ICMPv6 Type and Code values, as well as Mobile IP version 6
(MIPv6) mobility header (MH) Type values, are represented in this
field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type
and Code values are treated as a single 16-bit integer port
number, with Type in the most significant eight bits and Code in
the least significant eight bits. MIPv6 MH Type values are
treated as a single 16-bit integer port number, with Type in the
most significant eight bits and the least significant eight bits
set to zero.
Traffic Selectorで許可される最小のポート番号を指定する。ポートが未定義のプロトコル(protocol 0も含む)またはすべてのポートを許可する場合、0を設定すること。mobile ipv6(MIPv6) mobility header(MH) typeと同様にICMP, ICMPv6 type/ code valueはこのフィールドに設定される（Section 4.4.1.1）。
o End Port (2 octets, unsigned integer) - Value specifying the
largest port number allowed by this Traffic Selector. For
protocols for which port is undefined (including protocol 0), or
if all ports are allowed, this field MUST be 65535. ICMP and
ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
represented in this field as specified in Section 4.4.1.1 of
[IPSECARCH]. ICMP Type and Code values are treated as a single
16-bit integer port number, with Type in the most significant
eight bits and Code in the least significant eight bits. MIPv6 MH
Type values are treated as a single 16-bit integer port number,
with Type in the most significant eight bits and the least
significant eight bits set to zero.
Traffic Selectorで許可される最大のポート番号を指定する。ポートが未定義のプロトコル(protocol 0も含む)またはすべてのポートを許可する場合、65535を指定すること。
o Starting Address - The smallest address included in this Traffic
Selector (length determined by TS Type).
このTraffic Selectorに含まれる最小のアドレス。
o Ending Address - The largest address included in this Traffic
Selector (length determined by TS Type).
このTraffic Selectorに含まれる最大のアドレス。
Systems that are complying with [IPSECARCH] that wish to indicate
"ANY" ports MUST set the start port to 0 and the end port to 65535;
note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems
working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but
not "ANY" ports, MUST set the start port to 65535 and the end port to
0.
[IPSECARCH]に準拠するシステムで"ANY"を示す場合、start port 0、end port 65535を指定すること。
The Traffic Selector types 7 and 8 can also refer to ICMP or ICMPv6
type and code fields, as well as MH Type fields for the IPv6 mobility
header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets
have separate source and destination fields. The method for
specifying the Traffic Selectors for ICMP and MIPv6 is shown by
example in Section 4.4.1.3 of [IPSECARCH].
The following table lists values for the Traffic Selector Type field
and the corresponding Address Selector Data. 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.
下表にTraffic Selector Type fieldと対応するAddress Selector Dataを示す。RFC 4306の値。
最新の値なIKEV2IANA参照。
TS Type Value
-------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two four-octet
values. The first value is the beginning IPv4 address
(inclusive) and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.
2×4オクテットで表されるIPv4アドレスの範囲。開始アドレスと終了アドレスで、そのアドレス自体も含む。指定されたアドレスの範囲の値すべてを含む。
TS_IPV6_ADDR_RANGE 8
A range of IPv6 addresses, represented by two sixteen-octet
values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.
2×16オクテットで表されるIPv6アドレスの範囲。開始アドレスと終了アドレスで、そのアドレス自体も含む。指定されたアドレスの範囲の値すべてを含む。
3.14. Encrypted Payload
The Encrypted payload, denoted SK{...} in this document, contains
other payloads in encrypted form. The Encrypted payload, if present
in a message, MUST be the last payload in the message. Often, it is
the only payload in the message. This payload is also called the
"Encrypted and Authenticated" payload.
Encrypted payloadはSK{...}と表記する。暗号化された他のpaylaodが含まれる。Encrypted payloadがメッセージ内に存在する場合、メッセージの最後のpyalodであること。多くの場合、メッセージで唯一のpayloadになる。このpayloadは"Encrypted and Authenticated payload"とも呼ばれる。
The algorithms for encryption and integrity protection are negotiated
during IKE SA setup, and the keys are computed as specified in
Sections 2.14 and 2.18.
encryption/integrity protectionはIKE SAのsetupでネゴシエーションされ、Section 2.14、2.18の方法でキーが算出される。
This document specifies the cryptographic processing of Encrypted
payloads using a block cipher in CBC mode and an integrity check
algorithm that computes a fixed-length checksum over a variable size
message. The design is modeled after the ESP algorithms described in
RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
completely specifies the cryptographic processing of IKE data, but
those documents should be consulted for design rationale. Future
documents may specify the processing of Encrypted payloads for other
types of transforms, such as counter mode encryption and
authenticated encryption algorithms. Peers MUST NOT negotiate
transforms for which no such specification exists.
CBC modeのブロック暗号を使用したEncrypted payloadの暗号化処理と、可変長メッセージに対する固定長のチェックサムを計算するintegrity protectionチェックアルゴリズムを規定する。これは、RFC2104(HMAC), 4303(ESP), 2451(ESP CBC)のESPアルゴリズムをモデルにしている。今後、counter mode encryptionやauthenticated encryption algorithmが使用されてもよい。Peerは仕様として存在しないtransformをネゴシエーションしないこと。
When an authenticated encryption algorithm is used to protect the IKE
SA, the construction of the Encrypted payload is different than what
is described here. See [AEAD] for more information on authenticated
encryption algorithms and their use in ESP.
authenticated encryption algorithmがIKE SAを保護するために使用される場合、Encrypted payloadはここに定義されたものと異なる。authenticated encryption algorithmとESPについては[AEAD]を参照。
The payload type for an Encrypted payload is forty-six (46). The
Encrypted payload consists of the IKE generic payload header followed
by individual fields as follows:
Encrypted payloadは46のpayload typeである。
Encrypted payloadはIKE generic payload headerと各fieldで構成される。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (length is block size for encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Encrypted Payload Format
o Next Payload - The payload type of the first embedded payload.
Note that this is an exception in the standard header format,
since the Encrypted payload is the last payload in the message and
therefore the Next Payload field would normally be zero. But
because the content of this payload is embedded payloads and there
was no natural place to put the type of the first one, that type
is placed here.
最初に設定されているpayload type。Encrypted payloadはメッセージの最後のpayloadであるため、Next Payload fieldは0になるため、標準のheader formatとは異なる。最初に設定されたpayload typeを設定する適切な場所が無いため、ここに設定される。
o Payload Length - Includes the lengths of the header,
initialization vector (IV), Encrypted IKE payloads, Padding, Pad
Length, and Integrity Checksum Data.
header、IV、Encrypted IKE payload、Padding、Pad Length、Integrity Checksum Dataを含んだlength。
o Initialization Vector - For CBC mode ciphers, the length of the
initialization vector (IV) is equal to the block length of the
underlying encryption algorithm. Senders MUST select a new
unpredictable IV for every message; recipients MUST accept any
value. The reader is encouraged to consult [MODES] for advice on
IV generation. In particular, using the final ciphertext block of
the previous message is not considered unpredictable. For modes
other than CBC, the IV format and processing is specified in the
document specifying the encryption algorithm and mode.
CBC mode cipherでinitialization vector(IV)はencryption algorithmのブロック長に等しい。sendorは新しいIVを選択し、受信者はどんな値でも許容すること。IVの生成については[MODES]を参照。前のメッセージの最後の暗号ブロックを使用すると、予測される可能性がある。CBC以外ではIVの形式と処理は各ドキュメントに記載される。
o IKE payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher.
IKE payloadはこのSectionの前で規定されたpayloadである。このfieldはネゴシエーションされた暗号で暗号化される。
o Padding MAY contain any value chosen by the sender, and MUST have
a length that makes the combination of the payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher.
Paddingはsenderが任意の値を含めることができ、payload、Padding、Pad Lengthがencryption blockサイズの倍数になること。このfieldはネゴシエーションされた暗号で暗号化される。
o Pad Length is the length of the Padding field. The sender SHOULD
set the Pad Length to the minimum value that makes the combination
of the payloads, the Padding, and the Pad Length a multiple of the
block size, but the recipient MUST accept any length that results
in proper alignment. This field is encrypted with the negotiated
cipher.
Pad LengthはPadding filedのlengthである。senderはPadding、Pad Length、payloadが最小のブロックサイズになるようにPad Lengthを設定すること。受信者は任意のlengthを許容すること。このfieldはネゴシエーションされた暗号で暗号化される。
o Integrity Checksum Data is the cryptographic checksum of the
entire message starting with the Fixed IKE header through the Pad
Length. The checksum MUST be computed over the encrypted message.
Its length is determined by the integrity algorithm negotiated.
Integrity Checksum DataはPad LengthからFixed IKE headerまでの全体のメッセージのchecksumである。チェックサムはencryptedメッセージで計算されること。このlengthはネゴシエーションされたintegrity algorithmで決定される。
3.15. Configuration Payload
The Configuration payload, denoted CP in this document, is used to
exchange configuration information between IKE peers. The exchange
is for an IRAC to request an internal IP address from an IRAS and to
exchange other information of the sort that one would acquire with
Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly
connected to a LAN.
Configuration PayloadはCPと表記され、IKE peer間でconfiguration情報を交換するために使用される。IRAC(IPsec Remote Access Client)がInternal IP addressをIRAS(IPsec Remote Access Server)に要求したり、IRACがLANに接続したときにDHCPから取得するその他の情報を交換するためのexhangeである。
The Configuration payload is defined as follows:
Configuration payloadは下記のように定義される。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CFG Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Configuration Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Configuration Payload Format
The payload type for the Configuration payload is forty-seven (47).
o CFG Type (1 octet) - The type of exchange represented by the
Configuration Attributes. 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.
Configuration Attributeによって表されるexchangeのtype。最新の値は[IKEV2IANA]参照。
CFG Type Value
--------------------------
CFG_REQUEST 1
CFG_REPLY 2
CFG_SET 3
CFG_ACK 4
o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
receipt.
0を送信し、受信側は無視すること。
o Configuration Attributes (variable length) - These are type length
value (TLV) structures specific to the Configuration payload and
are defined below. There may be zero or more Configuration
Attributes in this payload.
Configuration payloadのtype length value(TLV)構造体で以下のように定義される。payloadには0個以上のConfiguration Attributeがある。
3.15.1. Configuration Attributes
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Configuration Attribute Format
o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt.
0を設定し、受信側は無視すること。
o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types.
Configuration Attribute Typeの一意の識別子。
o Length (2 octets, unsigned integer) - Length in octets of value.
オクテット長。
o Value (0 or more octets) - The variable-length value of this
Configuration Attribute. The following lists the attribute types.
このConfigurationの可変長の値。以下にattribute typeを示す。
The values in the following table are only current as of the
publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
INTERNAL_IP6_NBNS which were removed by this document). Other values
may have been added since then or will be added after the publication
of this document. Readers should refer to [IKEV2IANA] for the latest
values.
以下の値はRFC4306のものである。INTERNAL_ADDRESS_EXPIRY、INTERNAL_IP_NBNSは本書で削除された。最新の値は[IKEV2IANA]参照。
Attribute Type Value Multi-Valued Length
------------------------------------------------------------
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets
* These attributes may be multi-valued on return only if
multiple values were requested.
複数の値がrequestされた場合にのみ、responseに複数の値を設定できる。
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or private
address, and it MAY be a private address on the Internet. In a
request message, the address specified is a requested address (or
a zero-length address if no specific address is requested). If a
specific address is requested, it likely indicates that a previous
connection existed with this address and the requestor would like
to reuse that address. With IPv6, a requestor MAY supply the low-
order address octets it wants to use. Multiple internal addresses
MAY be requested by requesting multiple internal address
attributes. The responder MAY only send up to the number of
addresses requested. The INTERNAL_IP6_ADDRESS is made up of two
fields: the first is a 16-octet IPv6 address, and the second is a
one-octet prefix-length as defined in [ADDRIPV6]. The requested
address is valid as long as this IKE SA (or its rekeyed
successors) requesting the address is valid. This is described in
more detail in Section 3.15.3.
内部ネットワークのアドレス。red node address/private addressとも呼ばれる。requestでは要求するアドレスまたは特定のアドレスの要求がない場合は0 length addressが設定される。特定のアドレスが設定されるのは以前に使用したアドレスを再利用したいケース等。IPv6ではrequesterは使用したい下位アドレスのオクテットを要求してもよい。複数のinternal address attributesを要求することで、複数のinternal addressを要求できる。
responderは要求されたアドレス数以下しか送信できない。INTERNAL_IP6_ADDRESSは2つのフィールド（16-octet IPv6 address、one-octet prefix-length）で構成される。要求されたアドレスはアドレスを要求したIKE SA（rekeyも含む）が有効な間、有効である。詳細は3.15.3章。
o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
netmask is allowed in the request and response messages (e.g.,
255.255.255.0), and it MUST be used only with an
INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a
CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET
containing the same information ("send traffic to these addresses
through me"), but also implies a link boundary. For instance, the
client could use its own address and the netmask to calculate the
broadcast address of the link. An empty INTERNAL_IP4_NETMASK
attribute can be included in a CFG_REQUEST to request this
information (although the gateway can send the information even
when not requested). Non-empty values for this attribute in a
CFG_REQUEST do not make sense and thus MUST NOT be included.
internal networkのnetmask。request/responseで1つのnetmaskのみ使用できる（例：255.255.255.0）。INTERNAL_IP4_ADDRESS attributeでのみ使用できる。CFG_REPLYのINTERNAL_IP4_NETMASKはINTERNAL_IP4_SUBNETとほぼ同じことを意味するが、リンク境界(boundary)を意味する。
o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS
server within the network. Multiple DNS servers MAY be requested.
The responder MAY respond with zero or more DNS server attributes.
ネットワーク内のDNSサーバーのアドレス。複数のDNSサーバーを要求してもよい。responderは0個以上の DNS server attributesで応答してよい。
o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server
(WINS) within the network. Multiple NBNS servers MAY be
requested. The responder MAY respond with zero or more NBNS
server attributes.
ネットワーク内のNetBios Name Server(WINS) のアドレス。複数のNBNSサーバーを要求してもよい。resnponderは0個以上のNBNS server attributesで応答してよい。
o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
any internal DHCP requests to the address contained within the
attribute. Multiple DHCP servers MAY be requested. The responder
MAY respond with zero or more DHCP server attributes.
Attributeに含まれるアドレスへDHCP requestを送信する要求。複数のDHCPサーバーを要求してもよい。resnponderは0個以上のDHCP server attributesで応答してよい。
o APPLICATION_VERSION - The version or application information of
the IPsec host. This is a string of printable ASCII characters
that is NOT null terminated.
IPsecホストのバージョンまたはアプリケーション情報。NULL終端しない、ASCII文字列。
o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields: the
first being an IP address and the second being a netmask.
Multiple sub-networks MAY be requested. The responder MAY respond
with zero or more sub-network attributes. This is discussed in
more detail in Section 3.15.2.
このデバイスが保護するサブネットワーク。IPアドレスとnetmaskで構成される。複数のサブネットワークが要求されてもよい。responderは0個以上のsubnet attributeで応答してよい。詳細は3.15.2章参照。
o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
MUST be zero-length and specifies a query to the responder to
reply back with all of the attributes that it supports. The
response contains an attribute that contains a set of attribute
identifiers each in 2 octets. The length divided by 2 (octets)
would state the number of supported attributes contained in the
response.
request内ではlength 0であり、responserへのサポートするattributeのqueryを応答する。responseには2octetのattribute idを含むattributeが含まれる。length/2 octetにはresnponderがサポートするattribute数を設定する。
o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields: the
first is a 16-octet IPv6 address, and the second is a one-octet
prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY
be requested. The responder MAY respond with zero or more sub-
network attributes. This is discussed in more detail in
Section 3.15.2.
このデバイスが保護するサブネットワーク。16octetのIPv6 addressと1octetのプレフィックス長。複数のサブネットワークが要求されてもよい。responderは0個以上のsubnet attributeで応答してよい。詳細は3.15.2章参照。
Note that no recommendations are made in this document as to how an
implementation actually figures out what information to send in a
response. That is, we do not recommend any specific method of an
IRAS determining which DNS server should be returned to a requesting
IRAC.
本ドキュメントでは実装が送信する情報に関して規定はしない。例えば、IRACが要求したDNSサーバーを決定するIRASの決定方法は規定しない。
The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
information from its peer. If an attribute in the CFG_REQUEST
Configuration payload is not zero-length, it is taken as a suggestion
for that attribute. The CFG_REPLY Configuration payload MAY return
that value, or a new one. It MAY also add new attributes and not
include some requested ones. Unrecognized or unsupported attributes
MUST be ignored in both requests and responses.
CFG_REQUESTとCFG_REPLYのペアはIKE endpointがpeerから情報を要求できるようにする。CFG_REQUEST configuration paylaodがlength 0でない場合、要求として扱われる。CFG_REPLY configuration payloadは既存の値か新しい値を返してよい。要求に含まれない新しいattributeを追加してもよい。認識できないまたはサポートしていないattributeはrequest/responseどちらも無視すること。
The CFG_SET and CFG_ACK pair allows an IKE endpoint to push
configuration data to its peer. In this case, the CFG_SET
Configuration payload contains attributes the initiator wants its
peer to alter. The responder MUST return a Configuration payload if
it accepted any of the configuration data and it MUST contain the
attributes that the responder accepted with zero-length data. Those
attributes that it did not accept MUST NOT be in the CFG_ACK
Configuration payload. If no attributes were accepted, the responder
MUST return either an empty CFG_ACK payload or a response message
without a CFG_ACK payload. There are currently no defined uses for
the CFG_SET/CFG_ACK exchange, though they may be used in connection
with extensions based on Vendor IDs. An implementation of this
specification MAY ignore CFG_SET payloads.
CFG_SETとCFG_ACKのペアによりIKE endpointはconfigu dataをpeerにプッシュできる。CFG_SET configuration payloadにはinitiatorがpeerに設定するattributeが含まれる。responderはconfigurationを受け入れた場合、configuration payloadを返し、length 0で受け入れたattributeを返す。受け入れないattributeはCFG_ACK configurationに設定しないこと。受け入れられないattributeはresponderは空のCFG_ACK payloadかCFG_ACK payloadのないresponseで返すこと。CFG_SET/CFG_ACK exchangeに規定の使い方は無いが、Vendor IDの拡張で使用できる。本ドキュメントによる実装では、CFG_SET payloadを無視してもよい。
3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET
INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets,
ones that need one or more separate SAs, that can be reached through
the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET
attributes may also express the gateway's policy about what traffic
should be sent through the gateway; the client can choose whether
other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is
sent through the gateway or directly to the destination. Thus,
traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET
attributes should be sent through the gateway that announces the
attributes. If there are no existing Child SAs whose Traffic
Selectors cover the address in question, new SAs need to be created.
INTERNAL_IP4/6_SUBNET attributeは1つ以上の異なるSAを必要とするsubnetを示す。ゲートウェイのポリシーを表すこともできる。クライアントはトラフィックをゲートウェイ経由で送信するか、直接宛先に送信するかを選択できる。INTERNAL_IP4/6_SUBNETのアドレスへのトラフィックはattributeを通知するgatewayを介して送信される。トラフィックセレクタに特定のアドレスをカバーするchild SAが無い場合、新しいChild SAを作成する必要がある。
For instance, if there are two subnets, 198.51.100.0/26 and
192.0.2.0/24, and the client's request contains the following:
198.51.100.0/26 and 192.0.2.0/24のsubnetがある場合、クライアントの要求は下記になる。
CP(CFG_REQUEST) =
INTERNAL_IP4_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)
then a valid response could be the following (in which TSr and
INTERNAL_IP4_SUBNET contain the same information):
応答は下記になる。TSrとINTERNAL_IP4_SUBNETに同じ情報が含まれる。
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
(0, 0-65535, 192.0.2.0-192.0.2.255))
In these cases, the INTERNAL_IP4_SUBNET does not really carry any
useful information.
この場合、INTERNAL_IP4_SUBNETは有益な情報を含まない。
A different possible response would have been this:
異なる応答として下記がある。
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
That response would mean that the client can send all its traffic
through the gateway, but the gateway does not mind if the client
sends traffic not included by INTERNAL_IP4_SUBNET directly to the
destination (without going through the gateway).
この応答はclientが全てのトラフィックをゲートウェイ経由で送信できることを意味する。クライアントがINTERNAL_IP4_SUBNETに含まれていないトラフィックをゲートウェイを経由せずに宛先に直接送信するか、ゲートウェイは関与しない。
A different situation arises if the gateway has a policy that
requires the traffic for the two subnets to be carried in separate
SAs. Then a response like this would indicate to the client that if
it wants access to the second subnet, it needs to create a separate
SA:
ゲートウェイに2つのサブネットのトラフィックを別々のSAで送信する場合、下記が設定される。
クライアントに2番目のサブネットへのアクセスが必要になった場合に別のSA作成が必要である。
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)
INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
only part of the address space. For instance, if the client requests
the following:
INTERNAL_IP4_SUBNETはクライアントのTSrにアドレス空間の一部が含まれている場合にも使用される。
クライアントが下記の要求をした場合、
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
then the gateway's response might be:
ゲートウェイは下記を応答する。
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in
CFG_REQUESTs is unclear, they cannot be used reliably in
CFG_REQUESTs.
CFG_REQUESTのINTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNETの意味は明確でないため、使用しない。
3.15.3. Configuration Payloads for IPv6
The Configuration payloads for IPv6 are based on the corresponding
IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
things". In particular, IPv6 stateless autoconfiguration or router
advertisement messages are not used, neither is neighbor discovery.
Note that there is an additional document that discusses IPv6
configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an
experimental document, but there is a hope that with more
implementation experience, it will gain the same standards treatment
as this document.
IPv6 Configuration payloadはIPv4 configuration payloadをベースにしており、通常のIPv6に完全には準拠していない。特に、IPv6 stateless autoconfiguration, router advertisement、neighbor discoveryも使用されない。今後対応していくことを期待する。
A client can be assigned an IPv6 address using the
INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might
look like this:
INTERNAL_IP6_ADDRESS Configuration payloadを使用してクライアントにIPv6を割り当てられる。
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the
CFG_REQUEST to request a specific address or interface identifier.
The gateway first checks if the specified address is acceptable, and
if it is, returns that one. If the address was not acceptable, the
gateway attempts to use the interface identifier with some other
prefix; if even that fails, the gateway selects another interface
identifier.
クライアントはCFG_REQUESTに空でないINTERNAL_IP6_ADDRESS attributeを送信し、特定のアドレス、interface 識別子を要求してもよい。ゲートウェイはそのアドレスが許容できる場合は、そのアドレスを返す。許容できない場合、他のprefixでアドレスを返す。それでも失敗した場合、ゲートウェイは別のインターフェース識別子を使用する。
The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
field. When used in a CFG_REPLY, this corresponds to the
INTERNAL_IP4_NETMASK attribute in the IPv4 case.
INTERNAL_IP6_ADDRESSにはprefix fieldも含まれる。CFG_REPLYで使用される場合、IPv4の場合のINTERNAL_IP4_NETMASKに相当する。
Although this approach to configuring IPv6 addresses is reasonably
simple, it has some limitations. IPsec tunnels configured using
IKEv2 are not fully featured "interfaces" in the IPv6 addressing
architecture sense [ADDRIPV6]. In particular, they do not
necessarily have link-local addresses, and this may complicate the
use of protocols that assume them, such as [MLDV2].
IPv6アドレスを設定するアプローチにはいくつかの制限がある。IKEv2を使用して設定されたIPsecトンネルは、IPv6 [ADDRIPV6]の機能を完備しない。リンクローカルアドレスを必ずしももたないため、 [MLDV2]のようなプロトコルを使用するのが困難になる。
3.15.4. Address Assignment Failures
If the responder encounters an error while attempting to assign an IP
address to the initiator during the processing of a Configuration
payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.
The IKE SA is still created even if the initial Child SA cannot be
created because of this failure. If this error is generated within
an IKE_AUTH exchange, no Child SA will be created. However, there
are some more complex error cases.
Configuration payloadの処理中にresponderがinitiatorにIPアドレス割り当て中にエラーを検出すると、responderはINTERNAL_ADDRESS_FAILURE notificationで応答する。この問題により最初のChild SAを作成できない場合でもIKE SAは作成される。このエラーがIKE_AUTH exchange中に発生した場合、Child SAは作成されない。さらに複雑なケースが存在する。
If the responder does not support Configuration payloads at all, it
can simply ignore all Configuration payloads. This type of
implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
If the initiator requires the assignment of an IP address, it will
treat a response without CFG_REPLY as an error.
responderがconfiguration payloadをサポートしていない場合、全てのconfiguration payloadを無視してよい。この実装ではINTERNAL_ADDRESS_FAILURE notificationは送信されない。initiatorがIPアドレスの割当を必要とする場合、CFG_REPLY無しの応答をエラーとして処理する。
The initiator may request a particular type of address (IPv4 or IPv6)
that the responder does not support, even though the responder
supports Configuration payloads. In this case, the responder simply
ignores the type of address it does not support and processes the
rest of the request as usual.
initiatorはresponderがサポートしていないアドレスタイプ(IPv4/IPv6)を要求してもよい。responderはサポートしていないアドレスタイプを無視し、残りのリクエストを通常通り処理する。
If the initiator requests multiple addresses of a type that the
responder supports, and some (but not all) of the requests fail, the
responder replies with the successful addresses only. The responder
sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
initiarorがresponderがサポートしているタイプの複数のアドレスを要求し、一部のリクエストが失敗した場合、responderは成功したアドレスのみを応答する。responderはアドレスを全て割り当てることができない場合のみ、INTERNAL_ADDRESS_FAILUREを送信する。
If the initiator does not receive the IP address(es) required by its
policy, it MAY keep the IKE SA up and retry the Configuration payload
as separate INFORMATIONAL exchange after suitable timeout, or it MAY
tear down the IKE SA by sending a Delete payload inside a separate
INFORMATIONAL exchange and later retry IKE SA from the beginning
after some timeout. Such a timeout should not be too short
(especially if the IKE SA is started from the beginning) because
these error situations may not be able to be fixed quickly; the
timeout should likely be several minutes. For example, an address
shortage problem on the responder will probably only be fixed when
more entries are returned to the address pool when other clients
disconnect or when responder is reconfigured with larger address
pool.
initiatorが必要なIPアドレスを受信しなかった場合、適当なりトライ時間で、IKE SAを維持しConfiguration payloadをINFORMATIONAL exchangeで再試行するか、Delete payloadを送信してIKE SAを破棄して最初からやり直してもよい。このエラー状況は即座に解決しない可能性があるため、リトライ時間は数分程度とある程度長いことが望ましい。responderのアドレス不足の問題は、他のクライアントが切断された場合やより大きいアドレスプールが再設定された場合に解消する可能性がある。
3.16. Extensible Authentication Protocol (EAP) Payload
The Extensible Authentication Protocol payload, denoted EAP in this
document, allows IKE SAs to be authenticated using the protocol
defined in RFC 3748 [EAP] and subsequent extensions to that protocol.
When using EAP, an appropriate EAP method needs to be selected. Many
of these methods have been defined, specifying the protocol's use
with various authentication mechanisms. EAP method types are listed
in [EAP-IANA]. A short summary of the EAP format is included here
for clarity.
EAPと呼ばれる拡張認証プロトコルpayloadは、IKE SAがRFC3748で定義されたプロトコルとその他の拡張プロトコルによる認証を可能とする。EAPを使用する場合、適切なEAPメソッドを選択する必要がある。EAPメソッドには様々な認証メカニズム、プロトコルが定義される。EAP method typeは[EAP-IANA]に定義されている。簡易的なEAPフォーマットが含まれる。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ EAP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: EAP Payload Format
The payload type for an EAP payload is forty-eight (48).
EAP payloadのpayload typeは48。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 25: EAP Message Format
o Code (1 octet) indicates whether this message is a Request (1),
Response (2), Success (3), or Failure (4).
このメッセージがRequest (1)、Response (2)、Success (3)、Failure (4)か示す。
o Identifier (1 octet) is used in PPP to distinguish replayed
messages from repeated ones. Since in IKE, EAP runs over a
reliable protocol, it serves no function here. In a response
message, this octet MUST be set to match the identifier in the
corresponding request.
再送メッセージか連続メッセージか区別するためにPPPで使用される。IKEではEAPは信頼できるプロトコルで動作するため、この機能は使用されない。
o Length (2 octets, unsigned integer) is the length of the EAP
message and MUST be four less than the Payload Length of the
encapsulating payload.
EAPメッセージの長さであり、カプセル化payloadのPayload Lengthよりも4octet小さいこと。
o Type (1 octet) is present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. Note that since IKE passes an
indication of initiator identity in the first message in the
IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
requests (type 1). The initiator MAY, however, respond to such
requests if it receives them.
Code filedがRequest (1)、Response (2)の場合にのみ存在する。他のcodeではEAP message lengthは4 octetであり、Type、Type_Data fieldは存在しないこと。
o Type_Data (Variable Length) varies with the Type of Request and
the associated Response. For the documentation of the EAP
methods, see [EAP].
RequestのTypeと関連するResponseによって異なる。EAP methodのドキュメントについては[EAP]参照。
Note that since IKE passes an indication of initiator identity in the
first message in the IKE_AUTH exchange, the responder should not send
EAP Identity requests. The initiator may, however, respond to such
requests if it receives them.
IKEはIKE_AUTH exchangeの最初のメッセージでinitiator identiryを設定するため、responderはEAP identity requestを送信しないこと。initiatorは受信した場合、応答してもよい。
4. Conformance Requirements
In order to assure that all implementations of IKEv2 can
interoperate, there are "MUST support" requirements in addition to
those listed elsewhere. Of course, IKEv2 is a security protocol, and
one of its major functions is to allow only authorized parties to
successfully complete establishment of SAs. So a particular
implementation may be configured with any of a number of restrictions
concerning algorithms and trusted authorities that will prevent
universal interoperability.
IKEv2の全ての実装が相互運用できることを保証するため、サポートが必須である追加の要求事項がある。特定の目的をもつ実装では、相互運用をしない制限された構成もできる。
IKEv2 is designed to permit minimal implementations that can
interoperate with all compliant implementations. The following are
features that can be omitted in a minimal implementation:
IKEv2は最小限の実装を行い、相互運用するために省略できる機能は下記である。
o Ability to negotiate SAs through a NAT and tunnel the resulting
ESP SA over UDP.
NATを通してSAをネゴシエートし、UDPを通してESP SAをトンネリングする機能。
o Ability to request (and respond to a request for) a temporary IP
address on the remote end of a tunnel.
トンネルのリモートエンド上の一時的なIPアドレスを要求する機能。
o Ability to support EAP-based authentication.
EAPベースの認証をサポートする機能。
o Ability to support window sizes greater than one.
1以上のウィンドウサイズをサポートする機能。
o Ability to establish multiple ESP or AH SAs within a single IKE
SA.
1つのIKE SAに複数のESP/AH SAを確立する機能。
o Ability to rekey SAs.
SAをrekeyする機能。
To assure interoperability, all implementations MUST be capable of
parsing all payload types (if only to skip over them) and to ignore
payload types that it does not support unless the critical bit is set
in the payload header. If the critical bit is set in an unsupported
payload header, all implementations MUST reject the messages
containing those payloads.
相互運用性をサポートするためには、全ての実装はスキップしないpayloadはパースし、payload headerにcritical bitがセットされていなければサポートしないpayload typeを無視できること。critical bitがサポートされていないpayload headerに設定されている場合、全ての実装はそれらのpayloadを含むそのメッセージを拒否すること。
Every implementation MUST be capable of doing four-message
IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
one for ESP or AH). Implementations MAY be initiate-only or respond-
only if appropriate for their platform. Every implementation MUST be
capable of responding to an INFORMATIONAL exchange, but a minimal
implementation MAY respond to any request in the INFORMATIONAL
exchange with an empty response (note that within the context of an
IKE SA, an "empty" message consists of an IKE header followed by an
Encrypted payload with no payloads contained in it). A minimal
implementation MAY support the CREATE_CHILD_SA exchange only in so
far as to recognize requests and reject them with a Notify payload of
type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
expires (based on locally configured values of either lifetime or
octets passed), and implementation MAY either try to renew it with a
CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
create a new one. If the responder rejects the CREATE_CHILD_SA
request with a NO_ADDITIONAL_SAS notification, the implementation
MUST be capable of instead deleting the old SA and creating a new
one.
全ての実装は2つのSA(IKE SA, ESPorAH SA)を確立する4つのメッセージ、IKE_INIT, IKE_AUTH exchangeを行うことができること。実装は、プラットフォームに応じてinitiate only, responder onlyになってよい。
全ての実装はINFORMATIONAL exchangeに応答可能であること。ただし、最低限の実装ではINFORMATIONAL exchangeの任意の要求の空応答できること（IKE SAのコンテキスト内では、空のメッセージはIKE headerの後にpayloadの無いEncripted payloadが続く）。
最小限の実装では、NO_ADDITIONAL_SASのNOTIFICATION payloadで要求を拒否できる場合のみ、CREATE_CHILD_SA exchangeをサポートしてよい。
最小限の実装ではCREATE_CHILD_SA, INFORMATIONALを開始する必要がない。
SAが期限切れになった場合、実装はCREATE_CHILD_SAで更新するか、古いSAを削除して新しいものを削除してよい。responderがNO_ADDITIONAL_SAS notificationでCREATE_CHILD_SA requestを拒否した場合、実装は古いSAを削除して新しいSAを作成できること。
Implementations are not required to support requesting temporary IP
addresses or responding to such requests. If an implementation does
support issuing such requests and its policy requires using temporary
IP addresses, it MUST include a CP payload in the first message in
the IKE_AUTH exchange containing at least a field of type
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are
optional. If an implementation supports responding to such requests,
it MUST parse the CP payload of type CFG_REQUEST in the first message
in the IKE_AUTH exchange and recognize a field of type
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing
an address of the appropriate type, it MUST return a CP payload of
type CFG_REPLY containing an address of the requested type. The
responder may include any other related attributes.
実装では、一時的なIPアドレスの要求や応答をサポートする必要はない。実装がそのような要求をサポートし、ポリシーが一時的なIPアドレスの使用を必要とする場合、IKE_AUTH exchangeの最初のメッセージにINTERNAL_IP4_ADDRESSまたはINTERNAL_IP6_ADDRESSを含むCP payloadを含める必要がある。その他のフィールドは全てオプションである。
実装がそのような要求への応答をサポートする場合、IKE_AUTH exchangeの最初のメッセージのCFG_REQUESTのCPペイロードをパースし、INTERNAL_IP4_ADDRESS かINTERNAL_IP6_ADDRESSを認識する必要がある。適切なアドレスタイプのリースをサポートする場合、CFG_REPLYのCP payloadを返す。応答にはその他の関連するattributeも含まれる。
For an implementation to be called conforming to this specification,
it MUST be possible to configure it to accept the following:
この仕様に適合する実装をするためには以下を受け入れられること。
o Public Key Infrastructure using X.509 (PKIX) Certificates
containing and signed by RSA keys of size 1024 or 2048 bits, where
the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
ID_DER_ASN1_DN.
X.509(PKIX)を使用するPKI：1024bit or 2048bitのRSA keyを含む署名付きの証明書とID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, ID_DER_ASN1_DNでIDが設定される。
o Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR.
ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDRである共通鍵認証。
o Authentication where the responder is authenticated using PKIX
Certificates and the initiator is authenticated using shared key
authentication.
responderがPKIX証明書で認証され、initiatorが共通key認証で認証される認証。
5. Security Considerations
While this protocol is designed to minimize disclosure of
configuration information to unauthenticated peers, some such
disclosure is unavoidable. One peer or the other must identify
itself first and prove its identity first. To avoid probing, the
initiator of an exchange is required to identify itself first, and
usually is required to authenticate itself first. The initiator can,
however, learn that the responder supports IKE and what cryptographic
protocols it supports. The responder (or someone impersonating the
responder) can probe the initiator not only for its identity, but
using CERTREQ payloads may be able to determine what certificates the
initiator is willing to use.
このプロトコルは認証されていないpeerに設定情報の開示を最小限に抑えるように設計されているが、開示は避けられない。
peerは自身のidentityを最初に証明する必要がある。initiatorはresponderがIKEをサポートすること、サポートする暗号化プロトコルを知ることができる。responderおよびresponderの偽装者はinitiatorのidentityだけでなく、CERTREQ payloadを使用してinitiatorがどの証明書を使うか判断できる場合がある。
Use of EAP authentication changes the probing possibilities somewhat.
When EAP authentication is used, the responder proves its identity
before the initiator does, so an initiator that knew the name of a
valid initiator could probe the responder for both its name and
certificates.
EAP認証を使用すると、プローブされる可能性が多少変わる。EAP認証が使用される場合、responderはinitiatorが行う前にidentityを証明する(responder主導)。有効なinitiatorの名前を知っているinitiatorはresponderの名前と証明書を知ることができる。
Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
single key. Implementers should take note of this fact and set a
limit on CREATE_CHILD_SA exchanges between exponentiations. This
document does not prescribe such a limit.
追加の Diffie-Hellman鍵交換を行わずに、CREATE_CHILD_SAを繰り返し使用すると、全てのSAが単一の鍵の解読に対して脆弱になる。実装者はCREATE_CHILD_SAに制限を設定する必要がある。しかし、本文章ではそのような制限を規定しない。
The strength of a key derived from a Diffie-Hellman exchange using
any of the groups defined here depends on the inherent strength of
the group, the size of the exponent used, and the entropy provided by
the random number generator used. Due to these inputs, it is
difficult to determine the strength of a key for any of the defined
groups. Diffie-Hellman group number two, when used with a strong
random number generator and an exponent no less than 200 bits, is
common for use with 3DES. Group five provides greater security than
group two. Group one is for historic purposes only and does not
provide sufficient strength except for use with DES, which is also
for historic use only. Implementations should make note of these
estimates when establishing policy and negotiating security
parameters.
diffie-hellman鍵交換による鍵の強さは各種パラメーターに依存する。グループ2は3DESで使用するのが一般的。グループ5はグループ2よりセキュリティが高い。グループ1は不十分。実装ではこれらを考慮してセキュリティパラメーターをネゴシエーションすること。
Note that these limitations are on the Diffie-Hellman groups
themselves. There is nothing in IKE that prohibits using stronger
groups nor is there anything that will dilute the strength obtained
from stronger groups (limited by the strength of the other algorithms
negotiated including the PRF). In fact, the extensible framework of
IKE encourages the definition of more groups; use of elliptic curve
groups may greatly increase strength using much smaller numbers.
これらの制限はdiffie-hellmanグループ自体にある。強力なグループの使用を禁じることはない。
It is assumed that all Diffie-Hellman exponents are erased from
memory after use.
全てのdiffie-hellman exponentは使用後にメモリから消去されると想定される。
The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator
has been authenticated. As a result, an implementation of this
protocol needs to be completely robust when deployed on any insecure
network. Implementation vulnerabilities, particularly DoS attacks,
can be exploited by unauthenticated peers. This issue is
particularly worrisome because of the unlimited number of messages in
EAP-based authentication.
IKE_SA_INITとIKE_AUTHのexchangeはinitiatorが認証される前に実施される。その結果、プロトコルの実装は、安全でないネットワークに配置された場合に完全に堅牢である必要がある。脆弱性、特にDoS攻撃は認証されていないpeerに悪用される可能性がある。この問題には、EAPベースの認証では無制限のメッセージがあるため特に問題になる。
The strength of all keys is limited by the size of the output of the
negotiated PRF. For this reason, a PRF whose output is less than 128
bits (e.g., 3DES-CBC) MUST NOT be used with this protocol.
全てのキーの強度はネゴシエートされたPRFの出力サイズによって制限される。このため、出力PRFが128bit未満のPRF（例：3DES-CBC）をこのプロトコルで使用しないこと。
The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudorandom source
(see [RANDOMNESS]). Implementers should take care to ensure that use
of random numbers for both keys and nonces is engineered in a fashion
that does not undermine the security of the keys.
このプロトコルのセキュリティはランダム性に依存する。強力な乱数または適切にシードされた擬似乱数によって生成されること。実装者はkeyとnanceの両方の乱数がセキュリティを損なわないように設計すること。
For information on the rationale of many of the cryptographic design
choices in this protocol, see [SIGMA] and [SKEME]. Though the
security of negotiated Child SAs does not depend on the strength of
the encryption and integrity protection negotiated in the IKE SA,
implementations MUST NOT negotiate NONE as the IKE integrity
protection algorithm or ENCR_NULL as the IKE encryption algorithm.
ネゴシエートされたchild SAのセキュリティはIKE SAでネゴシエートされた暗号化と完全性の保護の強度には依存しないが、IKE暗号化アルゴリズムとしてNONE、ENCR_NULLをネゴシエートしないこと。
When using pre-shared keys, a critical consideration is how to assure
the randomness of these secrets. The strongest practice is to ensure
that any pre-shared key contain as much randomness as the strongest
key being negotiated. Deriving a shared secret from a password,
name, or other low-entropy source is not secure. These sources are
subject to dictionary and social-engineering attacks, among others.
pre-shared keyを使用する場合、secretのランダム性を保証する方法が重要になる。最も良いプラクティスは、pre-shared keyには最も強度のあるkeyがネゴシエーションされるランダム性をを保証すること。password、name,等からpre-shared keyを生成することは安全ではない。これらは辞書攻撃やソーシャルエンジニアリング攻撃の対象になる。
The NAT_DETECTION_*_IP notifications contain a hash of the addresses
and ports in an attempt to hide internal IP addresses behind a NAT.
Since the IPv4 address space is only 32 bits, and it is usually very
sparse, it would be possible for an attacker to find out the internal
address used behind the NAT box by trying all possible IP addresses
and trying to find the matching hash. The port numbers are normally
fixed to 500, and the SPIs can be extracted from the packet. This
reduces the number of hash calculations to 2^32. With an educated
guess of the use of private address space, the number of hash
calculations is much smaller. Designers should therefore not assume
that use of IKE will not leak internal address information.
NAT_DETECTION_*_IP notifycationにはNAT配下にあるinternal IPのアドレスとポートのハッシュが含まれている。IPv4アドレス空間は32bitであるため、一致するハッシュを見つけることでNAT配下で使用されるIPを見つけることができる。ポート番号も通常は500固定のため、パケットからSPIを特定できる。これにより、ハッシュ計算数が2^32になる。private addressの知識があればハッシュ計算はさらに用意になる。従って、設計者はIKEを使用してもinternal addressが漏えいしないとは考えないこと。
When using an EAP authentication method that does not generate a
shared key for protecting a subsequent AUTH payload, certain man-in-
the-middle and server-impersonation attacks are possible [EAPMITM].
These vulnerabilities occur when EAP is also used in protocols that
are not protected with a secure tunnel. Since EAP is a general-
purpose authentication protocol, which is often used to provide
single-signon facilities, a deployed IPsec solution that relies on an
EAP authentication method that does not generate a shared key (also
known as a non-key-generating EAP method) can become compromised due
to the deployment of an entirely unrelated application that also
happens to use the same non-key-generating EAP method, but in an
unprotected fashion. Note that this vulnerability is not limited to
just EAP, but can occur in other scenarios where an authentication
infrastructure is reused. For example, if the EAP mechanism used by
IKEv2 utilizes a token authenticator, a man-in-the-middle attacker
could impersonate the web server, intercept the token authentication
exchange, and use it to initiate an IKEv2 connection. For this
reason, use of non-key-generating EAP methods SHOULD be avoided where
possible. Where they are used, it is extremely important that all
usages of these EAP methods SHOULD utilize a protected tunnel, where
the initiator validates the responder's certificate before initiating
the EAP authentication. Implementers should describe the
vulnerabilities of using non-key-generating EAP methods in the
documentation of their implementations so that the administrators
deploying IPsec solutions are aware of these dangers.
後続のAUTH payloadを保護するための共有鍵を生成しないEAP認証方式を使用する場合、MITMおよびサーバー偽装攻撃が可能である。これらの脆弱性はEAPが安全なトンネルで保護されていないプロトコルで使用されている場合に発生する。EAPはSSO等に使用される汎用的な認証プロトコルであるため、共有鍵を生成しないEAP認証方式は他の方法でキーを生成することもあるが、保護されていない場合は問題になる。この脆弱性はEAPに限らず、認証基盤が再利用されるシナリオでも発生する。例えば、EAP方式にトークンを使用する場合、中間者はWebサーバーを偽装してトークン認証を傍受し、IKEv2接続を開始できる。このため、鍵生成をしないEAPメソッドの使用はできる限り避けること。それらが使用される場合、EAP認証を開始する前にinitiatorがresponderの証明書を検証すること。実装者は非キー生成のEAPメソッドを使用していることを記述し、IPsecソリューションの管理者がこの危険性を認識できるようにすること。
An implementation using EAP MUST also use a public-key-based
authentication of the server to the client before the EAP
authentication begins, even if the EAP method offers mutual
authentication. This avoids having additional IKEv2 protocol
variations and protects the EAP data from active attackers.
EAPを使用する実装では、EAPが相互認証を提供していても、EAP認証の前にサーバーによるクライアントの公開鍵ベースの認証をすること。これにより、攻撃者からEAPデータを保護できる。
If the messages of IKEv2 are long enough that IP-level fragmentation
is necessary, it is possible that attackers could prevent the
exchange from completing by exhausting the reassembly buffers. The
chances of this can be minimized by using the Hash and URL encodings
instead of sending certificates (see Section 3.6). Additional
mitigations are discussed in [DOSUDPPROT].
IKEv2のメッセージが長く、IPレベルのフラグメントが必要な場合、攻撃者はリアセンブルバッファを使い切ることによるexchangeを完了させない攻撃が可能である。3.6章の証明書の代わりにハッシュとURLを使用することで抑えることができる。※不正にURLアクセスさせたりできそう。
Admission control is critical to the security of the protocol. For
example, trust anchors used for identifying IKE peers should probably
be different than those used for other forms of trust, such as those
used to identify public web servers. Moreover, although IKE provides
a great deal of leeway in defining the security policy for a trusted
peer's identity, credentials, and the correlation between them,
having such security policy defined explicitly is essential to a
secure implementation.
addmission制御は重要である。IKEピアを識別するのに使用されるトラストアンカーは公開Webサーバーを識別するためのものをは異なると思われる。IKEではID、資格情報等の様々なセキュリティポリシーを定義できる。実装ではそのようなポリシーを明示的に設計することが不可欠である。
5.1. Traffic Selector Authorization
IKEv2 relies on information in the Peer Authorization Database (PAD)
when determining what kind of Child SAs a peer is allowed to create.
This process is described in Section 4.4.3 of [IPSECARCH]. When a
peer requests the creation of an Child SA with some Traffic
Selectors, the PAD must contain "Child SA Authorization Data" linking
the identity authenticated by IKEv2 and the addresses permitted for
Traffic Selectors.
IKEv2はpeerがどのような種類のchild SAを作成することができるかを決定する際に、Peer Authorization Database(PAD)の情報を使う。このプロセスは[IPSECARCH]4.4.3に記載されている。peerがtraffic selectorを持つChild SAの作成を要求するとき、PADはIKEv2によって認証されたIDとtraffic selectorに許可されたアドレスをリンクするChild SA Authorization Dataを含む。
For example, the PAD might be configured so that authenticated
identity "sgw23.example.com" is allowed to create Child SAs for
192.0.2.0/24, meaning this security gateway is a valid
"representative" for these addresses. Host-to-host IPsec requires
similar entries, linking, for example, "fooserver4.example.com" with
198.51.100.66/32, meaning this identity is a valid "owner" or
"representative" of the address in question.
例えば、認証されたID"sgw23.example.com"が192.0.2.0/24のchild SAを作成できるように、SeGWがこれらのアドレスの"representative"であるようにPADを作成する。
host2hostのIPsecでも同様のエントリを必要とする。"fooserver4.example.com"と 198.51.100.66/32をリンクする。これは、IDが対象のアドレスの"owner" or "representative" であることを意味する。
As noted in [IPSECARCH], "It is necessary to impose these constraints
on creation of child SAs to prevent an authenticated peer from
spoofing IDs associated with other, legitimate peers". In the
example given above, a correct configuration of the PAD prevents
sgw23 from creating Child SAs with address 198.51.100.66, and
prevents fooserver4 from creating Child SAs with addresses from
192.0.2.0/24.
[IPSECARCH]に記載のとおり、認証されたpeerが他の認証されたpeerに関連するIDの偽装を防ぐためにChild SAの作成に制約を設ける必要がある。上記の例では、PADの設定により、sgw23が198.51.100.66のChild SAを作成するのを防ぎ、fooserver4が192.0.2.0/24のアドレスをもつchild SAを作成するのを防ぐ。
It is important to note that simply sending IKEv2 packets using some
particular address does not imply a permission to create Child SAs
with that address in the Traffic Selectors. For example, even if
sgw23 would be able to spoof its IP address as 198.51.100.66, it
could not create Child SAs matching fooserver4's traffic.
特定のアドレスを使用してIKEv2パケットを送信するだけでは、そのアドレスをもつChild SAをトラフィックセレクタに作成する許可を意味しない。例えば、sgw23が198.51.100.66として偽装できたとしてもfooserver4のトラフィックに一致するchild SAを作成できない。
The IKEv2 specification does not specify how exactly IP address
assignment using Configuration payloads interacts with the PAD. Our
interpretation is that when a security gateway assigns an address
using Configuration payloads, it also creates a temporary PAD entry
linking the authenticated peer identity and the newly allocated inner
address.
IKEv2ではconfiguration payloadを使用するIPアドレス割り当てがPADとどのように連携するかを規定していない。SeGWがConfiguration payloadを使用してアドレスを割り当てると、認証されてpeer IDと新しく割り当てたinner IPをリンクする一時的なPADエントリが作成されると考えられる。
It has been recognized that configuring the PAD correctly may be
difficult in some environments. For instance, if IPsec is used
between a pair of hosts whose addresses are allocated dynamically
using DHCP, it is extremely difficult to ensure that the PAD
specifies the correct "owner" for each IP address. This would
require a mechanism to securely convey address assignments from the
DHCP server, and link them to identities authenticated using IKEv2.
一部の環境ではPADを正しく設定するのが困難な場合がある。例えば、DHCPを使用してアドレスが動的に割り当てられるホストのpeer間でIPsecが使用される場合、PADが各IPアドレスに対して正しいownerを指定することは難しい。DHCPサーバーからのアドレス割り当てを安全に伝え、IKEv2を使用して認証されたIDにそれをリンクするメカニズムが必要である。
Due to this limitation, some vendors have been known to configure
their PADs to allow an authenticated peer to create Child SAs with
Traffic Selectors containing the same address that was used for the
IKEv2 packets. In environments where IP spoofing is possible (i.e.,
almost everywhere) this essentially allows any peer to create Child
SAs with any Traffic Selectors. This is not an appropriate or secure
configuration in most circumstances. See [H2HIPSEC] for an extensive
discussion about this issue, and the limitations of host-to-host
IPsec in general.
この制限により、認証されたpeerがIKEv2パケットに使用されたのと同じアドレスを含むトラフィックセレクタを持つChild SAを作成できるように、一部のベンダーではPADを設定している。IPスプーフィングが可能な環境では、任意のpeerが任意のトラフィックセレクタをもつChild SAを作成できる。これはあまり安全な運用ではない。これらの問題については[H2HIPSEC] 参照。
6. IANA Considerations
[IKEV2] defined many field types and values. IANA has already
registered those types and values in [IKEV2IANA], so they are not
listed here again.
[IKEV2]には多くのフィールドタイプと値が定義されている。ここには再掲しない。
Two items have been removed from the IKEv2 Configuration Payload
Attribute Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY.
IKEv2 Configuration payload attribute typeからINTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRYの2つが削除された。
Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR
TYPES" registry are defined here that were not defined in [IKEV2]:
IKEv2パラメーターが2つ追加された。
43 TEMPORARY_FAILURE
44 CHILD_SA_NOT_FOUND
IANA has changed the existing IKEv2 Payload Types table from:
既存のIKEv2 payload Type tableを変更した。
46 Encrypted E [IKEV2]
to
46 Encrypted and Authenticated SK [This document]
IANA has updated all references to RFC 4306 to point to this
document.
7. Acknowledgements
Many individuals in the IPsecME Working Group were very helpful in
contributing ideas and text for this document, as well as in
reviewing the clarifications suggested by others.
The acknowledgements from the IKEv2 document were:
This document is a collaborative effort of the entire IPsec WG. If
there were no limit to the number of authors that could appear on an
RFC, the following, in alphabetical order, would have been listed:
Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt
Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John
Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero
Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer
Reingold, and Michael Richardson. Many other people contributed to
the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
each of which has its own list of authors. Hugh Daniel suggested the
feature of having the initiator, in message 3, specify a name for the
responder, and gave the feature the cute name "You Tarzan, Me Jane".
David Faucher and Valery Smyslov helped refine the design of the
Traffic Selector negotiation.
8. References
8.1. Normative References
[ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[ADDRIPV6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[AEAD] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008.
[AESCMACPRF128]
Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
PRF-128) Algorithm for the Internet Key Exchange Protocol
(IKE)", RFC 4615, August 2006.
[AESXCBCPRF128]
Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006.
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[IKEV2IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org>.
[IPSECARCH]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[MUSTSHOULD]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[UDPENCAPS]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[URLS] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
8.2. Informative References
[AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[ARCHGUIDEPHIL]
Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[ARCHPRINC]
Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[DES] American National Standards Institute, "American National
Standard for Information Systems-Data Link Encryption",
ANSI X3.106, 1983.
[DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n. 6, June 1977.
[DIFFSERVARCH]
Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DIFFSERVFIELD]
Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[DIFFTUNNEL]
Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[DOSUDPPROT]
C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
for UDP-based protocols", ACM Conference on Computer and
Communications Security, October 2003.
[DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard",
Draft FIPS 186-3, June 2008.
[EAI] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008.
[EAP-IANA] "Extensible Authentication Protocol (EAP) Registry: Method
Types", <http://www.iana.org>.
[EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in
Tunneled Authentication Protocols", November 2002,
<http://eprint.iacr.org/2002/163>.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[EXCHANGEANALYSIS]
R. Perlman and C. Kaufman, "Analysis of the IPsec key
exchange Standard", WET-ICE Security Conference, MIT,
2001,
<http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>.
[H2HIPSEC] Aura, T., Roe, M., and A. Mohammed, "Experiences with
Host-to-Host IPsec", 13th International Workshop on
Security Protocols, Cambridge, UK, April 2005.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992.
[IDNA] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[IPSECARCH-OLD]
Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPV6CONFIG]
Eronen, P., Laganier, J., and C. Madson, "IPv6
Configuration in Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 5739, February 2010.
[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[MAILFORMAT]
Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[MODES] National Institute of Standards and Technology, U.S.
Department of Commerce, "Recommendation for Block Cipher
Modes of Operation", SP 800-38A, 2001.
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[RANDOMNESS]
Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006.
[REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", December 2008,
<http://www.cacr.math.uwaterloo.ca/techreports/2008/
cacr2008-24.pdf>.
[ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec", RFC 5857, May 2010.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978.
[SHA] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard",
FIPS 180-3, October 2008.
[SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE
Protocols", Advances in Cryptography - CRYPTO 2003
Proceedings LNCS 2729, 2003, <http://
www.informatik.uni-trier.de/~ley/db/conf/crypto/
crypto2003.html>.
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security ,
1996.
[TRANSPARENCY]
Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
Appendix A. Summary of Changes from IKEv1
The goals of this revision to IKE are:
IKE改訂の目的は下記である。
1. To define the entire IKE protocol in a single document,
replacing RFCs 2407, 2408, and 2409 and incorporating subsequent
changes to support NAT Traversal, Extensible Authentication, and
Remote Address acquisition;
RFCs 2407、2408、2409を置き換え、NATトラバーサル、EAP、リモートアドレス取得の動作を組み込み、IKEプロトコル全体を1つのドキュメントで定義する。
2. To simplify IKE by replacing the eight different initial
exchanges with a single four-message exchange (with changes in
authentication mechanisms affecting only a single AUTH payload
rather than restructuring the entire exchange) see
[EXCHANGEANALYSIS];
8つの異なるinitial exchangeを1つの4 message exchangeで置き換えることでIKEを簡素化[EXCHANGEANALYSIS]。鍵交換全体を変更するのではなく、1つのAUTH payloadのみに影響がある。
3. To remove the Domain of Interpretation (DOI), Situation (SIT),
and Labeled Domain Identifier fields, and the Commit and
Authentication only bits;
DOI、SIT等のラベル付きドメイン識別フィールド、認証専用bitを削除する。
4. To decrease IKE's latency in the common case by making the
initial exchange be 2 round trips (4 messages), and allowing the
ability to piggyback setup of a Child SA on that exchange;
initial exchangeを2往復（4message）とし、そのexchangeでChild SAの確立をpiggybackできるようにしてIKEのレイテンシを削減する。
5. To replace the cryptographic syntax for protecting the IKE
messages themselves with one based closely on ESP to simplify
implementation and security analysis;
ESPに基いてIKEメッセージ自体を保護するための暗号化シンタックスを置き換えることで、実装、分析を容易にする。
6. To reduce the number of possible error states by making the
protocol reliable (all messages are acknowledged) and sequenced.
This allows shortening CREATE_CHILD_SA exchanges from 3 messages
to 2;
プロトコルの信頼性を全メッセージに確認応答することで高め、順序付けすることでエラー状態の下図を減らす。これにより、CREATE_CHILD_SA exchaneを3メッセージから2メッセージへ減らせる。
7. To increase robustness by allowing the responder to not do
significant processing until it receives a message proving that
the initiator can receive messages at its claimed IP address;
initiatorが要求されたIPアドレスでメッセージを受信できることを確認するまで、responderは重要な処理を行わない事によるロバスト性向上。
8. To fix cryptographic weaknesses such as the problem with
symmetries in hashes used for authentication (documented by Tero
Kivinen);
認証に使用されるハッシュの対称性に関する問題などの暗号的脆弱性を修正。
9. To specify Traffic Selectors in their own payloads type rather
than overloading ID payloads, and making more flexible the
Traffic Selectors that may be specified;
ID payloadのオーバーロードではなく、payload typeでトラフィックセレクタを設定することで、柔軟にトラフィックセレクタを指定できる。
10. To specify required behavior under certain error conditions or
when data that is not understood is received in order to make it
easier to make future revisions in a way that does not break
backward compatibility;
後方互換を損なわないため、特定のエラー条件、解析できないデータを受け取ったときの動作を規定。
11. To simplify and clarify how shared state is maintained in the
presence of network failures and DoS attacks; and
ネットワーク障害、DoS攻撃時に状態がどのように維持されるか明記、簡素化
12. To maintain existing syntax and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be
enhanced to support IKEv2 with minimum effort.
既存の構文、マジックナンバーをできるだけ維持し、IKEv1からIKEv2への移行を容易にする。
Appendix B. Diffie-Hellman Groups
There are two Diffie-Hellman groups defined here for use in IKE.
These groups were generated by Richard Schroeppel at the University
of Arizona. Properties of these primes are described in [OAKLEY].
The strength supplied by group 1 may not be sufficient for typical
uses and is here for historic reasons.
Additional Diffie-Hellman groups have been defined in [ADDGROUP].
B.1. Group 1 - 768-bit MODP
This group is assigned ID 1 (one).
The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
The generator is 2.
B.2. Group 2 - 1024-bit MODP
This group is assigned ID 2 (two).
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
The generator is 2.
Kaufman, et al. Standards Track [Page 133]
RFC 5996 IKEv2bis September 2010
Appendix C. Exchanges and Payloads
This appendix contains a short summary of the IKEv2 exchanges, and
what payloads can appear in which message. This appendix is purely
informative; if it disagrees with the body of this document, the
other text is considered correct.
このAppendixにはIKEv2 exchangeの概要とどのメッセージにどのpayloadが設定されるか記載されている。本文と一致しない場合、本文が正しい。
Vendor ID (V) payloads may be included in any place in any message.
This sequence here shows what are the most logical places for them.
Vendor ID (V) は任意のメッセージの任意の場所に含めることができる。一例として場所を記載する。
C.1. IKE_SA_INIT Exchange
request --> [N(COOKIE)],
SA, KE, Ni,
[N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)],
[V+][N+]
normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[V+][N+]
cookie response <-- N(COOKIE),
[V+][N+]
different Diffie- <-- N(INVALID_KE_PAYLOAD),
Hellman group [V+][N+]
wanted
C.2. IKE_AUTH Exchange without EAP
request --> IDi, [CERT+],
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
AUTH,
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+][N+]
response <-- IDr, [CERT+],
AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+][N+]
error in Child SA <-- IDr, [CERT+],
creation AUTH,
N(error),
[V+][N+]
Kaufman, et al. Standards Track [Page 135]
RFC 5996 IKEv2bis September 2010
C.3. IKE_AUTH Exchange with EAP
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+][N+]
first response <-- IDr, [CERT+], AUTH,
EAP,
[V+][N+]
/ --> EAP
repeat 1..N times |
\ <-- EAP
last request --> AUTH
last response <-- AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+][N+]
Kaufman, et al. Standards Track [Page 136]
RFC 5996 IKEv2bis September 2010
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs
request --> [N(REKEY_SA)],
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Ni, [KEi], TSi, TSr
[V+][N+]
normal <-- [CP(CFG_REPLY)],
response [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Nr, [KEr], TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)]
[V+][N+]
error case <-- N(error)
different Diffie- <-- N(INVALID_KE_PAYLOAD),
Hellman group [V+][N+]
wanted
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA
request --> SA, Ni, KEi
[V+][N+]
response <-- SA, Nr, KEr
[V+][N+]
C.6. INFORMATIONAL Exchange
request --> [N+],
[D+],
[CP(CFG_REQUEST)]
response <-- [N+],
[D+],
[CP(CFG_REPLY)]
Kaufman, et al. Standards Track [Page 137]
RFC 5996 IKEv2bis September 2010
最終更新：2018年01月01日 16:04
