Hi Scott,
thank you for your comments. I'll address only one point.
This, in general, is a significant improvement over the 26 year old ESP
format; doing things like moving that stupid trailer, and having all 64 bits
of the sequence number in the packet (rather than having the decryptor guess
the upper 32 bits). The idea of subSAs also sounds to be very useful.
That said, I would suggest that we consciously try to avoid "second system
effect", where we cram in every good sounding idea in there, but instead try
to keep things as simple as possible.
My comments:
* This should be seen as an alternative to ESP, rather than a
replacement (which is the intention of the authors). What that means is
that we needn't be that sensitive to packet size, as ESP can be used in
situations where that is constrained.
* You continue the transport/tunnel mode distinction. Is this
appropriate? Tunnel mode can do everything that transport mode can, with
some additional overhead. Would it simplify things if we only had tunnel
mode.
* Even if we want to continue the distinction, the transport/tunnel
mode flag is in the clear (flags field). Is that something we want to leak?
Even if we want a per-packet indication the first 4 bits of the decrypted
plaintext gives us that - 0 = transport, 4 = IPv4 runnel, 6 = IPv6 tunnel.
* You make the sequence number optional. The only benefit I can see
from that is reduced packet size (and to be honest, I'm not thrilled with
giving engineers the option of dropping antireplay from the security
services we provide). Is this what we want to do? I realize implementors
still can; I'd prefer not giving them any incentive to do so.
Two use cases were considered when sequence numbers are not needed:
1. Multicast SA with a lot of senders (e.g., each group member acts as a
sender). In this case replay protection is either impossible to get (in case
all group senders use
unsynchronized sequence numbers) or too expensive (when each receiver keeps
separate track of sequence numbers for each sender in a large group).
2. So called "stateless encryption", when receiving side keeps no per-SA
state (e.g., as in Google's PSP protocol). Since receiver has no per-SA
state,
it cannot do replay protection based on received sequence numbers. It is
assumed in this case that upper level protocol is either resilient to
replays or replays
are detected at transport layer.
These use cases were considered for EESP (but not yet specified in the
draft, since they are not "regular"). In these cases transferring
sequence numbers makes no sense, thus this field is marked optional. With
"regular" use of EESP replay protection must be on
and in this case sequence numbers won't be omitted.
Regards,
Valery.
* Similarly, you give the option of exposing some of the plaintext.
Again, is this something we want to do?
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
