Signing data packets increases data size too large for packet to contain In a setup where the client signs then encrypts outgoing data packets to a VPN server / onion network, an ECDSA signature appended to the plaintext before encryption could cause the data to be too large to be contained in the packet. How is this avoided??

Side note: Encryption will be with a stream cipher, so the data size wont increase after encryption of the ECDSA signature appended to the plaintext.
How is this avoided??


Well, if it add any sort of integrity check to the data (be it a signature or a more sensible MAC), well, that increases the size of the data (packet), and so can potentially push the packet to be larger than the MTU size (assuming the inbound and outbound MTU sizes are the same).

However, the TCP/IP protocol has mechanisms to deal with this.  The details depend somewhat on whether you're encrypting as an end host, or you're a security gateway - since you talk about encrypting traffic from a website, I'll assume you are (at least partially) talking about a security gateway (that is, something that sits between the two end points).

The most obvious one is to advertise a smaller MTU size; that is, if you get a packet that (after encapsulation) would be too big, you reject it with the appropriate ICMP message (giving the largest MTU size that you could process).

This works; however IPv6 doesn't allow you to advertise an MTU size smaller than 1280; if the path that handles the encrypted traffic is close to that size, this doesn't work.

The fallback is to do packet fragmentation yourself; you divide the packet into two (along with some notation to the decryptor about what you did), and encapsulate each packet separately.  This is uglier, however it does work.

The IPsec RFC (4301) goes through this rather explicitly...