[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
peer address update payload
Here is a proposal for the peer address update payload if
we decide to include it in the next IKEv2 draft. The modifs
are:
- an update of the section 1.4 (The INFORMATIONAL Exchange).
BTW IMHO we should split this section in three parts, a
general one, the next one about Deletes and the last one
about Updates.
- a new subsection at the end of section 3 (Header and Payload
Formats). Don't forget to update the last subsection (Other Payload
types) (:)!
As the format is simple (it was modelled after the Delete one),
I begin by it:
3.17 Peer Address Update Payload Format
The next figure 26 shows the format of the Peer Address Update
Payload. It is possible to send multiple SPIs in a Peer Address
Update payload, however, each SPI MUST be for the same
protocol. Mixing of Protocol Identifiers MUST NOT be performed in a
the Peer Address Update payload. It is permitted, however, to
include multiple Peer Address Update payloads in a single
INFORMATIONAL Exchange where each Peer Address Update payload lists
SPIs for a different protocol.
Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but
no SPIs. Update of a CHILD_SA, such as ESP or AH, will contain the
Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the
SPI the sending endpoint would expect in inbound ESP or AH packets.
The following diagram illustrates the content of the Peer Address
Update Notification:
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A| Protocol-ID ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Peer Address Update Payload Format
o All (1 bit) - MUST be set to one when all SAs (the IKE SA and
all non-proxy incoming IPsec SAs negotiated by it) are
updated. In this case the update is for the IKE-SA (Protocol-ID
0, SPI size 0, no SPI and number of SPIs 0).
MUST be set to zero when an individual SA is updated.
o Protocol_Id (7 bits) - Must be zero for an IKE_SA, 1 for
ESP, or 2 for AH.
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. 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 Peer
Address Update Notification. 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 lengths of these
fields are determined by the SPI Size and # of SPIs fields.
The payload type for the Peer Address Update Payload (in short
the Update (U) Payload) is seventeen (17).
3.18 Other Payload Types
Payload type values 18-127 are reserved to IANA for future assignment
in IKEv2 (see section 10). Payload type values 128-255 are for
private use among mutually consenting parties.
The text to add at the end of the section 1.4 (IMHO in the subsection
1.4.2 of a reorganized 1.4) is:
The explicit mechanism SHALL be used when NAT traversal support is
not active, i.e., when IKE runs over UDP port 500 with protected
peer addresses and only it this case. It has strong sequencing
requirements: as IKEv2 messages have a protected sequence number,
the only issue is the window of processing and pending exchanges.
Any INFORMATIONAL Exchange with a peer address update payload
MUST be processed in order.
When the receiver of an update request has to check the validity
of the new peer address, it MAY use a return routability check
sending an empty INFORMATIONAL message to the new address and
waiting for a response in a similar way to liveness checks (2.4).
The default policy SHOULD be to perform this check but a peer
MAY choose to directly accept updates.
When an SA is updated for a peer address, both members of the pair
MUST be updated. When SAs are nested, as when data (and IP headers
if in tunnel mode) are encapsulated first with IPcomp, then with
ESP, and finally with AH between the same pair of endpoints, all of
the SAs MUST be updated together. Each endpoint MUST update the SAs
it receives on and allow the other endpoint to update the other SA
in each pair.
To update a peer address of an SA, an Informational Exchange with
one or more peer address update payloads is sent listing the SPIs
(as they would be placed in the headers of inbound packets) of the
SAs to be updated. The recipient MUST update the designated SAs.
Normally, the reply in the Informational Exchange will contain peer
address update payloads for the paired SAs going in the other
direction. Note there is no special case for update collision,
and there is a simple way to handle the common case where all
SAs, i.e., the IKE SA and all non-proxy IPsec SAs negociated by it,
have to be updated.
Thanks
Francis.Dupont@enst-bretagne.fr
PS: if this is adopted, we need to update the introduction (abstract/
overview). The Update Payload adds the support for multi-homing and
a partial support for mobility (partial because the mobile-to-mobile
case with possible simultaneous handoffs needs more). BTW IKEv2 with
the Update Payload can do the same thing than unoptimized mobile IPv6!
PPS: about NAT-T text, I am waiting for the integration of Tero's
comments:
From: Tero Kivinen <kivinen@ssh.fi>
Subject: draft-ietf-ipsec-ikev2-05.txt comments
Message-ID: <15983.47777.849792.382994@ryijy.hel.fi.ssh.com>
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24164
Wed, 12 Mar 2003 17:52:04 -0500 (EST)