Victor Sudakov wrote: > Julian Elischer wrote: > > > > > > > Back to the point. I've figured out that both encrypted (in transport > > > > mode) and unencrypted TCP segments have the same MSS=1460. Then I'm > > > > completely at a loss how the encrypted packets avoid being fragmented. > > > > TCP has no way to know in advance that encryption overhead will be > > > > added. > > > Using multiple routing tables we could add a mechanism to the ipsec > > code so that encapsulated sessions are referred to one routing table > > and that the "envelope" routes are referencing another (specified in > > ipsec setup) routing table. The two routing tables would have different > > MTUs. This mechanism/framework would also be useful for other > > tunneling protocols in general. > > I think before inventing something so innovative and clever, we should > look at how IPSec transport mode and MTU adjustment is implemented in > other OSes (OpenBSD, Linux, even Windows). Any experts?
Maybe I've created much ado about nothing? In *transport* mode, the packet payload above the IP level (TCP+FTP in our case) is replaced by the encrypted payload. Probably this transformation should not cause any increase in payload size because AFAIK a symmetric cipher does not increase the message size (i.e. the encrypted message is not bigger than the cleartext). OTOH, there is added information is the 4 bytes of SPI and 4 bytes of ESP sequence number, correct? So the payload should grow 8 bytes. Is this enough to make the packet too large? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
