Re: [RFC] Ethernet Cheap Cryptography

[stephen@dino.dnsalias.com (Stephen J. Bevan)]

David Miller writes:
 > From: stephen@dino.dnsalias.com (Stephen J. Bevan)
 > Date: Thu, 19 Oct 2006 19:18:41 -0700
 > 
 > > Pawel Foremski writes:
 > >  > Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE
 > >  > traffic, for example. 
 > > 
 > > Various, commercial, IPsec products decrease the MSS for TCP
 > > encapsulated in PPPoE.  I've not checked the Linux 2.6 IPsec code to
 > > see if it does or if it can easily be made to.
 > 
 > Linux will for local TCP connections over IPSEC transports since it
 > knows the path MTU, for IPSEC gateways the source system will adjust
 > the MSS after it notes via path-MTU what the decreased MTU is.

path-MTU gets interesting[1] in the context of an an IPsec gateway
(i.e. tunnel mode IPsec) and there is definitely variability as to how
reliably an ICMP will be returned in the case that the MTU is exceeded
somewhere between the two endpoints.  Throw in port/protocol based
selectors[2] or IPv4(IPv6) traffic encrypted with an IPv6(IPv4)
header[3] and the chances of success go down.

Users ussually don't tend to care whose IPsec is at fault, they just
want things to work.  Thus, having tunnel mode IPsec alter the MSS (of
non-local traffic) to take account of the encryption (or PPPoE,
... etc.) overhead smooths over most fragmentation issues.

----------
[1] as detailed in the length Appendix B of RFC 2401.

[2] some IPsec implementation won't correctly match an ICMP up against
    port/protocol based selectors and so the ICMP is lost.

[3] mapping the DF bit is left to implementations, some reset the DF
    bit and so just fragment.