pMTU discovery

[David Woodhouse]

On Fri, 2012-06-08 at 21:54 +0200, Bernhard Schmidt wrote:
> 
> IPv6 with MTU 1492:
> 
> TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1428, pmtu 1500
> X-CSTP-MTU: 1335
> X-DTLS-MTU: 1386
> 
> IPv4 with MTU 1492:
> 
> TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1448, pmtu 1500
> X-CSTP-MTU: 1335
> X-DTLS-MTU: 1418
> 
> Can openconnect output the _sent_ HTTP headers somehow? 

It sends X-CSTP-MTU of 13 less than the lower of rcv_mss and snd_mss,
and X-CSTP-Base-MTU equal to the pmtu.

So it's sending 1355 and 1500 respectively in the above cases.

I think I see the problem. I tested this here by setting the outbound
MTU at my border router to 1300. That's *lower* than the TCP MSS set by
the ASA, so my client will have been sending oversized packets and it
will have received an ICMP 'too big' or 'fragmentation needed' response.
So it *knew* the pMTU, reported it correctly in the TCP_INFO response,
and all was good.

In your case, the MTU of 1492 is higher than the MSS that the server
sets on the TCP session. You're never *trying* to send a packet that
exceeds the MTU, so you never receive the ICMP, and you never know what
the path MTU is.

I don't really know how we could *discover* the path MTU except by
sending a packet that exceeds it, and waiting for the ICMP response...
that might never come if some idiot has filtered ICMP.

Does the Cisco client get it "right" in this situation? How? After
running 'ip route flush cache' can you capture the traffic (host $SERVER
or icmp or icmp6) and see precisely what it's doing?

I'm imagining some trick with sending a 1500-byte UDP packet to the
server before making the TCP connection... but that's horrid.


Also, what does the Cisco client do with the MTU of the actual tun0
interface, when the DTLS connection is made/broken? You can test this
firewalling all UDP to/from the server. Does it actually reduce the MTU
of the interface? Or *discard* packets which are too big for the CSTP
MTU, if they arrive while the DTLS is down? Discarding too-big packets
seems silly, since we don't have a good way to generate ICMP responses
(please tell me they aren't faking those!). I think the best option is
just to shove the large packets down the CSTP link even though we know
they'll end up fragmented over the Internet.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120608/c1431ee6/attachment.bin>