Re: peer address update payload

["Theodore Ts'o" <tytso@mit.edu>]

Francis, your proposal doesn't seem to any sense to me:

>    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)              ~
>        !                                                               !
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.