Subject: peer address update payload

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Apr 2003 17:16:48 +0200

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

[email-masked]

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 <[email-masked]>
 Subject: draft-ietf-ipsec-ikev2-05.txt comments
 Message-ID: <[email-masked]>
 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24164
         Wed, 12 Mar 2003 17:52:04 -0500 (EST)

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 11 Apr 2003 16:23:02 -0400

>    The following diagram illustrates the content of the Peer Address

It's not clear to me where the address used to update the source addr
in the SA is coming from, since it is not specified in the packet.  If
you are assuming that it will be derived from the source address in
the IP header, this will be problematic since most implementations
will discard the packet upon initial verification of the IP header
and the SPI, long before they start processing the IKE payload.

In contrast, Tero's proposal (which I include below for convenience)
explicitly includes the source address in the notification payload.
Unlike your proposal, his does not allow for the simultaneous updating
of multiple SPI's.

						- Ted

--------------- Tero's proposal

2.25 Explicit Address Updating

For some cases there are needed for explicitly update the peer
address. This can be used to support mobile-ip, multihoming, and to
help SCTP support. The difference with implicit address updating, is
that in this case the other end can actually notify the other end
about the change in the address, and authenticate the new address (and
port). The explicit address update is done by sending
SOURCE-ADDRESS-CHANGED notification, having new port and ip-address
inside, to the other end. This notification can be send either using
the old or new address, but the sender MUST be able receive in the new
address before sending this out.

When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process
MUST check that the other end can receive the packets sent to new
address, by sending empty notification to the peer addres and port
given inside the notification (not the UDP outer address). When the
host requesting the change replies to that notification, and proofs
that it can actually receive packets sent to that address the actual
change should take effect. This change affects the IKE SA used to
receive the notification (i.e all future exchanges started on that IKE
SA will use this new address) and all child IPsec SAs created by this
IKE SA (i.e tunnel endpoint updated to new address).

The reply to the original SOURCE-ADDRESS-CHANGED notification is sent
back to the address where it was received, as is also all other
requests, where reply is not yet sent (i.e they follow normal rule,
that the reply is sent back to the address where the packet
originated). Note, that all hosts are required to process this
notification while waiting for reply to their SOURCE-ADDRESS-CHANGED
notification (see section 2.3). 

This requires implementations to support mutating the already existing
SAs (one way to implement this is to atomically delete the SA and then
add it back with new information). Similar feature is also needed for
the implicit address updating needed for NAT traversal, where we need
to update the UDP encapsulation addresses and ports.

----------------------------------------------------------------------

Following text should be added to section 3.10.1 after
HTTP-CERT-LOOKUP-SUPPORTED:

----------------------------------------------------------------------

	SOURCE-ADDRESS-CHANGED		   	24587

            This notification is sent when the other end has changed
            its IP-address and wants the responder of this
            notification to update the IKE SA remote peer address and
            port. When this notification is received the host MUST
            do the dead peer detection against the address given in
            this payload, and if that is successful then the IKE SA
            peer address and all the child SA tunnel endpoint
            addresses MUST be updated to new address. This
            notification is not used in the NAT traversal case, as the
            host behind NAT does not know when its address changes.
            The data associated with this notification is 2 byte port
            number and 4 or 16 byte IP-address.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Apr 2003 01:07:32 +0200

In your previous mail you wrote:

   
   It's not clear to me where the address used to update the source addr
   in the SA is coming from, since it is not specified in the packet.

=> argh! IP packets have no source addresses?
To be serious, perhaps the text should repeat this requirement
"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" which is after the format
description in my message but will be before in the draft.

   If you are assuming that it will be derived from the source address in
   the IP header, this will be problematic since most implementations
   will discard the packet upon initial verification of the IP header
   and the SPI, long before they start processing the IKE payload.
   
=> and where they get the addresses to setup tunnel mode SAs?
Where they get the addresses for sending responses? These implementations
don't interoperate correctly in IKEv1 and won't be compliant in IKEv2.

=> I know it: it is a subset of my proposal, it doesn't fix the
pseudo-NAT problem and is not powerful enough for multi-homing.

=> in my proposal the source address is in a mandatory peer address
protection notification, so there is no need to include it twice. BTW
these peer address protection notifications are in every messages
when the NAT traversal is not active so the source address cannot be
changed en route for other critical operations like a CREATE_CHILD_SA
exchange.

=> at the opposite his does allow only the simultaneous updating
of all SAs:
  "This change affects the IKE SA used to
   receive the notification (i.e all future exchanges started on that IKE
   SA will use this new address) and all child IPsec SAs created by this
   IKE SA (i.e tunnel endpoint updated to new address)."
This is a common case, covered in my proposal by the ALL flag, but this
is not the only case in multi-homed environments.
There is another difference, Tero's proposal works from the old souce
address but this will give only a win of 1/2 RTT in some cases at the
cost of 1 RTT for some others (cf the thread between me and Jari).

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Apr 2003 07:10:01 +0800

> we decide to include it in the next IKEv2 draft. The modifs

I am still not sure we need to have the ability to have different IP
address per each CHILD SA of the IKE SA. I think we should simply say
that if you want to modify the IP addresses of the CHILD SAs
independently then create them using separate IKE SAs. If you happen
to have all of the CHILD SAs created by one IKE SA and you want to
split them to two different classes, create another IKE SA and
recreate those CHILD SAs you want to move inside this new IKE SA and
delete them from the old IKE SA.

Or you can create each CHILD SA with separate IKE SA. 

I think it is simplier, and offeres same features than peer address
update payload. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Apr 2003 12:14:13 +0200

I am still not sure we need to have the ability to have different IP
   address per each CHILD SA of the IKE SA.

=> between multi-homed SGs this is very useful, both for resilience
to failures and for load sharing. In the mobile node to mobile node
case, one should like to setup an ESP tunnel using the care-of addresses
in the outer header but with an IKE SA running over the stable home
addresses: this is the easiest way to handle simultaneous handoffs.

   I think we should simply say
   that if you want to modify the IP addresses of the CHILD SAs
   independently then create them using separate IKE SAs.

=> this can be very expensive. I believe this trade-off was
intensely discussed when we decide to keep a two phase protocol,
i.e., the choice is to run *one* IKE SA between two peers.

   If you happen

=> I agree this gives the same level of flexibility.

=> I don't believe we agree about what is simplier. My opinion is
to use one IKE SA per IPsec SA group is against the rationale for
a two phase protocol...

Thanks