I was forwarded this message. As a matter of fact, I've never left the list,
but very rarely read it.
Speaking as one of the original designers of ESP, I'm delighted that folks
are finally catching up to our original design of 25+ years ago!
There's no need to rename ESP. The Security Parameters Index was always
intended to always be in exactly same place, while the following fields
were per transform:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
On 7/22/20 6:26 AM, Michael Rossberg wrote:
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
I'll post on this separately.
* 64 bit sequence counters in each header to ease protocol handling and
allow for
replay protection in multicast groups
ESP as originally specified circa 1994-1995 permitted larger sequence numbers.
We had expected all stacks to support them.
The size of this field is variable, though for any given Security
Association it has a particular known size. ...
All conformant implementations MUST correctly process a 64-bit
field size. ...
As IPsec was originally developed in the SIPP IPng WG, we were advocates of
64-bit alignment of the TCP data.
Sadly, a later WG editor removed that facility over my objections.
We'd always envisioned that DES would not be the be-all and end-all. But
some short-sighted folks restricted the initial RFC published transforms.
Heck, they wouldn't even publish triple-DES or DES-XEX. (I was on both of
those internet-drafts.)
Because of the DES unicity distance, there should never be more than 2^31
packets on the same DES session key. You've been stuck for 25 years with
DES-specific transform formats.
* Removing the trailer to ease segment & fragment handling and alignment
The trailing payload type was always a poor choice. Caused already
perfectly aligned packets to need extra block cipher padding, and even
IP fragmentation. But we lost that fight, too.
It was a compromise advocated by certain IP stacks of the day that
couldn't/wouldn't pass up their stack based upon the SPI.
We'd envisioned the SPI to be provisioned on a per socket basis.
The payload type and even the port number were to be specified or
negotiated by the session key manager.
* Implicit IVs in spirit of RFC 8750 removing the need for AAD
I'll post on this separately.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
