[strongSwan] using 500/tcp

[Tobias Brunner]

Hi Harald,

> AFAIU defragmentation is enabled in strongswan for incoming packages,
> anyway.

That's basically for IKEv1 where the first message may already be
fragmented and for misbehaving peers that send fragmented packets even
if it wasn't enabled explicitly.  It does not mean that the notify to
enable fragmentation is actually sent.  That's only the case if
`fragmentation` is enabled.

> I have enabled fragmentation explicitly yesterday (Stronswan 5.5.0).
> Unfortunately it didn't help. MacOS does fragment the package, using an MTU
> of 1500.

Actually, it seems to use a lower MTU.  The UDP packet is 1264 bytes:

> 19:56:21.450731 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), length 1318: (flowlabel 0x6067d, hlim 64, next-header UDP (17) payload length: 1264) 2001:db8:0:1:c1a8:d747:f5f0:d411.4500 > 2001:db8:0:2::63.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001: child_sa  ikev2_auth[I]:
>     (#53) [|v2IDi]
> 19:56:21.450799 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), length 1318: (flowlabel 0x6067d, hlim 255, next-header UDP (17) payload length: 1264) 2001:db8:0:1:c1a8:d747:f5f0:d411.4500 > 2001:db8:0:2::63.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001: child_sa  ikev2_auth[I]:
>     (#53)
> 19:56:21.450858 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), length 198: (flowlabel 0x6067d, hlim 255, next-header UDP (17) payload length: 144) 2001:db8:0:1:c1a8:d747:f5f0:d411.4500 > 2001:db8:0:2::63.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001: child_sa  ikev2_auth[I]:
>     (#53)

With the overhead of 40 bytes for the IPv6 header this is bigger than
the MTU of 1280, though.  Perhaps they actually used 1280 as limit but
did not correctly account for the overhead (e.g. only for an IPv4 header
of 20 bytes, or they forgot about the Non-ESP marker of 4 bytes, or the
padding that's required because of the 16 byte blocksize of AES-CBC).

Anyway, it's too big for your environment:

> 19:56:21.452772 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), length 1294: (hlim 64, next-header ICMPv6 (58) payload length: 1240) 2001:db8:0:1::2 > 2001:db8:0:1:c1a8:d747:f5f0:d411: [icmp6 sum ok] ICMP6, packet too big, mtu 1280
> 19:56:21.452775 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), length 1294: (hlim 64, next-header ICMPv6 (58) payload length: 1240) 2001:db8:0:1::2 > 2001:db8:0:1:c1a8:d747:f5f0:d411: [icmp6 sum ok] ICMP6, packet too big, mtu 1280

Interestingly, the capture does not show any retransmits and only one
IKE_AUTH request on the second try (the last small message).  Since that
message has still the same size I guess the IKE daemon did not adjust
the fragment size but that the messages were just fragmented on the IP
layer.  Anyway, it shows responses by strongSwan, so the messages
apparently came through.  It also shows that strongSwan correctly
fragments its response to a maximum size of 1280 for the complete IP
packet (the 8 byte difference to that theoretical maximum is due to the
16-byte blocksize):

> 19:56:40.244848 a4:d1:8c:e5:e8:50 > 80:ee:73:95:c1:0d, ethertype IPv6 (0x86dd), length 198: (flowlabel 0x6883d, hlim 255, next-header UDP (17) payload length: 144) 2001:db8:0:1:c1a8:d747:f5f0:d411.4500 > 2001:db8:0:2::63.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001: child_sa  ikev2_auth[I]:
>     (#53)
> 19:56:40.298766 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), length 1286: (flowlabel 0x698f7, hlim 54, next-header UDP (17) payload length: 1232) 2001:db8:0:2::63.4500 > 2001:db8:0:1:c1a8:d747:f5f0:d411.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001: child_sa  ikev2_auth[R]:
>     (#53) [|v2IDr]
> 19:56:40.299479 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), length 1286: (flowlabel 0x698f7, hlim 54, next-header UDP (17) payload length: 1232) 2001:db8:0:2::63.4500 > 2001:db8:0:1:c1a8:d747:f5f0:d411.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001: child_sa  ikev2_auth[R]:
>     (#53)
> 19:56:40.300929 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), length 1286: (flowlabel 0x698f7, hlim 54, next-header UDP (17) payload length: 1232) 2001:db8:0:2::63.4500 > 2001:db8:0:1:c1a8:d747:f5f0:d411.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001: child_sa  ikev2_auth[R]:
>     (#53)
> 19:56:40.301629 80:ee:73:95:c1:0d > a4:d1:8c:e5:e8:50, ethertype IPv6 (0x86dd), length 742: (flowlabel 0x698f7, hlim 54, next-header UDP (17) payload length: 688) 2001:db8:0:2::63.4500 > 2001:db8:0:1:c1a8:d747:f5f0:d411.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001: child_sa  ikev2_auth[R]:
>     (#53)

> Please note the delay. The Mac stops trying, i.e. I have to click on
> [Connect] again.

So I guess you could also just start the connection, then manually
disconnect (about when you are sure the IKE_AUTH requests were sent) and
then connect again.

> IMU MacOS should have recognized the icmp6 p-t-b
> and retried immediately, this time with a proper fragmentation.

It's strange that it does not seem to send any retransmits of the
IKE_AUTH message at all.  I guess these should already be fragmented
correctly.  Perhaps the ICMPs somehow change how retransmits are
handled/triggered by the IKE daemon.

> Using tcp the icmp6 p-t-b could have been handled on a lower network
> layer, hiding the fragmentation issues from the IKEv2 implementation.

That works the same for UDP.  But PMTUD often does not work reliably,
which is why a fragmentation on the IKE layer was added.

> Looking at this it appears to me that there is nothing I could do on
> the strongswan side. :-(

Nope.

Regards,
Tobias