Re: 51 - spi collisions

Francis Dupont wrote:

>  In your previous mail you wrote:
> 
>       Storing the remote tunnel header IP address in the SPD
>       cache may also complicate the implementation of MOBIKE,
>       since the address can change during the lifetime of the
>       SA. Thus, we recommend implementing the links between the
>       SPD cache and the SAD in a way that does not require
>       modification when the tunnel header IP address is updated
>       by MOBIKE. For instance, in the C programming language, an
>       ordinary pointer could be used.
>    
>    Any comments?
>    
> => 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:

   The mobility support in MOBIKE allows both parties to move, but 
   does not provide a "rendezvous" mechanism that would allow [...] 
   discovering the addresses when the IKE_SA is first established.

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. 

If the IP address of the remote tunnel endpoint is not static, you
need some kind of "rendezvous" mechanism for discovering it, 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).

> PS: NAT-T and MIPv6 have the same issue. In NAT-T it is solved by
> making the initiator always behind the NAT (so the address can
> "float" as it is never used :-). In MIPv6 a solution is described
> in draft-sugimoto-mip6-pfkey-migrate-01.txt and in the real world
> an "unique" tag is used.

Yes, some kind of unique tag could be used instead of a pointer...

> 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 perhaps it's better not to
say anything about C pointers in this document at all.

Best regards,
Pasi