Re: The TCP and UDP checksum algorithm may soon need updating

[Nico Williams <[e-mail]>]

On Mon, Jun 08, 2020 at 11:23:09AM -0700, Michael Thomas wrote:
> ssl had the advantage that it 1) beat ipsec to market, and 2) wasn't subject
> to API differences from OS layer calls like IPsec was, and with quite a bit
> of churn as i recall too. it's really too bad, imo. we wouldn't have had to
> do the contortions of dtls, for example. and now there's this problem. none
> of them are earth shattering, but it would have been cleaner.

You can sprinkle TLS anywhere you have an octet stream.  You can
sprinkle DTLS anywhere you have datagram flows.  No need for OS support
-- it will just work.  IPsec?  IPsec requires OS support.

Also, IPsec got a lot of things wrong.  It's simply not usable at
Internet scale as originally intended because... it's IP-layer, so it
deals in discrete packets and IP addresses.  Well, discrete packets do
not define application connections/sessions[*], IP addresses are too
dynamic and useless for authentication and authorization[**], and
configuration is ETOOHARD.

As you can see, a dozen years ago was already too late, but our idea
then was to

 - construct protection guarantees for packet flows using IPsec,
 - to use anonymous or anonymous-like key exchanges to key IPsec,
 - and to use channel binding from application layer protocols that can
   authenticate more useful names than IP addresses.

Nico


[*] In the IPsec architecture, RFC 4301, there is no guarantee that the
    packets making up a TCP connection, say, will have anything like
    similar protection for the lifetime of the TCP connection.
    Everything about how a TCP conenction is protected by IPsec depends
    entirely on *configuration* with no standard interfaces _at all_ for
    applications to manipulate said configuration.

[**] Yes, in RFC 4301 you're supposed to specify things like trust
     anchors and policies like "any peer with a certificate from this CA
     can _claim_ IP addresses in the following prefixes/ranges".  This
     _cannot_ scale to Internet scale.

     Giving up on authentication and authorization in the RFC 4301
     scheme (BTNS, RFC 5387) and constructing logical packet flows with
     consistent protection during their lifetimes (RFC 5660), fixes the
     problem.  It didn't get implemented -- even if it had been, TLS was
     already king.  This would all have to have happened at least half a
     decade earlier, if not a whole decade earlier, to have had a
     chance.

     What was particularly appealing at one point was the possibility of
     having ESP offload in NIC HW.  The lower in the stack the crypto
     happens, the easier it is to offload it.