Re: Secure remote access with IPsec

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

 In your previous mail you wrote:

   I was talking with Jari Arkko about this last night, and I came up
   with following 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).

=> note that when NAT-T is not activated we need an explicit protection
of the peer addresses (notifications like NAT-DETECTION-*-IP carrying
the full address and port) so the only guy who can put fake new addresses
is the peer.

   The explicit address update is done by sending
   SOURCE-ADDRESS-CHANGED notification, having new port and ip-address
   inside, to the other end.

=> so new port and address don't need to be inside the notification
because they are inside the (protected) message.

   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.
   
=> I disagree: there is no problem to require they are sent using
the new address.

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

=> I disagree: this return routability check should not be mandatory,
i.e., one MAY trust its peer. But IMHO it should be explained (as it
adds in fact nothing in the protocol it is free) and a config knob
should enable it. We have to provide the default value for this knob,
I am in favor of ON, i.e., perform the check by default.

   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.

=> fine

   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).
   
=> I disagree: we need more fine grain stuff for multi-homing.
What I propose is to put the list of affected SAs in the notification
with an "all SAs" flag which does exactly what you describe with
a restriction for proxy case SAs which must be never affected.

   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). 
   
=> is this text really useful?

   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.
   
=> agreed. IMHO this feature should be accessible from the outside of
the IKE implementation too.

   ----------------------------------------------------------------------
   
   Following text should be added to section 3.10.1 after
   HTTP-CERT-LOOKUP-SUPPORTED:
   
   ----------------------------------------------------------------------
   
   	SOURCE-ADDRESS-CHANGED		   	24587
   
               This
               notification is not used in the NAT traversal case, as the
               host behind NAT does not know when its address changes.

=> with the mandatory peer address protection when NAT-T is not activated
this statement is no more useful (because NAT-T and peer address protection
are exclusive and one of them is mandatory after the IKE_SA_INIT exchange).

I'll update my address management proposal (remove all the NAT-T stuff
and adopt a NAT-T vs. other case style) but IMHO we should put our
efforts on the things to clarify in the current draft, i.e., everything
about NAT-T & address management at the exclusion of the explicit
mechanism itself.

Thanks

Francis.Dupont@enst-bretagne.fr