Re: a proposal of address management for IKEv2

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

 In your previous mail you wrote:

   Francis Dupont writes:
   > => for privacy issues, a standard secret peer address is better than
   > a hash because it obviously never lacks knowledge.
   
   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...

   > PS: the main question is about the implicit IPsec SA update mechanism
   > that I rejected and you seem to like to keep. What is the opinion of
   > the IPsec WG people?
   
   I think that implicit mechanism is very important and usefull for
   NAT-T case, and SHOULD or MUST NOT be used in the mobile-ip or
   multihoming case (where we can get proper security by explicit
   update). 

=> IMHO we should avoid to have two worlds, one with NAT-T enabled,
one with NAT-T disabled but with a dedicated mechanism for mobility
and multi-homing. But this is an architectural issue: it is not in the
scope of the IPsec WG and should be submitted to the IESG/IAB.
Until we get an advice from them, can we try to fix all the other
minor details (in fact what I suggested for this pre-last call)?

Thanks

Francis.Dupont@enst-bretagne.fr

PS: have we enough numbers about renumbering of flows through NATs.
For instance, the mean delay between two renumberings.