Re: peer address update payload

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   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.

=> 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.

   In contrast, Tero's proposal (which I include below for convenience)

=> 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.

   explicitly includes the source address in the notification payload.

=> 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.

   Unlike your proposal, his does not allow for the simultaneous updating
   of multiple SPI's.
   
=> 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

Francis.Dupont@enst-bretagne.fr