[strongSwan] Query for Mobike responder behavior

[Mukesh Yadav]

Thanks Tobias... That clears a lot...
Besides mobike, you mentioned that when exchange is done on 4500 and no
NATT detected.
Strong swan sends ESP as non-UDP encapsulated.

Going by some reference earlier, I recall, even if no NATT detected and
still initiator using port 4500 for Ikev2.
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...
Hence for ruling out such drop, ESP packet can be send as UDP encapsulated..

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

Thanks
Mukesh

On 5 April 2016 at 13:57, Tobias Brunner <tobias at strongswan.org> wrote:

> Hi Mukesh,
>
> > Crux of this para is that if NAT traversal and mobike both are supported
> > at both IPsec end-points, then implementation shall change to port 4500.
> >
> > Both peers support NAT traversal will be found at IKE_SA_INIT exchange
> > and Mobike support will be found after IKE_AUTH exchange is done..
> >
> > In case of multi-round AUTH like EAP-AKA, initiator will get to know
> > responder's mobike capability in last round of IKE_Auth response when it
> > sends Mobike_supported as per RFC4555 Section 3.3
>
> Correct.  As you point out what RFC 4555 mandates does not really work.
>
> > Hence initiator will use port 4500 only for IKEv2 message after IKE_Auth
> > completion.
>
> Or an initiator that supports MOBIKE will just always switch to port
> 4500 when sending the first IKE_AUTH request.  That's what strongSwan
> does if MOBIKE is enabled and NAT-T is supported by the peer.  This is
> no problem and not directly related to UDP encapsulation of ESP, which
> strongSwan only uses if a NAT is actually detected.  As RFC 7296 puts it:
>
>   "An initiator can use port 4500 for both IKE and ESP, regardless of
>    whether or not there is a NAT, even at the beginning of IKE.  When
>    either side is using port 4500, sending ESP with UDP encapsulation is
>    not required, but understanding received UDP-encapsulated ESP packets
>    is required."
>
> > I am doubtful regarding Responder behavior after IKE_AUTH completion..
> > Shall responder use port 4500 for any IKEv2 request/UDP encapsulated ESP
> > packet towards initiator right after IKE_AUTH completion or wait till
> > initiator sends some Ikev2 packet with port 4500...
>
> The responder has no way of changing the ports, in particular, if the
> client is behind a NAT it can't know the port to which the client's port
> 4500 will be mapped.  It just responds and initiates exchanges to the
> same endpoint from which it received the requests.  Or as RFC 7296 puts it:
>
>   "An implementation MUST
>    accept incoming requests even if the source port is not 500 or 4500,
>    and MUST respond to the address and port from which the request was
>    received.  It MUST specify the address and port at which the request
>    was received as the source address and port in the response."
>
> Regards,
> Tobias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160405/6676432e/attachment.html>