Subject: Re: [Mobike] 51 - spi collisions

From: <[email-masked]>
Date: Wed, 2 Nov 2005 15:30:23 +0200

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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Nov 2005 14:51:18 +0100

=> 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.

=> 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.

   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-masked]

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!
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike