Re: 51 - spi collisions

 In your previous mail you wrote:

   > => I am afraid it is not enough: the link issue is not the only
   > issue: if the SPD has no indication of what are the new endpoint
   > addresses to use after an update, one cannot guarantee a new SA
   > pair will be create using the right addresses. So an update
   > should impact something somewhere in the SPD.
   
   Currently, it's beyond the scope of MOBIKE how the initial
   contact is handled. Section 1.2 says:
   
=> I don't speak about the initial contact but the case where
there are many SPD entries requiring IPsec protection between
the two peers and only some of them have active IPsec SA pairs.
The peer addresses are somewhere in the SPD (this is highly
implementation dependent) and this information must be updated.

   In fact, if your manually configured SPD entry says that a certain
   IP address must be used when the SA is established, then that's
   the policy that must be followed, MOBIKE or not. 
   
=> this is not the issue, next paragraph seems better.

   If the IP address of the remote tunnel endpoint is not static,

=> they are not in MOBIKE.

   you need some kind of "rendezvous" mechanism for discovering it,

=> no, we need this only if they are dynamic at *both* sides.

   like DNS (but then the SPD entry that triggers the creation of the
   IKE_SA would contain the FQDN of the remote tunnel endpoint, not
   the IP address -- and this is what "remote access" VPN clients
   usually do, I guess).
   
=> the VPN client I use has the addresses of the VPN server. It doesn't
try DNS resolution because it tries to send no packets before
IKE/IPsec setup.

To come back to the main point, the peer addresses are dynamic and
included somewhere in the SPD or the PAD. The way this is supported
is very implementation dependent but the fact the information must be
updatable by MOBIKE is not at choice.

   > BTW a C pointer is not a good solution because there is no
   > one-to-one mapping between SPD and SAD.
   
   Well, it's many-to-one, so a pointer could work in the 
   SPD cache-to-SAD direction..?

=> but without a back pointer to patch it when the SAD changes is painful.

   But perhaps it's better not to
   say anything about C pointers in this document at all.
   
=> I agree.

Regards

[email protected]

PS: BTW this is not the first time we have this discussion on the list.
The problem is a detailed solution should be too implementation dependent
and too vague wording doesn't help.
But IMHO this is a critical issue: in fact the update the IPsec SAs is
less important than the update the peer addresses in the policy!