Hi again,<br><br><div class="gmail_quote">On 29 August 2011 17:56, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi Patricia,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can this packet be tunneled at that point? are initiator and responder<br>
updating the SAs after the liveness test? I think this packet should not<br>
be received through the tunnel until the handover process ends.<br>
<br>
Is the return routability check activated by default? by who?<br>
</blockquote>
<br></div>
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.<br>


<br></blockquote><div><br></div><div>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.</div>

<div> </div><div><br></div><div>Regards</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Regards,<br><font color="#888888">
Tobias<br>
</font></blockquote></div><br>