Subject: rfc791 coming up to 40 years ... what to do (remember, celebrate, ...?)

From: Toerless Eckert <[email-masked]>
Date: Fri, 12 Mar 2021 15:49:12 +0100

Wanted to bring to the list this topic after mentioning it at the plenary.

I guess there are all type of memorable dates for the Internet and also more
traditional dates for the IETF as an organization, but if i look at the
Intersection of the organizations work product and its biggest success,
then this seem like a unique IETF event opportunity.

So, here is my idea what to do, nonwithstanding anything else of course:

Having trolled a bit on [email-masked], it is nice to see
that there are still a lot of folks around who made it happen back 40 years and
from then on. But alas, i am sure that will be different in 10 years.

So, one thing i think would be great to do and for which it might even
be the last big opportunity would be some form of e.g.: 1 day workshop
with interesting invited talks from contributors to that history.

Given how 
a) travel even without Corona for the witnesses of history may not
  always be a welcome option,
b) and given how i think that such a one day workshop
  would very easily have a target audience far exceeding the IETF community
  itself,
c) and finally given how such an event would best be well preserved for
  historic consumption,

this would actually be ideal to be had as a video event to be recorded.
Maybe/probably ISOC would be best to organize, but given how i think as
IETF'ers we would like to see focus put on technical payload, i'd hope
folks from IETF would drive to make something like this happen.

again.. just an idea. Happy to hear any opinion!

Cheers
    Toerless

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Mar 2021 14:57:54 -0500

Top-posting,

I'd like to see some observance like this. Another related day that might
serve was the TCP/IP Flag Day, when Arpanet stopped carrying NCP, on
January 1, 1983.

Best,

Spencer

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Mar 2021 17:04:57 -0400

On 3/23/21 3:57 PM, Spencer Dawkins at IETF wrote:

> I'd like to see some observance like this. Another related day that 
> might serve was the TCP/IP Flag Day, when Arpanet stopped carrying 
> NCP, on January 1, 1983. 

Maybe the public Internet can start filtering advertisements for IPv4 
prefixes on the 40th anniversary of that date?

(ducks)

Keith

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Mar 2021 14:19:36 -0700

> On Mar 23, 2021, at 2:05 PM, Keith Moore <[email-masked]> wrote:
> 
>> I'd like to see some observance like this. Another related day that might serve was the TCP/IP Flag Day, when Arpanet stopped carrying NCP, on January 1, 1983. 
> 
> Maybe the public Internet can start filtering advertisements for IPv4 prefixes on the 40th anniversary of that date?

That’s one way to make sure the Internet doesn’t make it to 41. 

Joe

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Mar 2021 09:44:38 -0500

On Tue, Mar 23, 2021 at 4:19 PM Joe Touch <[email-masked]> wrote:

> might serve was the TCP/IP Flag Day, when Arpanet stopped carrying NCP, on
> January 1, 1983.
> >
+1

Also let's celebrate as Toerless suggests on January 1, 2023 as TCP/IP Flag
Day.
My guess is by then QUIC will be ready to take over TCP, so after that day,
TCP/IP no more but long live QUIC/IP

Behcet

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Mar 2021 17:24:30 -0400

On Wed, Mar 24, 2021 at 10:46 AM Behcet Sarikaya <[email-masked]>
wrote:

> Also let's celebrate as Toerless suggests on January 1, 2023 as TCP/IP
> Flag Day.
> My guess is by then QUIC will be ready to take over TCP, so after that
> day, TCP/IP no more but long live QUIC/IP
>

That won't ever happen because the mistake in TCP/IP was to imagine that
transport is a kernel level concern.

Transport started moving to the application stack when SSL happened. And
QUIC is only the logical endpoint. But contrary to expectations here, the
logic that there can only be one TCP does not apply to QUIC. Once you move
Transport up to application, it is going to be game on and QUIC is going to
be the first of many.

And this is a good thing. TCP responds poorly to HTTP needs because it is
optimized for file transfer. QUIC is optimized for Web browsing. QUIC is
not optimized for every Internet application because not everything is Web
browsing and not every Internet application is a Web browser. That wasn't
the goal in 1992 and it certainly isn't the goal now that Web browsers are
entering middle age with a rather nasty case of 'spread'.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Mar 2021 14:36:30 -0700

On 3/24/21 2:24 PM, Phillip Hallam-Baker wrote:
>
>
> On Wed, Mar 24, 2021 at 10:46 AM Behcet Sarikaya 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>     On Tue, Mar 23, 2021 at 4:19 PM Joe Touch <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>         > On Mar 23, 2021, at 2:05 PM, Keith Moore
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>         >
>         >> I'd like to see some observance like this. Another related
>         day that might serve was the TCP/IP Flag Day, when Arpanet
>         stopped carrying NCP, on January 1, 1983.
>         >
>         > Maybe the public Internet can start filtering advertisements
>         for IPv4 prefixes on the 40th anniversary of that date?
>
>     Also let's celebrate as Toerless suggests on January 1, 2023 as
>     TCP/IP Flag Day.
>     My guess is by then QUIC will be ready to take over TCP, so after
>     that day, TCP/IP no more but long live QUIC/IP
>
>
> That won't ever happen because the mistake in TCP/IP was to imagine 
> that transport is a kernel level concern.
>
> Transport started moving to the application stack when SSL happened. 
> And QUIC is only the logical endpoint. But contrary to expectations 
> here, the logic that there can only be one TCP does not apply to QUIC. 
> Once you move Transport up to application, it is going to be game on 
> and QUIC is going to be the first of many.
>
> And this is a good thing. TCP responds poorly to HTTP needs because it 
> is optimized for file transfer. QUIC is optimized for Web browsing. 
> QUIC is not optimized for every Internet application because not 
> everything is Web browsing and not every Internet application is a Web 
> browser. That wasn't the goal in 1992 and it certainly isn't the goal 
> now that Web browsers are entering middle age with a rather nasty case 
> of 'spread'.
>
>
IPsec certainly suffered this fate, though with filtering I'm not sure 
if it would have the right security properties for tunnel mode. 
Certainly had we used transport mode IPsec instead of SSL we wouldn't be 
coming back 25 years later worried about the TCP checksum.

Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Mar 2021 18:22:35 -0400

> that transport is a kernel level concern.
As an implementation decision I think that made sense at the time. The 
relationship between various costs has changed a lot since then.
> and QUIC is going to be the first of many.
Certainly agree with the last part.   I don't know why the entire 
spectrum of Internet applications should run over a single transport 
protocol, and the over-reliance on cleartext TCP to date has created a 
fertile ground for middleboxes to screw things up in various ways.
> now that Web browsers are entering middle age with a rather nasty case 
  Not sure I agree that TCP was optimized for file transfer - certainly 
a transport that's optimized for file transfer doesn't need to ensure 
strict ordering of all messages sent from one peer to another as long as 
they get reassembled in correct order when the file is written.   
Otherwise, I agree.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Mar 2021 18:23:49 -0400

On 3/24/21 5:36 PM, Michael Thomas wrote:

> Certainly had we used transport mode IPsec instead of SSL we wouldn't 
> be coming back 25 years later worried about the TCP checksum. 

IMO IPsec was DOA because it didn't actually consider the needs of 
applications.

Keith

---

From: Joseph Touch <[email-masked]>
Date: Wed, 24 Mar 2021 15:40:53 -0700

> On Mar 24, 2021, at 3:22 PM, Keith Moore <[email-masked]> wrote:
> 
> ...Not sure I agree that TCP was optimized for file transfer - certainly a transport that's optimized for file transfer doesn't need to ensure strict ordering of all messages sent from one peer to another as long as they get reassembled in correct order when the file is written….

At the time it was created, dominant devices were sequential read/write (e.g., paper and magnetic tape, paper cards). So a small amount of reordering compensation in TCP allowed for those devices at the edges. That’s why TCP is called a byte stream protocol, not a bulk transfer one.

For bulk transfer, see NETBLT.

Joe

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Mar 2021 16:10:01 -0700

On 3/24/21 3:23 PM, Keith Moore wrote:
>> IPsec certainly suffered this fate, though with filtering I'm not 
>> sure if it would have the right security properties for tunnel mode. 
Well there's no actual reason why IPsec needs to be run in the kernel 
except for maybe some issues with IP protocol numbers (can't remember if 
they could be exposed up at that time). Beyond that IPsec in transport 
mode doesn't seem to be much different than TLS other than covering the 
transport headers too. IKE v1 was messy, but IKE v2 fixed a bunch of 
that though both could have worked for web stuff and they both run in 
user land anyway.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Mar 2021 16:17:09 -0700

On 3/24/21 3:40 PM, Joseph Touch wrote:
>
>
>> On Mar 24, 2021, at 3:22 PM, Keith Moore <[email-masked] 
>> ...Not sure I agree that TCP was optimized for file transfer - 
>> certainly a transport that's optimized for file transfer doesn't need 
>> to ensure strict ordering of all messages sent from one peer to 
>> another as long as they get reassembled in correct order when the 
>> file is written….
>
> At the time it was created, dominant devices were sequential 
> read/write (e.g., paper and magnetic tape, paper cards). So a small 
> amount of reordering compensation in TCP allowed for those devices at 
> the edges. That’s why TCP is called a byte stream protocol, not a bulk 
> transfer one.

I thought that actual thing TCP carried by and large email and telnet :)

Mike, when did nntp come around?

---

From: Joseph Touch <[email-masked]>
Date: Wed, 24 Mar 2021 16:57:28 -0700

> On Mar 24, 2021, at 4:10 PM, Michael Thomas <[email-masked]> wrote:
> 
> 
>>> IPsec certainly suffered this fate, though with filtering I'm not sure if it would have the right security properties for tunnel mode. Certainly had we used transport mode IPsec instead of SSL we wouldn't be coming back 25 years later worried about the TCP checksum. 
>> 
>> IMO IPsec was DOA because it didn't actually consider the needs of applications.
>> 
> Well there's no actual reason why IPsec needs to be run in the kernel except for maybe some issues with IP protocol numbers (can't remember if they could be exposed up at that time).
> Beyond that IPsec in transport mode doesn't seem to be much different than TLS other than covering the transport headers too.

Turns out that can be important for things like BGP (that’s why we had TCP-MD5 and now TCP-AO).

IMO, what IPsec got wrong was tunnel mode; it should have just been transport mode and IP-IP tunneling (RFC 3884 explains why).

Joe

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Mar 2021 17:05:46 -0700

> IMO, what IPsec got wrong was tunnel mode; it should have just been transport mode and IP-IP tunneling (RFC 3884 explains why).
Ah, interesting point. On the other hand for most VPN applications I've 
often wondered why they need to advertise/configure specific tunnel 
endpoints. Why can't you just follow normal routing to the destination 
and send back an ICMP to say they need to be authenticated/encrypted if 
need be. It seems it would solve a lot of weird problems that tunnels cause.

Mike

---

From: Joseph Touch <[email-masked]>
Date: Wed, 24 Mar 2021 17:06:35 -0700

> On Mar 24, 2021, at 5:05 PM, Michael Thomas <[email-masked]> wrote:
> 
> 
> Ah, interesting point. On the other hand for most VPN applications I've often wondered why they need to advertise/configure specific tunnel endpoints. Why can't you just follow normal routing to the destination and send back an ICMP to say they need to be authenticated/encrypted if need be. It seems it would solve a lot of weird problems that tunnels cause.

See the recent discussions on int-area.

ICMPs are largely blocked.

Joe

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Mar 2021 17:13:12 -0700

On 3/24/21 5:06 PM, Joseph Touch wrote:
>
>
>> On Mar 24, 2021, at 5:05 PM, Michael Thomas <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>>> On Mar 24, 2021, at 4:10 PM, Michael Thomas <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>>>> sure if it would have the right security properties for tunnel 
>>>>>> mode. Certainly had we used transport mode IPsec instead of SSL 
>>>>>> we wouldn't be coming back 25 years later worried about the TCP 
>>>>>> checksum.
>>>> Well there's no actual reason why IPsec needs to be run in the 
>>>> kernel except for maybe some issues with IP protocol numbers (can't 
>>>> remember if they could be exposed up at that time).
>>>> Beyond that IPsec in transport mode doesn't seem to be much 
>>>> different than TLS other than covering the transport headers too.
>>> IMO, what IPsec got wrong was tunnel mode; it should have just been 
>>> transport mode and IP-IP tunneling (RFC 3884 explains why).
>>>
>> Ah, interesting point. On the other hand for most VPN applications 
>> I've often wondered why they need to advertise/configure specific 
>> tunnel endpoints. Why can't you just follow normal routing to the 
>> destination and send back an ICMP to say they need to be 
>> authenticated/encrypted if need be. It seems it would solve a lot of 
>> weird problems that tunnels cause.
>
I haven't really noticed that. But it isn't necessary to have it 
conveyed by ICMP. Heck, with current VPN's there's no concept of 
discovery at all so plain old static configuration is obviously possible.

Mike

---

From: Alejandro Acosta <[email-masked]>
Date: Thu, 25 Mar 2021 08:11:51 -0400

On 24/3/21 8:05 PM, Michael Thomas wrote:
>>>>> mode. Certainly had we used transport mode IPsec instead of SSL we 
>>>>> wouldn't be coming back 25 years later worried about the TCP 
>>>>> checksum.

Sounds to me as a terrific idea.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 25 Mar 2021 09:44:40 -0700

> IMO, what IPsec got wrong was tunnel mode; it should have just been transport mode and IP-IP tunneling (RFC 3884 explains why).
 From a separation of concerns, I would agree. It's really a shame that 
IPSec turned into a VPN tunneling solution. Didn't GRE and all of that 
exist back then?

Mike

---

From: Joseph Touch <[email-masked]>
Date: Thu, 25 Mar 2021 10:27:45 -0700

> On Mar 25, 2021, at 9:44 AM, Michael Thomas <[email-masked]> wrote:
> 
> From a separation of concerns, I would agree. It's really a shame that IPSec turned into a VPN tunneling solution. Didn't GRE and all of that exist back then?

GRE docs in the IETF go back to RFC1701 in Oct 1994, originating as drafts in Sep 1993.

IPsec docs in the IETF go back to RFC1825 in Apr 1995, originating as drafts in Feb 1995.

So strictly, IPsec seems to have followed GRE. But GRE isn’t a replacement for IPsec; it’s a shim tunnel layer that is more comparable to IP-IP tunneling, e.g., RFC2003 in Oct 1996, which dates back to July 1995 - but even that is just a variant of RFC1853 in Oct 1995 (whose draft origins are not available AFAICT).

So IP encapsulation predates IPsec; merging it inside IPsec is the problem; combining the two is fine.

Joe

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 Mar 2021 13:53:51 -0500

> transport mode and IP-IP tunneling (RFC 3884 explains why).

But IPsec also got transport mode wrong because what it really got wrong
was authentication and authorization.  Since IPsec deals in IP addresses
as node IDs it would want to authenticate IP addresses, but that's a
lost cause in IPv4 because IP address assignments are just too dynamic.
Authorization is downstream of authentication, so for IPsec it's busted
too.

A better approach would have been to have had connection latching (RFC
5660) and IPsec-specific socket options so that IPsec would do no
authorization in transport mode.  That would have left authorization to
the application, and then authentication could be PKIX (or KINK, or...)
without IPsec caring one bit about name types or forms (again, the apps
would deal with that).

If you get transport mode right like that, then gateways for IP
tunneling over transport mode IPsec would just have been one of many
applications.

But I'm the author of RFC 5660, so call me biased.  The above opinion
has been a minority view since the inception of the now-concluded BTNS
WG.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Mar 2021 15:21:28 -0400

On Wed, Mar 24, 2021 at 6:23 PM Keith Moore <[email-masked]>
wrote:

>  Not sure I agree that TCP was optimized for file transfer - certainly a
> transport that's optimized for file transfer doesn't need to ensure strict
> ordering of all messages sent from one peer to another as long as they get
> reassembled in correct order when the file is written.   Otherwise, I agree.
>
> Keith
>
The slow start parameters are.

Sure, you can use TCP for many things, but if you are making an HTTP GET
request, slow start on send is doing the exact opposite of what you would
want (and often with parameters chosen for 1980s line speeds).

But HTTP didn't exist when TCP was invented. There was terminal connection
mode, then proto-FTP emerged out of terminal mode and then email from
proto-FTP.

My bigger point though is that don't try to make QUIC all things to all
people. It is better to hyper-optimise QUIC to Web browsing and write a
different transport for Web Services, a different protocol for real time
media, etc. etc.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 25 Mar 2021 12:34:12 -0700

On 3/25/21 12:21 PM, Phillip Hallam-Baker wrote:
> On Wed, Mar 24, 2021 at 6:23 PM Keith Moore 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>      Not sure I agree that TCP was optimized for file transfer -
>     certainly a transport that's optimized for file transfer doesn't
>     need to ensure strict ordering of all messages sent from one peer
>     to another as long as they get reassembled in correct order when
>     the file is written.   Otherwise, I agree.
>
>     Keith
>
> Sure, you can use TCP for many things, but if you are making an HTTP 
> GET request, slow start on send is doing the exact opposite of what 
> you would want (and often with parameters chosen for 1980s line speeds).
>
> But HTTP didn't exist when TCP was invented. There was terminal 
> connection mode, then proto-FTP emerged out of terminal mode and then 
> email from proto-FTP.
>
> My bigger point though is that don't try to make QUIC all things to 
> all people. It is better to hyper-optimise QUIC to Web browsing and 
> write a different transport for Web Services, a different protocol for 
> real time media, etc. etc.
>
>
Well to be fair, there was a lot of concern about congestive collapse of 
the internet back then. Considering we were all novices back in the 
80's, zillions of people rolling their own transport could have been a 
real mess. And of course targeting a small handful of kernels is a lot 
easier than convincing a zoo of different transports that they really 
ought to be doing this or that new bit of new research.

Mike

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 25 Mar 2021 12:46:45 -0700

> entering middle age with a rather nasty case of 'spread'.

A good place as any to remind people of Van Jacobson's netchannels:

http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Mar 2021 15:48:52 -0400

On Wed, Mar 24, 2021 at 5:37 PM Michael Thomas <[email-masked]> wrote:

> IPsec certainly suffered this fate, though with filtering I'm not sure if
> it would have the right security properties for tunnel mode. Certainly had
> we used transport mode IPsec instead of SSL we wouldn't be coming back 25
> years later worried about the TCP checksum.
>
> Mike
>
My research into Internet-PHB has reached the point where I am having to
write my own presentation layer because HTTP/HTTPS isn't giving me what I
need

Alice (@alice) is sending a message to a host belonging to here Mesh
Service Provider (@provider).

Alice and the provider both have public key credentials. But they are not
PKIX credentials or anything remotely similar. So TLS Client Auth really
isn't a help. And there are in any case two distinct layers of credentials:

1) Device/.Host credentials
2) Principal credentials

In the Mesh, every device and every host has its own unique credentials
that are bound to those of the principal that issued the credentials.

We do a kimono type protocol when negotiating a connection. First we
establish a key exchange between the devices and this is constructed so
that the service only learns the client device and client principal
credentials after we have a secure channel.

While working on this scheme I have come to the following conclusions:

1) Do packet fragmentation at the application layer, this enables
super-packets of up to 256 Ethernet frames.

2) Use AEAD (OCB prefered over GCM) to provide a 128 bit integrity check on
the super-packet.

3) Packet level integrity checks only need to cover the IP header because
their purpose is to allow diagnostics and debugging of lower layer issues.
Application layers MUST NOT rely on the IP packet or lower integrity checks.

Packet 'fragmentation' at the application layer is a win because we can
tune for the network conditions and do retry at the fragment (i.e. IP
packet) pevel.

Consider the case of 'streaming' video, this is not really 'streaming'.
Rather we have a sequence of related work units. For the sake of argument,
consider the case where we pull in a complete frame then decompress, then
present it [yes, I know that the CODECs don't enforce this]. We receive the
data, decrypt, check the tag and if it is OK, decompress and present to the
user.

If we are in a live video conference situation and we hit an error, we
probably just scrub that frame and move on to the next. If we have to scrub
too many, we tell the sender to reduce the streaming rate

If we are doing a live studio broadcast, then the output is always a few
frames behind live and we will need to be able to recover from an error by
identifying which packet(s) have errors and ask for them to be resent.

Slow start in this context means 'make the first frame you send be a
thumbnail at your lowest resolution, then adapt'.

---

From: Joseph Touch <[email-masked]>
Date: Thu, 25 Mar 2021 14:03:43 -0700

T

> On Mar 25, 2021, at 12:21 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> On Wed, Mar 24, 2021 at 6:23 PM Keith Moore <[email-masked] <mailto:[email-masked]>> wrote:
>  Not sure I agree that TCP was optimized for file transfer - certainly a transport that's optimized for file transfer doesn't need to ensure strict ordering of all messages sent from one peer to another as long as they get reassembled in correct order when the file is written.   Otherwise, I agree.
> 
> Keith
> 
> Sure, you can use TCP for many things, but if you are making an HTTP GET request, slow start on send is doing the exact opposite of what you would want (and often with parameters chosen for 1980s line speeds).

TCP slow-start on send remains OK for HTTP. with current initial window sizes. The original IW is too small only because requests are full of a LOT of junk.

TCP infers EOF from server-initiated CLOSE, however - which causes TIMEWAIT accumulation at the server, if specs are followed. The current approach is largely to ignore those specs.

So we COULD make protocols for particular uses, but given how little those specs are actually honored, it seems like a waste of our time.

Joe

---

From: Joseph Touch <[email-masked]>
Date: Thu, 25 Mar 2021 14:05:39 -0700

> On Mar 25, 2021, at 11:53 AM, Nico Williams <[email-masked]> wrote:
> 
> was authentication and authorization.
...
> authorization in transport mode.  
...
> has been a minority view since the inception of the now-concluded BTNS

And given I created BTNS, you’ll get no argument from me ;-)

But that seems like more of an argument against IKE than IPsec.

Joe

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 Mar 2021 16:14:56 -0500

> And given I created BTNS, you’ll get no argument from me ;-)

:)

> But that seems like more of an argument against IKE than IPsec.

I don't see anything wrong with IKEv2.  The problem isn't the KE, the
problem, and neither is ESP.

The problem is the architecture, and the parts of it relating to
authorization that get implemented by the KE (or related service).

In RFC 5660 I described two ways to do the binding of IKE authentication
and ESP+ULP flows using SAs instantiated by the KE.  One of those
completely eliminates or sidesteps a lot of RFC 4301, while the other
one works within the RFC 4301 framework by editing configuration on the
fly and automatically to obtain the same result.  A system that only
uses IPsec in the RFC 5660 way basically wouldn't even need to expose
anything like the PAD, or even the SPD.

Nico
--

---

From: Joseph Touch <[email-masked]>
Date: Thu, 25 Mar 2021 14:22:51 -0700

> On Mar 25, 2021, at 2:14 PM, Nico Williams <[email-masked]> wrote:
> 

Ahh - thanks.

Just wanted to know what we need to eventually fix…

Joe

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 Mar 2021 16:39:26 -0500

> Just wanted to know what we need to eventually fix…

It's water under the bridge.  Transport mode IPsec isn't going to take
off.  Among other things, having an out of band KE is not really a
selling point anymore -- everything uses TLS (or DTLS, or whatever) now
and that's that.

Doing cryptographic session protection closer to the application layer
won out, and always was going to because it's by far the most available,
portable, and flexible option for application developers.

Going back in time to make IPsec perfect from day one might not produce
a different result.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 25 Mar 2021 15:02:58 -0700

> Going back in time to make IPsec perfect from day one might not produce

We ended up with tortured history of DTLS because TLS had so thoroughly 
won that it was better in the eyes of many to invent a UDP alternative 
to TLS so that SIP could use TLS. Of course the joke is that UDP based 
SIP is probably a thing of the past because of bloat.

Mike