Re: a proposal of address management for IKEv2

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

 In your previous mail you wrote:

   >    If the this stays static it will leak out information (i.e make the
   >    tracking of user easy). Also you assume that the client will know if
   >    there is NAT beteen (i.e use secret peer address only when there is
   >    NAT, and otherwise use normal address). If there is no NAT then client
   >    must use his own address otherwise we enable NAT-T every time. 
   >    
   > => if there is no NAT the secret address will be as it in the packet
   > header and no more secret. So I assume that when someone wants to
   > keep it address secret it begins by insert a NAT in the path...
   
   Yes, but the client does not know if there is NAT between before it is
   tested, and it might not know if the address is secret or not if it is
   given by dhcp.

=> now I can see your problem.

   If we give out the static address always in the nat
   discovery protocol then there is no way to keep that address secret.

=> so obviously the address should not be in the discovery request.

   That was the reason the addresses are hashed in the NAT-T draft. 

=> I still don't believe this is the good solution. In fact the initiator
knows there is a NAT only with the reply: my proposal is to keep the
unspecified address as the secret one and to rely on the reply (which
will contain the address received by the responder). The only difference
is the responder can believe there is a NAT in the path when there is none
but we have to handle the case where a NAT is inserted or removed from
the path so this is not a problem...
BTW what is the best mechanism for the switch between ports 500 and 4500?

Thanks

Francis.Dupont@enst-bretagne.fr