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

[Valery Smyslov <[e-mail]>]

Hi,

a few thoughts about this proposal.

> 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

An ability to have multiple windows per SA is an interesting idea.
However, in most cases the same result can be achieved with several parallel ESP SAs
with the same traffic selectors. Comparing with this proposal:

1. Several parallel ESP SAs require more resources to set up. On the other hand I don't 
    think it really matters (2 short IKE messages per SA is not a big deal, especially if no PFS is used and
    we are going to transmit millions of ESP packets then). 
2. Several parallel ESP SAs require more resources in the kernel. This is true.
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).

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.

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.

> 	* 64 bit sequence counters in each header to ease protocol handling and allow for
> 	  replay protection in multicast groups

This would simplify replay protection logic on receiver, but will waste
4 bytes on the wire for unicast SAs. I agree that ESN with ESP would not be available 
for multicast even if the above mentioned solution (letting GMs know SID) is implemented.
But I'm still not convinced we need it.

> 	* 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.
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)

> 	* 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. 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).

> 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.

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...

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. 

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 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.

Regards,
Valery.

> Michael
> 
> 
> [1] https://telematik.prakinf.tu-ilmenau.de/files/packetformat.pdf
> [2] https://telematik.prakinf.tu-ilmenau.de/files/VPE.pdf