Increase number of algorithms that can be initialized in cryptosoft

[jaz_semihalf.com]

Summary

During initialization, cryptosoft expects at most 2 algorithms one for
encryption, second for authentication. But there are also extensions to
crypto driver like support for Extended Sequence Number which are
represented as algorithms too. As consequence there could be 3
algorithms choosen, and that is the reason for increasing number of
algorithms in swcr_session.

[cem]

The majority of ocf drivers aren’t ready for this. Can you give me some context on what ESNs are and why they ought to be part of doing an OCF transform? Have you considered integrating these in @jhb’s OCF rework branch?

Thanks!

[jhb]

I do plan to land my ocf_rework branch soon which completely reworks the data structures (e.g. removing the linked list of cryptoini and cryptodesc). Some pointers to what ESNs are and how they are used would be useful to ensure that the new approach can work with it. The new approach uses a single, flat structure to describe both sessions and operations with explicit modes for combined operations (e.g. an ETA mode for Encrypt-then-Authenticate used by IPSec and TLS with ETM).

[mw]

Hi @jhb - so this patch will not apply onto your solution, right? When do you expect to push it?

Do you have some open repo to see and try it?

[cem]

In D22363#489261, @mw wrote:

Hi @jhb - so this patch will not apply onto your solution, right? When do you expect to push it?

Do you have some open repo to see and try it?

https://github.com/bsdjhb/freebsd/tree/ocf_rework

[pdk_semihalf.com]

Hi,

First of all, @cem, @jhb, @mw thanks for your comments.

ESN (Extended Sequence Number) is term closely related with IPSec, or more precisely with ESP header.
ESP header contains 32 bit Sequence Number field and it seems to be insufficient when IPSec
is used in high speed networks - rekeying (in fact: removing old tunnel and establishing new) procedure
have to be triggered too often. Moreover kernel doesn't inform user space that Sequence Number is about to wrap.
It's application responsibility to trigger rekeying procedure at times, basing on maximum packet rate.

RFC4304 introduces aforementioned Extended Sequence Numbers.
But it is not an additional field in ESP (next 4 bytes would consume precious bandwidth). ESN are part of ICV (Integrity Check Value)
computed by some authentication algorithm. In other words ESN is taken into account when computing ICV, but it is not transmitted
over network. Kernel is responsible for maintaining current ESN value.

To get things more complicated ESN position is different when computing ICV for combined-mode algortihms (eg. AES-GCM - RFC4106)
and for encrypt and authenticate algorithms.

Current crypto implementation doesn't allow for including data from some buffer only for authentication. ESN including can't be done in IPSec code, because
data are encrypted and authenticated at once and it will introduce unnecessary copying.

I'm aware that this solution is far from perfect, but for now it is reasonable way with little performance impact. I haven't checked ocf_rework branch yet but it seems
to be rebuilding whole crypto framework. Let me know how ESN fits in this.

[jhb]

TLS has a similar requirement btw of requiring AAD data that isn't present in the on-wire data in the buffer. The way I would handle TLS if we added support for TLS proper in the ocf_rework branch would be to add a new "mode" CSP_MODE_TLS along with some TLS-specific parameters to the session structure such as the TLS version and the TLS sequence number to 'struct cryptop'. I think that same approach would work well with ESN, but it's a bit invasive for drivers. (One reason I considered CSP_MODE_TLS is that some hardware accelerators such as ccr(4) can do TLS "natively", but that isn't true of ESN AFAIK). I will spend some more time thinking about ESN, but I've just rebased the rework branch and gotten the remaining drivers converted this week, so am going to send out a call for testing today or early next week (I can't run-time test all the drivers). The current framework is far too limited in that real hardware needs to know if it is doing ETA or MTE, etc. and the current OCF has no way to express that. It also has no way to express variable sized IVs (which we really need for the full suite of GCM and CCM NIST KAT vectors). The linked-list approach is also quite clumsy to work with on the driver side (a lot of boilerplate code gets removed from drivers trying to maintain a state machine to validate sessions in the current model that turns into simpler checks on a flat structure in the rework).

[cem]

It seems like ESNs are just AAD in integrity modes and maybe sometimes plaintext or sometimes AAD in other ipsec modes. I’m not sure why they’d be considered an algorithm? I think this will be easier to express in the rework branch so I’m glad to hear John plans to circulate it soon.

[pdk_semihalf.com]

It is considered as an algorithm to avoid ESN implementation in every driver (I have implemented ESN in cryptosoft and aesni only).
It would be perfect if OCF was prepared for ESN support or at least was organized in way that makes ESN implementation simpler than in current OCF.

When should I expect stable version of reworked OCF? When it will be merged into FreeBSD?