Encrypt-then-authenticate variant used in IPsec I am trying to understand the variant of Encrypt-then-Authenticate (EtA) that is used in IPsec. For this I have looked at this chapter.

What I got so far is that the integrity and confidentiality computations cover different parts of the EPS packet. What I don't understand is what exactly is done and how this is different from the general EtA composition (i.e. what is modified in comparison to the general EtA composition).
This is standard Encrypt-then-Authenticate. The only difference is that when doing EtA, it actually isn't necessary to encrypt everything. This strategy makes sense when there is some part of the message that needs integrity and not privacy. In IPSec, the ICV (which is a counter to prevent replay) does not need privacy. Furthermore, by not encrypting it, it is possible to not have to decrypt in order to check if a packet is being replayed (rather, it suffices to check the MAC).

It is important to note that it is possible to use IPSec incorrectly, and do MAC-then-encrypt. This is achieved by computing the IPSec authentication header, and then encrypting. Despite being recommended by some experts, this is BROKEN! So, if you want privacy and integrity, then it should all be done inside the ESP, as is described here.

The fact that AtE is broken in IPSec is not theoretical. See, for example, the paper On the (In)Security of IPsec in MAC-then-Encrypt Configurations by Degabriele and Paterson.