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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
