Re: Secure remote access with IPsec

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

 In your previous mail you wrote:

   > => if it seems useful to permit this (IMHO it will be the case) then
   > NAT-T support will get a MUST.
   The reason why nat-t draft and than IKEv2 draft switch the communication 
   to port 4500 if a NAT is detected there is a NAT-T helper fuction which 
   does nottraslate UDP500 and that is implemented in a lot of NA(P)T. So 
   what's wrong to let IKev2 directly speak on port 4500 instead of 500?

=> nothing but the current draft wording suggests that IKE_SA_INIT
always runs over UDP 500. This should be fixed.

   If we let IKEv2 speak on port 500 and then switch to port 4500 if nat is 
   detected we should have collision problem during IKE_SA_INIT.
   
=> there is no collision problem with the same initiator, and collisions
where both sides are initiators are already handled by the rekeying stuff
(both in the draft and in this list).

   > => we cannot change the selectors of a SA without rekeying. And we shan't
   > change a traffic selector of a tunnel without rekeying.
   Why not? What's wrong with changing the selectors?
   
=> the term selector is not very accurate. You can't change the traffic
selectors but you can change the endpoints (i.e., the peer addresses)
with a peer address update mechanism.

   [from  draft-ietf-mobileip-mipv6-ha-ipsec-03.txt]
       Step 9.  If the mobile node and the HA have the capability to change
       the IKE endpoints, they change the address to C.  If they dont have
       the capability, both nodes remove their phase 1 connections created
       on top of the care-of address B and establish a new IKE phase 1 on
       top of the care-of address C.

=> this text applies only to IKEv1. In IKEv2 one should use the rekeying
mechanism for the IKE SA, both because it is available and because in
IKEv2 when an IKE SA is closed all the IPsec SAs it negociated are closed.

       This capability to change the IKE
       phase 1 end points is indicated through setting the Key Management
       Mobility Capability (K) flag [8] in the Binding Update and Binding
       Acknowledgement messages.
   
=> this is about peer address update mechanisms, in IKEv2 you'll get:
 - an implicit mechanism with NAT Traversal for peers which have
   the other peer behind a NAT.
 - an explicit mechanism defined after the urgent publication of the
   IKEv2 document.
 - a programmatic stuff which provides the peer address update itself
   for a set of SAs (an IKE SA and some IPsec SA pairs). It will be
   used of course by IKEv2 but I've suggested to make it available from
   the outside of the IKEv2 process(es).

Thanks

Francis.Dupont@enst-bretagne.fr