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.
*
Similarly, you give the option of exposing some of the plaintext. Again, is
this something we want to do?
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
