RFC 4306
Internet Key Exchange (IKEv2) Protocol
Pages: 99
Obsoletes: 2407 2408 2409
Obsoleted by: 5996
Updated by: 5282
Obsoletes: 2407 2408 2409
Obsoleted by: 5996
Updated by: 5282
Part 4 of 5 – Pages 64 to 87
3.10. Notify Payload
The Notify Payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify Payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL Exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request.
The Notify 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 ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Notify Payload Format o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE_SA, the SPI Size MUST be zero. o Notify Message Type (2 octets) - Specifies the type of notification message. o SPI (variable length) - Security Parameter Index. o Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Message Type. Values for this field are type specific (see below). The payload type for the Notify Payload is forty one (41).
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. 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. 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 except that they SHOULD be logged. 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. NOTIFY MESSAGES - ERROR TYPES Value ----------------------------- ----- RESERVED 0 UNSUPPORTED_CRITICAL_PAYLOAD 1 Sent if the payload has the "critical" bit set and the payload type is not recognized. Notification Data contains the one-octet payload type. INVALID_IKE_SPI 4 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. INVALID_MAJOR_VERSION 5 Indicates the recipient cannot handle the version of IKE specified in the header. The closest version number that the recipient can support will be in the reply header. 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 denial of service 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.
INVALID_MESSAGE_ID 9
Sent when an IKE message ID outside the supported window is
received. This Notify MUST NOT be sent in a response; the
invalid request MUST NOT be acknowledged. Instead, inform
the other side by initiating an INFORMATIONAL exchange with
Notification data containing the four octet invalid message
ID. Sending this notification is optional, and
notifications of this type MUST be rate limited.
INVALID_SPI 11
MAY be sent in an IKE INFORMATIONAL exchange when a node
receives an ESP or AH packet with an invalid SPI. The
Notification Data contains the SPI of the invalid packet.
This usually indicates a node has rebooted and forgotten an
SA. If this Informational Message is sent outside the
context of an IKE_SA, it should be used by the recipient
only as a "hint" that something might be wrong (because it
could easily be forged).
NO_PROPOSAL_CHOSEN 14
None of the proposed crypto suites was acceptable.
INVALID_KE_PAYLOAD 17
The D-H Group # field in the KE payload is not the group #
selected by the responder for this exchange. There are two
octets of data associated with this notification: the
accepted D-H Group # in big endian order.
AUTHENTICATION_FAILED 24
Sent in the response to an IKE_AUTH message when for some
reason the authentication failed. There is no associated
data.
SINGLE_PAIR_REQUIRED 34
This 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.
NO_ADDITIONAL_SAS 35
This error indicates that a CREATE_CHILD_SA request is
unacceptable because the responder is unwilling to accept any
more CHILD_SAs on this IKE_SA. Some minimal implementations may
only accept a single CHILD_SA setup in the context of an initial
IKE exchange and reject any subsequent attempts to add more.
INTERNAL_ADDRESS_FAILURE 36
Indicates an error assigning an internal address (i.e.,
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the
processing of a Configuration Payload by a responder. If this
error is generated within an IKE_AUTH exchange, no CHILD_SA will
be created.
FAILED_CP_REQUIRED 37
Sent by responder in the case where CP(CFG_REQUEST) was expected
but not received, and so is a conflict with locally configured
policy. There is no associated data.
TS_UNACCEPTABLE 38
Indicates that none of the addresses/protocols/ports in the
supplied traffic selectors is acceptable.
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 IPsec SA.
RESERVED TO IANA - Error types 40 - 8191
Private Use - Errors 8192 - 16383
NOTIFY MESSAGES - STATUS TYPES Value
------------------------------ -----
INITIAL_CONTACT 16384
This notification asserts that this IKE_SA is the only
IKE_SA currently active between the authenticated
identities. It MAY be sent when an IKE_SA is established
after a crash, and the recipient MAY use this information to
delete any other IKE_SAs it has to the same authenticated
identity without waiting for a timeout. This notification
MUST NOT be sent by an entity that may be replicated (e.g.,
a roaming user's credentials where the user is allowed to
connect to the corporate firewall from two remote systems at
the same time).
SET_WINDOW_SIZE 16385
This notification asserts that the sending endpoint is
capable of keeping state for multiple outstanding exchanges,
permitting the recipient to send multiple requests before
getting a response to the first. The data associated with a
SET_WINDOW_SIZE notification MUST be 4 octets long and
contain the big endian representation of the number of
messages the sender promises to keep. Window size is always
one until the initial exchanges complete.
ADDITIONAL_TS_POSSIBLE 16386
This notification asserts that the sending endpoint narrowed
the proposed traffic selectors but that other traffic
selectors would also have been acceptable, though only in a
separate SA (see section 2.9). There is no data associated
with this Notify type. It may be sent only as an additional
payload in a message including accepted TSs.
IPCOMP_SUPPORTED 16387
This notification 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 data associated with this notification 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.
The transform IDs currently defined are:
NAME NUMBER DEFINED IN
----------- ------ -----------
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2 RFC 2394
IPCOMP_LZS 3 RFC 2395
IPCOMP_LZJH 4 RFC 3051
values 5-240 are reserved to IANA. Values 241-255 are
for private use among mutually consenting parties.
NAT_DETECTION_SOURCE_IP 16388
This notification is used by its recipient to determine
whether the source is behind a NAT box. The data associated
with this notification is a SHA-1 digest of the SPIs (in the
order they appear in the header), IP address, and port on
which this packet was sent. There MAY be multiple Notify
payloads of this type in a message if the sender does not
know which of several network attachments will be used to
send the packet. The recipient of this notification MAY
compare the supplied value to a SHA-1 hash of the SPIs,
source IP address, and port, and if they don't match it
SHOULD enable NAT traversal (see section 2.23).
Alternately, it MAY reject the connection attempt if NAT
traversal is not supported.
NAT_DETECTION_DESTINATION_IP 16389
This notification is used by its recipient to determine
whether it is behind a NAT box. The data associated with
this 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. The recipient of this
notification MAY compare the supplied value to a hash of the
SPIs, destination IP address, and port, and if they don't
match it SHOULD invoke NAT traversal (see section 2.23). If
they don't match, it means that this end is behind a NAT and
this end SHOULD start sending keepalive packets as defined
in [Hutt05]. Alternately, it MAY reject the connection
attempt if NAT traversal is not supported.
COOKIE 16390
This notification MAY be included in an IKE_SA_INIT
response. It indicates that the request should be retried
with a copy of this notification as the first payload. This
notification MUST be included in an IKE_SA_INIT request
retry if a COOKIE notification was included in the initial
response. The data associated with this notification MUST
be between 1 and 64 octets in length (inclusive).
USE_TRANSPORT_MODE 16391
This notification MAY be included in a request message that
also includes an SA payload requesting a CHILD_SA. It
requests that the CHILD_SA use transport mode rather than
tunnel mode for the SA created. If the request is accepted,
the response MUST also include a notification of type
USE_TRANSPORT_MODE. If the responder declines the request,
the CHILD_SA will be established in tunnel mode. If this is
unacceptable to the initiator, the initiator MUST delete the
SA. Note: Except when using this option to negotiate
transport mode, all CHILD_SAs will use tunnel mode.
Note: The ECN decapsulation modifications specified in
[RFC4301] MUST be performed for every tunnel mode SA created
by IKEv2.
HTTP_CERT_LOOKUP_SUPPORTED 16392
This notification MAY be included in any message that can
include a CERTREQ payload and indicates that the sender is
capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive
certificate specifications in that format).
REKEY_SA 16393
This notification MUST be included in a CREATE_CHILD_SA
exchange if the purpose of the exchange is to replace an
existing ESP or AH SA. The SPI field identifies the SA
being rekeyed. There is no data.
ESP_TFC_PADDING_NOT_SUPPORTED 16394
This notification asserts that the sending endpoint will NOT
accept packets that contain Flow Confidentiality (TFC)
padding.
NON_FIRST_FRAGMENTS_ALSO 16395
Used for fragmentation control. See [RFC4301] for
explanation.
RESERVED TO IANA - STATUS TYPES 16396 - 40959
Private Use - STATUS TYPES 40960 - 65535
3.11. Delete Payload
The Delete Payload, denoted D in this memo, 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 a 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.
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.
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 ! # 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.
o # of SPIs (2 octets) - The number of SPIs contained in the Delete
payload. The size of each SPI is defined by the 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 # of SPIs fields.
The payload type for the Delete Payload is forty two (42).
3.12. Vendor ID Payload
The Vendor ID Payload, denoted V in this memo, 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.
A Vendor ID payload MAY announce that the sender is capable to
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.
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 memo -- private
payloads, private exchanges, private notifications, etc. Unfamiliar
Vendor IDs MUST be ignored.
Writers of Internet-Drafts who wish to extend this protocol MUST
define a Vendor ID payload to announce the ability to implement the
extension in the Internet-Draft. It is expected that Internet-Drafts
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.
The Vendor ID Payload fields are 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ 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. 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. 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 memo, 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: 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.
o RESERVED - This field MUST be sent as zero and MUST be ignored on
receipt.
o Traffic Selectors (variable length) - One or more individual
traffic selectors.
The length of the Traffic Selector payload includes the TS header and
all the traffic selectors.
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.
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.
o TS Type (one octet) - Specifies the type of traffic selector.
o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the
protocol ID is not relevant to this traffic selector -- the SA can
carry all protocols.
o Selector Length - Specifies the length of this Traffic Selector
Substructure including the header.
o Start Port (2 octets) - Value specifying the smallest port number
allowed by this Traffic Selector. For protocols for which port is
undefined, or if all ports are allowed, this field MUST be zero.
For the ICMP protocol, the two one-octet fields Type and Code are
treated as a single 16-bit integer (with Type in the most
significant eight bits and Code in the least significant eight
bits) port number for the purposes of filtering based on this
field.
o End Port (2 octets) - Value specifying the largest port number
allowed by this Traffic Selector. For protocols for which port is
undefined, or if all ports are allowed, this field MUST be 65535.
For the ICMP protocol, the two one-octet fields Type and Code are
treated as a single 16-bit integer (with Type in the most
significant eight bits and Code in the least significant eight
bits) port number for the purposed of filtering based on this
field.
o Starting Address - The smallest address included in this Traffic
Selector (length determined by TS type).
o Ending Address - The largest address included in this Traffic
Selector (length determined by TS type).
Systems that are complying with [RFC4301] that wish to indicate "ANY"
ports MUST set the start port to 0 and the end port to 65535; note
that according to [RFC4301], "ANY" includes "OPAQUE". Systems
working with [RFC4301] that wish to indicate "OPAQUE" ports, but not
"ANY" ports, MUST set the start port to 65535 and the end port to 0.
The following table lists the assigned values for the Traffic
Selector Type field and the corresponding Address Selector Data.
TS Type Value
------- -----
RESERVED 0-6
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.
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.
RESERVED TO IANA 9-240
PRIVATE USE 241-255
3.14. Encrypted Payload
The Encrypted Payload, denoted SK{...} or E in this memo, 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.
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.
The encryption and integrity protection algorithms are modeled after
the ESP algorithms described in RFCs 2104 [KBC96], 4303 [RFC4303],
and 2451 [ESPCBC]. This document completely specifies the
cryptographic processing of IKE data, but those documents should be
consulted for design rationale. We require a block cipher with a
fixed block size and an integrity check algorithm that computes a
fixed-length checksum over a variable size message.
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:
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. o Payload Length - Includes the lengths of the header, IV, Encrypted IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. o Initialization Vector - A randomly chosen value whose length is equal to the block length of the underlying encryption algorithm. Recipients MUST accept any value. Senders SHOULD either pick this value pseudo-randomly and independently for each message or use the final ciphertext block of the previous message sent. Senders MUST NOT use the same value for each message, use a sequence of values with low hamming distance (e.g., a sequence number), or use ciphertext from a received message. o IKE Payloads are as specified earlier in this section. This field is encrypted with the negotiated cipher. 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.
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.
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.
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 payloads are of type CFG_REQUEST/CFG_REPLY or
CFG_SET/CFG_ACK (see CFG Type in the payload description below).
CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE
request. The IKE response MUST include either a corresponding
CFG_REPLY or CFG_ACK or a Notify payload with an error type
indicating why the request could not be honored. An exception is
that a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET
payloads, so a response message without a corresponding CFG_REPLY or
CFG_ACK MUST be accepted as an indication that the request was not
supported.
"CFG_REQUEST/CFG_REPLY" 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. Requestors MUST ignore returned attributes that
they do not recognize.
Some attributes MAY be multi-valued, in which case multiple attribute
values of the same type are sent and/or returned. Generally, all
values of an attribute are returned when the attribute is requested.
For some attributes (in this version of the specification only
internal addresses), multiple requests indicates a request that
multiple values be assigned. For these attributes, the number of
values returned SHOULD NOT exceed the number requested.
If the data type requested in a CFG_REQUEST is not recognized or not supported, the responder MUST NOT return an error type but rather MUST either send a CFG_REPLY that MAY be empty or a reply not containing a CFG_REPLY payload at all. Error returns are reserved for cases where the request is recognized but cannot be performed as requested or the request is badly formatted. "CFG_SET/CFG_ACK" 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 minimal implementation of this specification MAY ignore CFG_SET payloads. Extensions via the CP payload SHOULD NOT be used for general purpose management. Its main intent is to provide a bootstrap mechanism to exchange information within IPsec from IRAS to IRAC. While it MAY be useful to use such a method to exchange information between some Security Gateways (SGW) or small networks, existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP] should be preferred for enterprise management as well as subsequent information exchanges. The Configuration 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 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.
CFG Type Value
=========== =====
RESERVED 0
CFG_REQUEST 1
CFG_REPLY 2
CFG_SET 3
CFG_ACK 4
values 5-127 are reserved to IANA. Values 128-255 are for private
use among mutually consenting parties.
o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
receipt.
o Configuration Attributes (variable length) - These are type length
values specific to the Configuration Payload and are defined
below. There may be zero or more Configuration Attributes in this
payload.
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.
o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types.
o Length (2 octets) - Length in octets of Value.
o Value (0 or more octets) - The variable-length value of this
Configuration Attribute.
The following attribute types have been defined:
Multi-
Attribute Type Value Valued Length
======================= ===== ====== ==================
RESERVED 0
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_ADDRESS_EXPIRY 5 NO 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
RESERVED 9
INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_NBNS 11 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.
Types 16-16383 are reserved to IANA. Values 16384-32767 are for
private use among mutually consenting parties.
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or
private address and MAY be a private address on the Internet.
In a request message, the address specified is a requested
address (or zero 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 bytes 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 sixteen-octet IPv6
address and the second is a one-octet prefix-length as defined
in [ADDRIPV6].
The requested address is valid until the expiry time defined
with the INTERNAL_ADDRESS EXPIRY attribute or there are no
IKE_SAs between the peers.
o INTERNAL_IP4_NETMASK - The internal network's netmask. Only
one netmask is allowed in the request and reply messages (e.g.,
255.255.255.0), and it MUST be used only with an
INTERNAL_IP4_ADDRESS attribute.
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.
o INTERNAL_IP4_NBNS, INTERNAL_IP6_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.
o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that
the host can use the internal IP address. The host MUST renew
the IP address before this expiry time. Only one of these
attributes MAY be present in the reply.
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.
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.
o INTERNAL_IP4_SUBNET - The protected sub-networks that this
edge-device protects. This attribute is made up of two fields:
the first is an IP address and the second is a netmask.
Multiple sub-networks MAY be requested. The responder MAY
respond with zero or more sub-network attributes.
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.
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 sixteen-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.
Note that no recommendations are made in this document as to how
an implementation actually figures out what information to send in
a reply. That is, we do not recommend any specific method of an
IRAS determining which DNS server should be returned to a
requesting IRAC.
3.16. Extensible Authentication Protocol (EAP) Payload
The Extensible Authentication Protocol Payload, denoted EAP in this
memo, allows IKE_SAs to be authenticated using the protocol defined
in RFC 3748 [EAP] and subsequent extensions to that protocol. The
full set of acceptable values for the payload is defined elsewhere,
but a short summary of RFC 3748 is included here to make this
document stand alone in the common cases.
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).
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).
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. In other messages, this field MAY be set
to any value.
o Length (2 octets) is the length of the EAP message and MUST be
four less than the Payload Length of the encapsulating payload.
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. The following types are defined in
RFC 3748:
1 Identity
2 Notification
3 Nak (Response Only)
4 MD5-Challenge
5 One-Time Password (OTP)
6 Generic Token Card
o Type_Data (Variable Length) varies with the Type of Request and
the associated Response. For the documentation of the EAP
methods, see [EAP].
Note that since IKE passes an indication of initiator identity in
message 3 of the protocol, the responder SHOULD NOT send EAP Identity
requests. The initiator SHOULD, however, respond to such requests if
it receives them.
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 is designed to permit minimal implementations that can
interoperate with all compliant implementations. There are a series
of optional features that can easily be ignored by a particular
implementation if it does not support that feature. Those features
include:
Ability to negotiate SAs through a NAT and tunnel the resulting
ESP SA over UDP.
Ability to request (and respond to a request for) a temporary IP
address on the remote end of a tunnel.
Ability to support various types of legacy authentication.
Ability to support window sizes greater than one.
Ability to establish multiple ESP and/or AH SAs within a single
IKE_SA.
Ability to rekey SAs.
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.
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 and/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 INFORMATIONAL message with
an empty INFORMATIONAL reply (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 closing the old SA and creating a new one.
Implementations are not required to support requesting temporary IP addresses or responding to such requests. If an implementation does support issuing such requests, it MUST include a CP payload in message 3 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 message 3 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 SHOULD include all of the other related attributes if it has them. A minimal IPv4 responder implementation will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute and will respond with the address and other related attributes regardless of whether the initiator requested them. A minimal IPv4 initiator will generate a CP payload containing only an INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring attributes it does not know how to use. The only attribute it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must use to bound the lifetime of the SA unless it successfully renews the lease before it expires. Minimal initiators need not be able to request lease renewals and minimal responders need not respond to them. For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: 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. Shared key authentication where the ID passes is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR. Authentication where the responder is authenticated using PKIX Certificates and the initiator is authenticated using shared key authentication.