Tero Kivinen <[email protected]> wrote: > What I proposed earlier was that we define that chacha20 uses explicit > IV, but the IV is always generated as running counter incremented by > one.
> In normal case the IV is sent inside the both IKEv2 and ESP packets.
> In ESP the sequence number is used normally for replay protection.
> Then we could create new "ESP Sequence number + IV compression"
> protocol, that would negotiate the support for this in the IKEv2 for
> ESP, and if enabled by both ends, then they would set the ESP sequence
> number and chacha20 IV to be linked, i.e. they would always be same,
> and then we could compress one of them away after the encryption, and
> decompress them back in place before decryption.
That's an interesting proposal.
It seems excessively modular to me, but I'm willing to listen more to why it
makes sense. Are there actually IKE daemons that use the IPsec code to do
their decryption? I can see how this might happen in IoT space..
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
