Subject: [Edm] On Section 3.2. At what level should versioning occur?

From: Eliot Lear <[email-masked]>
Date: Thu, 5 Aug 2021 11:00:57 +0200

Martin and friends,

Thanks for this draft.  I also appreciate the lastest PR that reduces 
out the middlebox discussion.  We might want to have a more targeted 
revisiting of that section, but by pulling that stuff out you have 
focused down onto the subject of the draft, which is the risk of disuse.

I really like your section 3.2, but it does presume that the lower 
layers are able to accommodate exposing of version information.  Below 
the IP layer, when IEEE 802 is used, we are in very good shape; but does 
everything below that hourglass neck have that attribute, and do we want 
to demand that in order to implement v4/v6?  To that end, my suggestion 
is that you simply note this as an issue when we interact with other 
technologies.

Back in our little corner of the world, this has some broad IANA policy 
implications.

Interestingly, when we do port allocations, we generally say that 
applicants SHOULD include versioning information in their protocols 
because the IANA will not allocate new port numbers for existing 
services.  But is that the right approach, and what is meant by an 
existing service?  If the service is accomplishing the same thing, but 
the encoding of the underlying protocol has shifted, should we really be 
so strict?  While some quickly envision the world moving to QUIC, let's 
agree that there are some applications that won't find QUIC to be The 
Answer, and that port numbers may remain a somewhat scarce resource.  
And so maybe a version field ISN'T such a big deal, but requires 
additional protections for future use for those who are keeping score, 
yes I'm arguing both sides of the issue].  One example might be that 
two-party protocols never FAIL when they see a greased version but 
simply come back with "version not supported" or "I see grease" or some 
such.

Eliot

---

From: Erik Auerswald <[email-masked]>
Date: Thu, 5 Aug 2021 11:30:15 +0200

Hello Eliot,

On Thu, Aug 05, 2021 at 11:00:57AM +0200, Eliot Lear wrote:
> [...]
> layers are able to accommodate exposing of version information. 
> Below the IP layer, when IEEE 802 is used, we are in very good
> shape; but does everything below that hourglass neck have that
> attribute, and do we want to demand that in order to implement
> v4/v6?  To that end, my suggestion is that you simply note this as
> an issue when we interact with other technologies.

I do not think this I-D section argues against using version information
for a protocol, but rather that increasing the version number is not
sufficient for implementing and deploying a new version of a protocol
at a later time.

> [...]

I think that is good advice, since IMHO versioning information is a
necessary prerequisite for later on introducing another version.

> [...]

Thanks,
Erik

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 06 Aug 2021 11:33:18 +1000

> is that you simply note this as an issue when we interact with other 

More on this below, but I don't read Section 3.2 as declaring a mandate, but just as making a suggestion.
 
> existing service?  

The idea that port == service is largely a dead idea, so I don't see port numbers are relevant to this discussion.  (I think that we should probably not accept more allocations, without exceptional justification.  We have SRV and SVCB and other discovery/configuration things in ample measure.)

Your advice is very much valid there.  You are saying that TCP/UDP port numbers are not good for versioning.  That's right because they aren't.  That's not what they were designed for and that is not how they are used in practice.

> If the service is accomplishing the same thing, but 
> yes I'm arguing both sides of the issue].  

This is probably a different question now, and outside the scope of this work.  (I'll note that you said "strict" here, but I don't see anything that mandates a particular design direction in the draft. It seems pretty clearly optional advice to me.)

FWIW, as you mention ports, my position on *transport-level* versioning goes something like:

1. port numbers are not for versioning
2. consequently new transport protocols need versioning (this includes transport-adjacent protocols like TLS) or some way to allow for their eventual replacement; this is because there is no functioning facility in the IP layer (or UDP or TCP for that matter)
3. new transport protocols are expensive to build and should be rare (the difficulty of building a versioning scheme is part of that)
4. new uses of transport protocols should be secured and should use TLS or QUIC
5. new uses of transport protocols that use TLS or QUIC can use ALPN to manage their own versioning and so do not need their own versioning design

This document covers points 2 and 3 and talks generically about point 5, which is all it can really do.

> One example might be that 

That is essentially how QUIC and TLS work (though "I see grease" => "grease is just ignored").

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Aug 2021 05:32:38 +0200

> 4. new uses of transport protocols should be secured and should use TLS or QUIC

There are lots of good reasons when you do not want to do transport header
confidentiality. For example when you have a mission specific network deployment
that needs hop-by-hop transport layer quality measurements (per stream latency, loss,
jitter reordering etc..) as part of network to subscriber SLA. And your payload
is secured anyhow (think ABR in access SP IPTV services). Yes, there are long
term hw implementations for per-TCP-flow performance metrics measurements. And
probably more now for use not in video as i am familiar with, but also in DCs.

There are also a lot of good reasons not to think everything can or should run
on top of TLS or QUIC.  Think of real-time services whose resilience scheme
is not based on ARQ and that have more accurate real time measurement requirements
in collaboration between network and endpoints.  Anything using RTP for example,
or future enhancements variations of such transports. 

Also, no need to promote TLS and QUIC, they will surely get more adoption then
where they are the best choice, because many of the workflows where they hurt are
not well thought out during application development time, and then choosing TLS/QUIC
will be be a foregone conclusion in the absence of more application developer expertise
into the alternatives and other ecosystem reasons to go for the least common,
most widely adopted denominator.

And not even talking about the problem of building
firewalls / IDS with end-to-end encryption i a trustworthy way.

And that is just unicast.

Cheers
    Toerless