[strongSwan] MOBIKE

[Tobias Brunner]

Hi Patricia

>> In the current implementation charon as the initiator of a MOBIKE
>> exchange updates the IPsec SAs right after it determined a working
>> address pair.  At the same time, it sends the address update which
>> also includes a COOKIE2 payload, thus, is acting as routability
>> check.  The responder only updates the addresses of the IPsec SAs
>> after receiving an address update.  Since the observed ESP packet
>> and the address update do not necessarily have to arrive in that
>> order, it could very well be that the other peer successfully
>> receives the ESP packet.
>
> Is that defined in the IKEv2 RFC? where? It is interesting that
> responders could receive packets after update its IPsec SAs, but, if
> this is standardized by any RFC maybe there is no need to send the
> UPDATE_SA_ADDRESSES since the responder accepts every packet sent by the
> initator.

I'm not sure I completely understand your question.  Anyway, charon's 
behavior as described above is defined in RFC 4555 (MOBIKE), section 
3.5.  As far as the behavior for ESP traffic goes, this is handled by 
the Linux kernel.  For tunnel mode SAs the kernel currently accepts 
valid packets from any source.  But until the addresses in the kernel 
are updated the return path (outbound) will be invalid.  Traffic for 
transport mode SAs will be dropped, as the traffic selectors won't match 
until the addresses are update.  So the UPDATE_SA_ADDRESSES notification 
is definitely required (the addresses are not updated implicitly). 
Also, if the responder is multihomed and the initiator decides to use a 
different remote address, the ESP packets would also be dropped until 
the SAs are updated, because the kernel looks up IPsec SAs by SPI, 
protocol and destination address (i.e. the local address for inbound 
traffic).  I hope this answers your question.

Regards,
Tobias