Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Jan 2020 17:55:24 +0700
From:      Victor Sudakov <vas@sibptus.ru>
To:        Eugene Grosbein <eugen@grosbein.net>
Cc:        freebsd-net@freebsd.org, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Michael Tuexen <tuexen@freebsd.org>
Subject:   Re: IPSec transport mode, mtu, fragmentation...
Message-ID:  <20200118105524.GA10042@admin.sibptus.ru>
In-Reply-To: <16550199-67b9-d331-0c1e-4afa0e8b361c@grosbein.net>
References:  <f9b7357e-ced1-4ce5-40d5-8e3dcad42442@yandex.ru> <d263a709-63cf-7da5-1747-8a6791f6503f@grosbein.net> <20200116155305.GA465@admin.sibptus.ru> <55f7bafa-24c4-9810-0d21-f82cb332ee2d@grosbein.net> <20200116160745.GA1356@admin.sibptus.ru> <72355e03-1cf8-c58f-3aec-b0a21e631870@grosbein.net> <20200117093645.GA51899@admin.sibptus.ru> <70b0b855-189b-03c2-0712-fc1e35640702@grosbein.net> <20200117150928.GB66677@admin.sibptus.ru> <16550199-67b9-d331-0c1e-4afa0e8b361c@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

>=20
> >>> Back to the point. I've figured out that both encrypted (in transport
> >>> mode) and unencrypted TCP segments have the same MSS=3D1460. 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.

Here: http://admin.sibptus.ru/~vas/ftp-pcap.tar.gz you can find two
identical FTP sessions, the only difference being ipsec=3Doff during one
session and ipsec=3Don during the other one.

As I said, in both the sessions MSS=3D1460 which is already odd, and I
can't explain to myself why file transfer still works without MSS
ajustment.

Moreover, something fishy is happening in the encrypted session: there
are many TCP retransmissions (I was capturing on the FTP server's side,
so there are many segments with the same sequence number). How would you
explain this? There are almost no retransmissions in the unencrypted sessio=
n.

All this is happening in a lab environment (one bhyve VM is an FTP
server and the other downloads a file from the first), both VMs are on
the same bridge interface. There are almost 19,000 packets in the
encrypted file vs 12,000 in the plain file, I think because of those
excessive retransmissions.

Could the retransmissions be some artifact of the enc(4) interface I was
capturing the encrypted session on?

--=20
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

--LQksG6bCIzRHxTLp
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJeIuQcAAoJEA2k8lmbXsY0GnQH/jcg5OErEpJ4O9GEq2Zal9eJ
BmHfXooLS4sQUyygtKK1r+7BsbNWOj/9KSSTmfouSfJw6bHoa1NO4mEWjfzzW0vW
gC/BXEEMPpcraX9JbYChM/aCLmkwbYUrFJH6cGeTNNlrzbtW+9vau+xkjiV0wLLk
zPC9LCyfibIyZ3Ywc5YsdwgQ4pihoolXZgFzyjIQw7YGGm5xoy4X1P3ODygujU50
0IC1ceAk+RwDOKX6cz6LdsXxjow33JzVU3X80S65rBMs/RR7qvp8SRoldCkZPKGM
0WjxMIvcYiaVi+Uid0isLVbsKGFL79qg0oo8Pzbie9NtZT94hS4tOn3b1q/Ou/A=
=+Tjq
-----END PGP SIGNATURE-----

--LQksG6bCIzRHxTLp--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200118105524.GA10042>