Date: Sun, 19 Jan 2020 11:31:23 +0300 From: Sergey Matveev <stargrave@stargrave.org> To: freebsd-net@freebsd.org Subject: Re: IPSec transport mode, mtu, fragmentation... Message-ID: <20200119083123.GA31553@stargrave.org> In-Reply-To: <20200119080707.GB63055@admin.sibptus.ru> References: <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> <c7f5828b-3678-b432-47a8-75afada5bd9e@freebsd.org> <20200119033843.GB54797@admin.sibptus.ru> <20200119080707.GB63055@admin.sibptus.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: IPSec transport mode, mtu, fragmentation... *** Victor Sudakov [2020-01-19 15:07]: >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). Wrong in nearly all cases. 1) If you use *stream* symmetric cipher, then ciphertext's length is equal to plaintext. 2) If you use *block* symmetric cipher, then it has to be divisible by blocksize by definition. However that depends on used blockcipher mode of operation. For example CTR (counter) mode transforms block cipher intro stream cipher, thus requiring no padding. In CBC mode it requires padding, so as a rule it will be always greater up to blocksize. 3) ESP requires most fields to be multiple of 32-bits, so even if you use stream cipher or some kind of block cipher CTR mode, you have to pad it to be multiple of 4-bytes because of ESP. 4) You HAVE TO always use and enable ciphertext authentication. All modern protocols even forbid non AEAD (authenticated encryption) ciphermodes usage at all. For example AES-GCM is that kind of ciphermode. And always your ciphertext will have MAC tag (ICV field in ESP) filled. AES-GCM as I remember uses 96-bit MACs, others use 128-bit MACs or even larger. 5) Also ESP has IV field and most ciphers (AES-GCM, GOST ones, and so on) requires it. It takes 8 bytes in practice. >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? So minimally with some kind of modern AES-GCM you have 8 bytes of IV, 12 bytes of MAC tag (ICV field), possible ESP 32-bit alignment padding, 32-bits SPI and sequence numbers. --=20 Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEIpNVsPbb+nIRVbvGHh7ERWs1C6UFAl4kE9AACgkQHh7ERWs1 C6Wzmw//UHvWZXtoUd3sUpxSjIW9OsMDmi2jRplljDf3WwSgw22dmdmp1QU9TmxS FhE6LVUoxWsmONL5wjJ2PQqlVlGTibjPmiXY+De2RnN/vshFMYz8c6nDzo27sPH1 nurkyL4kx1pv+K7so0yN1URqI+GfS/7s42c1Hl7z0JUlpCZ1/jFVcsNCsucZ5mdt CKmAmbWy5DWt6Uv3afHWht7jgaIHqxOCKyArxukINLVoRYGeMxSHVIt0negMiIpq abgQmfLtkND24zhHsaG1Y19oXwRu50b9OzsEo9QdWLlfpsqYjIc7QEOBAwJLe/Ux pgEYTOdGp7NkSgIh3cBOmXG7YWxw5LKtCeZRyQzY4VtU5jHC3YPNsrrU/eZlurkZ i9DX1bQ5SOpAG0O5tgj70XClyI2LZg0KkgAE5z0PgGrG3fZE0ZLGKSuBjZzW2g4F Z38ySlGrcUq2Vuk9ShFEDdVdqE2/HAFM1vxLi0mIW2koD3WQtFXO+boLIvk57uJz GnZGkvQ91dL7It2ASwlX3E2RFD1zVaz1Ud7+BLctfbtYMZ5ufBPTbkC0kzo4lbL4 QrgXc7JrxgA+QNDPhjcydiqk5wEvJVBfYn/N+htUt2BcIGej1dS0Y8G+On0b/Cx8 AcshnYkl+OBF1MvlHaxWyOZE9XGAWhUzGmFa+SwFCKevsDREl5E= =NVLW -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200119083123.GA31553>