Re: [IPsec] Teaser for pitch talk at IETF 108

[Michael Rossberg <[e-mail]>]

>> 
>> We have been analyzing issues ESP has in current data-center networks and came to
>> the conclusion that changes in the protocol could significantly improve its behavior. Some
>> of results will be presented next Tuesday in a pitch talk at IETF 108. This mail is just a
>> small teaser, in case some of you wanted to gather some arguments for the discussion.
>> 
>> In particular, we propose the following changes to ESP:
>> 
>> 	* Allow multiple windows per SA to allow for scaling over CPUs, windows per QoS
>> 	  class & replay protection in multicast groups


> 3. If multiple windows are used for several QoS classes, then this proposal won't work in case
>    of TCP encapsulation, while several ESP SAs will (if we have several IKE SAs too).

With IPsec in TCP I do not believe one requires QoS anymore =) But honestly one could go
the same way. Multicast, CPU steering etc is a non-issue anyways.

> Having replay protection in case of multicast is a feature that is not currently
> available in ESP. However, it's easy to add this feature (with the limitation
> that it only will be available if counter mode ciphers are used) by simply
> letting all GMs know the number of SID bits, so that they can guess
> Sender ID from the IV. It's very simple modification of G-IKEv2.

If you have an explicit IV that is true. If you want implicit IVs, this approach no longer
works. Note rfc 8750 rules out multicast by design.

> Having said this, I think that the replay protection for multicast
> is not a feature that is absolutely needed. Multicast is performed
> over UDP, so application protocols have to deal with packet
> replication and loss in any case (when they are used without
> IPsec protection). So, while a nice feature to have, I don't think
> it's absolutely necessary and if one needed, it can be achieved without any
> modification to ESP with the same limitations as the proposed
> solution.

I disagree. As people more and more send VXLAN etc over IPsec I am afraid that there
might be side effects that at least I can no longer foresee. I remember WEP with its non-
existing replay protection, an we could replay certain packets that generate legitimate
answers in order to obtain more traffic for cryptanalysis more quickly.

>> 	* Removing the trailer to ease segment & fragment handling and alignment
> 
> I was told by Linux kernel people that having trailer in ESP is a headache for them.
> However, this simplification has its cost:
> 
> 1. Ciphers that require padding  cannot be used. I admit that CBC and the like
>     are out of fashion today, but I don't know which cipher modes will be in fashion tomorrow
>     and what requirement for padding they will have.

You can still pad implicitly (just like in IPTFS) and are not even limited to 256 bytes.

> 2. No Next Header field eliminates transport mode (BTW, widely used for multicast!)
>     and makes it difficult to implement TFC (you can add TFC  padding, but you can't send
>     dummy packets and you can't use IPTFS)

We have ideas to save the field for transport mode, but did not want to stress the teaser
too much. Basically we add an encrypted part to the header.

>> 	* Implicit IVs in spirit of RFC 8750 removing the need for AAD
> 
> I don't consider removing AAD is a benefit, since all the AEAD schemes I'm aware of
> allow to have AAD.

They are allowed to have AAD, but it will double en/decryption operations for small packets.

> On the other hand, implicit IV is only applicable
> to some transforms. I'm not only talking about non counter-based AEAD ciphers,
> (like CBC), but even for counter-based AEAD  a situation is possible when there is a need
> for IV to be somehow structured and not be a plain counter (e.g if you implement key trees).

As written in the chat during presentation we could look at that. But it is always possible to
go back to an explicit IV.

>> Further details and benchmark results may be found in a paper preprint [1] and a
>> presentation [2] we held with at the Linux IPsec Workshop.
> 
> A few more considerations.
> 
> It seems that performance of this proposal depends on ICV size
> for the plaintext to be properly aligned.
> If ICV is 16 bytes, then plaintext is ideally aligned on 32 bytes,
> but if one use 12 byes ICV (e.g. ENCR_AES_GCM_12)
> then the plaintext is aligned on 4 bytes, that is even worse
> than ESP, where it is for most AEAD transforms aligned on 16 bytes.

Alignment may - depending on the architecture - be a plus. With only a
header one can adjust the headroom to have proper alignment. In any
of that cases.
For the trailer ESP takes care of 4 byte alignment only. For the header
one can use the same tricks, but out of the box you only have 4 byte
alignment by IP and even worse 2 byte alignment by Ethernet.

> Since this proposal allows only tunnel mode, it will have
> larger overhead for small packets. This is partially
> compensated by having IV to be implicit...

We simplified for presentation as said above. Transport mode
is still possible with an additional inner header.

> And about security. In order to have IV combined with
> ESN and sub-windows identifiers this proposal removes secret
> salt from the nonce. This may have impact on security.
> I'm not a cryptographer, but I believe the impact is not negligible.
> On the last CFRG session a draft draft-wood-cfrg-aead-limits was
> discussed that calculates limits of data to be safely encrypted
> by various AEAD ciphers. The authors claimed that having
> secret salt in the nonce increases this limits in case of multi-user
> attacks and that the results in the draft are calculated
> for this case. If plain AEAD ciphers (with no secret salt) are used
> the limits are lower.

The salt is a precaution. Just like the numbers in  the padding. Nothing
you want to build your security upon. NIST GCM document does not
mention it. MACsec does not use a salt.

> So, on one hand this proposal makes it possible to transfer
> larger amount of data with a single key (because you can
> combine all the traffic from different QoS classes and
> all the CPU cores into one SA, no need to have
> several ESP SAs). On the other hand
> it simultaneously decreases the limit of data that
> can be safely protected with a single key.

I do not under stand why the data is reduced. The probability for internal
collisions in GCM is not affected by the proposal.

> I think that it's an interesting work, but I don't think it is
> a candidate for ESP replacement. The main problems with it
> (as I see it from my corner) is that it is not generic enough:
> it is optimized for small number of crypto transforms and
> use cases.

Indeed we concentrate on the ciphers we found predominant today. For
low speed connections there is still CBC, we could add it for sake of completeness.
The optimization for a certain use case is true, too. We concentrated on
high speed data center SAs, as it is always easy to make things slower later on =)
You can make unicast from a multicast-capable protocol, but not vice versa.
If an outcome of this discussion is, this being special purpose solution for data
centers, that would be absolutely fine I guess.