Hi Scott, thanks for your feedback!
My comments are inline. On Mon, Aug 04, 2025 at 03:01:41PM +0000, Scott Fluhrer (sfluhrer) wrote: > 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. Yes, absolutely. In the draft we say 'EESP neither updates nor obsoletes [RFC4303]' to make this clear. > * > 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. There are still use cases for transport mode where end to end connections don't want to have the tunnel overhead (in particular on IPv6). I think we should to keep the transport mode option. > * > 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. We discussed this and we think we don't need the flag, we plan to remove it with the next version of the draft. > * > 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. Aside from the use cases Valery mentioned, there is another reason why we want to negotiate replay protection. On ESP the receiver decides alone whether replay protection is done or not. The sender does not even know if the connection has replay protection. So on EESP we want to negotiate replay protection so that both peers can agree on this. And if agreed to not do replay protection, there is not point to have a sequence numbers field in the header. > * > Similarly, you give the option of exposing some of the plaintext. Again, is > this something we want to do? The recent 'industry security protocols' like Google PSP or the UEC TSS all have this option. So there is a need for it, at least in data center use cases. Both peers must agree whether to allow a crypto offset and if so how many bytes should be exposed as a maximum. So there is still the option to reject this feature for both peers. That said, I think we need someting like this. But we can think about moving it to a separate followup draft that specifies 'EESP for datacener use cases'. Steffen _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
