Re: IPSec transport mode, mtu, fragmentation...
Sergey Matveev wrote: > *** 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. Thank you, Sergey, this information was very educational. The conclusion is that even in transport mode we should observe a significant growth in size of the encrypted payload in comparison to the unencrypted one. So, how does the TCP/IP stack handle this growth? The transport layer (TCP in our case) probably does not know about this additional overhead because I observe in the packet dumps that the MSS is always the same 1460 bytes. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Problem reports for n...@freebsd.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- In Progress |221146 | [ixgbe] Problem with second laggport In Progress |235700 | oce(4) driver causes fatal trap 12 on boot with e New |204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New |205592 | TCP processing in IPSec causes kernel panic New |213410 | [carp] service netif restart causes hang only whe Open|193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open|194453 | [dummynet] pipe config bw parameter limited to 2G Open|194485 | Userland cannot add IPv6 prefix routes Open|202510 | [CARP] advertisements sourced from CARP IP cause Open|207261 | netmap: Doesn't do TX sync with kqueue Open|210726 | tcp connect() can return invalid EADDRINUSE (Eg: Open|73 | igb(4): Kernel panic (fatal trap 12) due to netwo Open|225438 | panic in6_unlink_ifa() due to race Open|225792 | ECMP is broken since tryforward() Open|227720 | Kernel panic in ppp server Open|235524 | igb(4): Ethernet interface loses active link stat Open|236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open|236983 | bnxt(4) VLAN not operational unless explicit "ifc Open|237072 | netgraph(4): performance issue [on HardenedBSD]? Open|237391 | route get returns no result for network addresses Open|237840 | Removed dummynet dependency on ipfw Open|238324 | Add XG-C100C/AQtion AQC107 10GbE NIC driver Open|240530 | netgraph/ng_source: Allow ng_source to inject int Open|240944 | em(4): Crash with Intel 82571EB NIC with AMD Pile Open|240969 | netinet6: Neighbour reachability detection broken Open|241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open|241162 | Panic in closefp() triggered by nginx (uwsgi with Open|241191 | route flush panic with RADIX_MPATH 28 problems total for which you should take action. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPSec transport mode, mtu, fragmentation...
Eugene Grosbein wrote:
> 19.01.2020 14:12, Victor Sudakov wrote:
>
> > So this is most probably the artifact of if_enc. What is then the
> > correct way to capture data with it?
>
> This is documented behaviour of enc(4), see its manual page for description
> of sysctl net.enc.{in|out}.ipsec_bpf_mask
This description does not make much sense to me, there is neigher "inner
header" nor "outer header" in transport mode.
By trial and error I've figured out that "net.enc.out.ipsec_bpf_mask=1"
is probably the answer. At least ICMP requests and replies are not
duplicated any more.
I still see lots of "dup ACKs" in Wireshark though.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
Re: IPSec transport mode, mtu, fragmentation...
19.01.2020 14:12, Victor Sudakov wrote:
> So this is most probably the artifact of if_enc. What is then the
> correct way to capture data with it?
This is documented behaviour of enc(4), see its manual page for description
of sysctl net.enc.{in|out}.ipsec_bpf_mask
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF signature.asc Description: PGP signature
Re: IPSec transport mode, mtu, fragmentation...
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
