Vitaliy Makkoveev <o...@bsdbox.dev> wrote: > > ssh_packet_need_rekeying() appears to have some nice decisions. The > > idea is to rekey based upon time, primarily. > > It does the same: the two limits and rekying starts when you exceeded > any of them. But in the ssh case we have no massive traffic load, so we > reach time limit first. The ipsec case is opposite.
First off, this is not ipsec. This is a iked decision. And thus the iked case is only the opposite of ssh because iked has ludicrously small data limits. I doubt this choice was made purposefully. Correct me if I am wrong about ssh: debug1: rekey in after 134217728 blocks Imagine AES is being used such that blocksize is 16. So ssh will rekey at 2GB data, also note this is a non-datagram model, it is a session that stops such that no traffic is lost. And this 2G is generally the data rekey decision for a flow by _a single user_. But IPSEC is not moving a single user's data! And as a result of this, datagrams get lost. Seems a poor tradeoff to lose packets when turning on crypto. So 2GB is a ludicrous position to take, very much like "the cipher being used is unsafe". Please explain how AES is suddenly this poor. If there are unsafe cipher choices, then those specific unsafe ones should make tighter datasize choices, but the modern ciphers we have are much better so their choices should be huge. I suspect the first step is to make the rekey decision be based upon the strength of the ciphers.
