1
$\begingroup$

The RFC https://tools.ietf.org/html/rfc4106#page-5 states that, under AES-GCM IPsec, each packet is expanded by 8 bytes for the IV and up to 16 bytes for the ICV. Why? Since we already have a Sequence Number (4 or, in the case of ESN, 8 bytes), can't we just use that as an implicit IV? This saves 8 bytes per packet (which is sometimes negligible, but sometimes not), and doesn't seem to harm security at all - either way, we need to ensure that sequence numbers are unique. If anything, it's easier to ensure that one field (ESN) is unique, more than two?

If I am correct, and you can just the ESN has the implicit IV, is doing so compliant with the standards?

Note: I recognize this assumes only one encryptor per SA. For cases of multiple encryptors using the same key, each encryptor would need to prepend their unique id to it.

$\endgroup$
2
$\begingroup$

If I am correct, and you can just the ESN has the implicit IV, is doing so compliant with the standards?

No, it would not be compliant with the RFC. The RFC clearly states that there must be 8 bytes of IV payload immediately in front of the ciphertext (see section 3). Omitting those 8 bytes would not allow interoperability with standard implementations of ESP-GCM (and a large part of the reason the IETF does RFC's is to allow different implementations to interoperate).

Yes can, of course, copy the ESP sequence number into the 8 byte IV; that meets the requirement for uniqueness; however that obviously doesn't do the bandwidth saving you're looking for.

Alternatively, if you feel strongly enough about it, you could design a vendor-specific encryption method that does GCM (and derives the sequence number in the ESP header as payload); IKE does provide ways to do that. However, you can't claim compliance to RFC4106...

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.