<div dir="ltr">Thanks Tobias... That clears a lot...<div>Besides mobike, you mentioned that when exchange is done on 4500 and no NATT detected.</div><div>Strong swan sends ESP as non-UDP encapsulated.</div><div><br></div><div>Going by some reference earlier, I recall, even if no NATT detected and still initiator using port 4500 for Ikev2.</div><div>It can be taken as reference that initiator wants ESP traffc as UDP encapsulated, since many firewals/routes drop normal ESP packet and only explicit port are configured to be allowed...</div><div>Hence for ruling out such drop, ESP packet can be send as UDP encapsulated..</div><div><br></div><div>As such there is no hard-rule for this scenario, but going by study material I assume sending Tx data packet as UDP encapsulated is safe when Ikev2 exchange is done on 4500 even without NATT..</div><div><br></div><div>Thanks</div><div>Mukesh<br><div class="gmail_extra"><br><div class="gmail_quote">On 5 April 2016 at 13:57, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">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 Mukesh,<br>
<span class=""><br>
> Crux of this para is that if NAT traversal and mobike both are supported<br>
> at both IPsec end-points, then implementation shall change to port 4500.<br>
><br>
> Both peers support NAT traversal will be found at IKE_SA_INIT exchange<br>
> and Mobike support will be found after IKE_AUTH exchange is done..<br>
><br>
> In case of multi-round AUTH like EAP-AKA, initiator will get to know<br>
> responder's mobike capability in last round of IKE_Auth response when it<br>
> sends Mobike_supported as per RFC4555 Section 3.3<br>
<br>
</span>Correct.  As you point out what RFC 4555 mandates does not really work.<br>
<span class=""><br>
> Hence initiator will use port 4500 only for IKEv2 message after IKE_Auth<br>
> completion.<br>
<br>
</span>Or an initiator that supports MOBIKE will just always switch to port<br>
4500 when sending the first IKE_AUTH request.  That's what strongSwan<br>
does if MOBIKE is enabled and NAT-T is supported by the peer.  This is<br>
no problem and not directly related to UDP encapsulation of ESP, which<br>
strongSwan only uses if a NAT is actually detected.  As RFC 7296 puts it:<br>
<br>
  "An initiator can use port 4500 for both IKE and ESP, regardless of<br>
   whether or not there is a NAT, even at the beginning of IKE.  When<br>
   either side is using port 4500, sending ESP with UDP encapsulation is<br>
   not required, but understanding received UDP-encapsulated ESP packets<br>
   is required."<br>
<span class=""><br>
> I am doubtful regarding Responder behavior after IKE_AUTH completion..<br>
> Shall responder use port 4500 for any IKEv2 request/UDP encapsulated ESP<br>
> packet towards initiator right after IKE_AUTH completion or wait till<br>
> initiator sends some Ikev2 packet with port 4500...<br>
<br>
</span>The responder has no way of changing the ports, in particular, if the<br>
client is behind a NAT it can't know the port to which the client's port<br>
4500 will be mapped.  It just responds and initiates exchanges to the<br>
same endpoint from which it received the requests.  Or as RFC 7296 puts it:<br>
<br>
  "An implementation MUST<br>
   accept incoming requests even if the source port is not 500 or 4500,<br>
   and MUST respond to the address and port from which the request was<br>
   received.  It MUST specify the address and port at which the request<br>
   was received as the source address and port in the response."<br>
<br>
Regards,<br>
Tobias<br>
<br>
</blockquote></div><br></div></div></div>