IPSec transport mode, mtu, fragmentation...

[Victor Sudakov]

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 at fidonet http://vas.tomsk.ru/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20200119/3eb0d1d6/attachment.sig>