> On Sat, Aug 07, 1999 at 06:18:21PM +0200, Richard Guy Briggs wrote:
> > > > Hmm. mss routing table attribute is only used by local TCP connections.
> > >
> > > Which is the point we care about. Transport mode. Im not quite sure why
> > > you are worried about tunnels - tunnels work, they always have
> >
> > Right, and this is why I would propose to send back ICMP from the
> > tunnel start point to the originating host for tunnel mode and prevent
> > the IPSEC stack from sending back ICMP in the case of a transport mode
> > encapsulation, letting the large mtu/small mss work its course.
>
> This does not make much sense. For what do you need the large MTU ?
To prevent any packets from being IP-fragmented (not to be mistaken
with TCP segmentation) *before* they arrive at the virtual IPSEC I/F.
If they are pre-fragmented and we transport encrypt those fragments, the
destination will attempt to re-assemble individually encrypted
fragments rather than decrypting the fragments, then re-assembling
them. We have no way to tell the destination the order of
re-asssembly/decryption. They should always be re-assembled before
decryption. To solve this, we encrypt the entire packet, then
fragment it. To avoid pre-fragmenting, we set the virtual MTU high
and the physical MTU to normal.
Each ESP, AH or IPIP IPSEC header adds anywhere from 20 to 28 octets
to the packet size, and all three may be added.
> If you lie to the stack about the MTU you'll only have to duplicate
> some work it'll otherwise do for you (like sending the ICMP or using
> reasonable initial MSS). And what gain would that duplicate work
> give you? Nothing.
If we don't lie, we have to re-assemble the fragments, encrypt,
re-fragment in transport mode.
> Fragmentation on the IPSec level is not interesting anyways, because
> it is rather useless:
>
> In transport mode DF will be near
> always set because TCP does path mtu discovery. You first set the MTU
> of your virtual device (or whatever implementation transport mode IPSec will
> chose) so that it starts with the correct MTU, if it doesn't workout
> for some reason [e.g. because the effective MTU changed] you use
> the error queue [ip_local_error] to inform TCP and the destination
> caache about the new MTU. This only works for shrinking MTUs, not increasing
> them ATM, in case this should be important for IPSec it can be added.
We can still respond to DF packets while giving a large MTU. The
large MTU is for the benefit of ICMP, UDP, IGMP, etc. which don't do
PMTUD.
> For transport mode UDP it is similar, either the stack will fragment
> for you automagically, or the application will use the pmtu discovery
> APIs Linux 2.2 offers. Doing magic fragmentation hacks would just cause
> problems. In case you updated the MTU and the stack does not know about
> it yet it is reasonable to use ip_local_error and simply drop it [there
> are even some cases in the regular stack where this can happen - ever
> seen the "sending pkt_too_big to self" message?]
I will have to digest this paragraph...
> For IPv6 this is even more important, because IPv6 only have end2end
> fragmentation and strongly encourages pmtu discovery.
I will have to check the IPSEC RFCs to see what happens here. IPSEC
is mandatory in a compliant IPv6 implementation.
> In short the big MTU/MSS hack is unnecessary and evil.
Can you suggest another way to send a ping of 2000 octets over a
transport mode connection with a physical MTU of 1500?
> -Andi
slainte mhath, RGB
- --
The first Ottawa Linux Symposium was a huge success! <ottawalinuxsymposium.org>
This SunRayce was a wet one! DroughtRelief_99? -- <www.sunrayce.com/sunrayce/>
Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada
<http://www.conscoop.ottawa.on.ca/rgb/> </www.flora.org/afo/>
Prevent Internet Wiretapping! -- FreeS/WAN:<www.xs4all.nl/~freeswan>
Thanks for voting Green! -- <green.ca> Marillion:<www.marillion.co.uk>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBN6x4Wt+sBuIhFagtAQEdCQQAqnMYoyyZxciHymo6I3ZxcBBZ2/oo0/pl
5vZPwLdBtRMiskG1gHGjMjAmtaKQrQQde/76sT6xREnZ8FhlKXwqb9QkyGzToRuh
bQf/GDX5SWvxtToZJBFveYkhSXPG9xoBhIWEWvQumphou3h9psg/eNoyrByw8FCg
sl8KI0BQ8Ro=
=s6up
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/