Re: [IPsec] New draft posted

[Yoav Nir <[e-mail]>]

This is why we need multiple vendors to look at this draft.

On Apr 26, 2010, at 2:29 PM, Tero Kivinen wrote:

> Yoav Nir writes:
>> I agree. And whatever we may think of the particular solution, it does present a problem that can and should be in the problem statement draft.
>> 
>> So how about adding teh following sub-section:
>> 
>> 3.7.  Different IP addresses for IKE and IPsec
>> 
>>   In many implementations there are separate IP addresses for the
>>   cluster, and for each member.  While the packets protected by tunnel
>>   mode child SAs are encapsulated in IP headers with the cluster IP
>>   address, the IKE packets originate from a specific member, and carry
>>   that member's IP address.  For the peer, this looks weird, as the
>>   usual thing is for the IPsec packets to come from the same IP address
>>   as the IKE packets.
> 
> Normally all ESP packets also have the members IP address as their
> outer address, so there is no problem. Both IKE and ESP packets have
> same address (provided the IKE and Child SAs are located on the same
> cluster member).

Actually, in our implementation, all packets (IKE and ESP) have the cluster IP address, so the peer doesn't notice a failover, and also the peer can't tell which member is "active" or which member it is working with.

> If the ESP packets have special handling that will change their outer
> source address to match cluster's IP address instead of individual
> member's IP address, then the same mechanims can easily be used for
> IKE SA too.

Not really. The IPsec stack constructs the ESP header and encapsulating IP header for tunnel mode SAs. It can put whatever external IP address it wants in there. IKE is handled by a user space process that opens a regular UDP socket and sends packets. To get those packets to have the cluster IP address, we need some special OS feature that allows you to override the IP stack, or a NAT mechanism to change the packets.


> 
>>   One obvious solution, is to use some fancy capability of the IKE host
>>   to change things so that IKE packets also come out of the cluster IP
>>   address.  This can be achieved through NAT or through assigning
>>   multiple addresses to interfaces.  This is not, however, possible for
>>   all implementations.
> 
> I would expect this to be one of those very basic systems provided by
> the cluster, so if cluster implementationdoes not offer such setup,
> then it most likely does not offer that for Child SAs either, thus
> there is no problem, as both ESP and IKE will use same IP (i.e.
> member's own IP). 

Again, for ESP, your code constructs the external source IP address, or it is a property of the child SA that the IKE process created.

> 
> We already have standard track mechanims for updating the outer
> address for both Child SAs and IKE (MOBIKE), so even when the
> cluster's outer IP address is used in normal case, the failover to
> another cluster member (using different IP address) is easy to do
> provided both the cluster member's share the same SA state.

MOBIKE was intended for mobile clients such as laptops and phones. It would be weird to use that for the enterprise gateway that uses clustering to improve scalability or availability. But in any case, at the moment we are only dealing with a problem statement. Solutions are yet to come.