[strongSwan] using 500/tcp

[Tobias Brunner]

Hi Harald,

As you noticed the IKE_AUTH packet is the one that's problematic.  But
since Mac OS X supports IKEv2 fragmentation

>         Notify (IKEv2 Fragmentation Supported) Payload:
>         No Data

there is really no reason not to enable it (unless you use an old
strongSwan version that does not support it yet).

>>> Looking at this I wonder if it is reasonable to ignore 500/tcp
>>> for Strongswan?
>>
>> Until [1] is standardized this won't change (it also requires kernel
>> changes for ESP in TCP encapsulation).
>>
> 
> Understood. Not to mention that the peer (MacOS) has to support
> it as well.

Yes, but Apple is one of the primary drivers behind this extension (the
main author actually works for Apple).  So I guess theirs will be one of
the first IKEv2 implementations to support it (but that will also depend
on their release cycle).

> I just wonder if you have any recommendations to avoid this delay?
> In the sample above the delay was just 3 seconds, but sometimes its
> 10 seconds or more.

What delay are you referring to exactly?  In the log you sent it looks
like the timespan between sending the IKE_SA_INIT request and giving up
because the IKE_AUTH response was not received is about 12 seconds.
I also wonder if the problem is the request or the response not getting
fragmented properly (you might want to check with tcpdump/Wireshark to
see who sends messages that are too large and where the ICMPs come from,
and if there are any retransmits).

> Once the MTU is known the IKEv2 negotiations work very well. I tried
> to ping6 the peer with -s 1500 before initiating the IPsec connection,
> but this did not help.

You might have to use the -m option on Mac OS X as it looks like the
packet will otherwise be fragmented at 1280 bytes (minimum IPv6 MTU).
Afterwards you can check the cached PMTU with `ip route get <IP>` on
Linux, and on Mac OS X `netstat -f inet6 -narl` should show the MTU for
cached routes.

Regards,
Tobias