Subject: [tsvwg] Protocol ossification in draft-ietf-tsvwg-transport-encrypt-07.txt

From: Tom Herbert <[email-masked]>
Date: Mon, 8 Jul 2019 08:05:49 -0700

Hello, I have a comment about the discussion of protocol ossification.
>From the draft:

"A reliance on the presence and semantics of specific header
information  leads to ossification, where an endpoint could be
required to supply a specific header to receive the network service
that it desires.  In some case this could be benign or advantageous to
the protocol"

I am dubious about any statement that protocol ossification of
transport layer by middleboxes is a good thing. There are too many
examples where protocol ossification has impeded or prevented
deployment of IP protocols or features (QUIC, MPTCP, TFO, SCTP, EH,
etc.). Yes, we need to take effects of protocol ossification into
consideration when deploying a new end to end protocol or features,
but that is for practicality and not by choice. IMO, protocol
ossification is something we have to work around and undo, not a
principle to embrace.

If there is some case that is "benign or advantageous to the protocol"
then please provide a _specific_ example. And if such a case exists
then I'd expect there would be general consensus that the protocol
definition was wrong in the first place to have allowed so much
extensibility and that the ossification should be standardized in the
protocol specification.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 8 Jul 2019 21:35:46 -0700

> On Jul 8, 2019, at 8:05 AM, Tom Herbert <[email-masked]> wrote:
> 
> information  leads to ossification…"

Relying on the semantics of a protocol header is also called a standard. 

> “...In some case this could be benign or advantageous to
> the protocol”

> transport layer by middleboxes is a good thing.

Ossification and stability are two sides of exactly the same coin.

It’s called ossification when the variation of a standard is no longer supported, e.g., because of middleboxes assumptions beyond that defined by the standard.

It’s called stability when we can rely on a set of definitions that constrain arbitrary variation in controlled ways.

Joe

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Jul 2019 23:35:38 +0100

> On 9 Jul 2019, at 05:35, Joe Touch <[email-masked]> wrote:
>> On Jul 8, 2019, at 8:05 AM, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Exactly. 

We might choose to declare certain properties of a protocol as invariant, because we want a stable substrate on which others can build, including middlebox vendors. That is, we might choose to intentionally accept and encourage ossification, because we believe the benefits of stability for those features outweigh the benefits of flexibility. 

The problem is not ossification as such. It’s ossification of things that we intended to be changeable. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Jul 2019 16:16:51 -0700

> We might choose to declare certain properties of a protocol as invariant, because we want a stable substrate on which others can build, including middlebox vendors. That is, we might choose to inte…

Colin,

Who is "we" in this description? Is this is IETF or an open community
that has diligently evaluated the effects of ossification of some
feature and has achieved consensus that too much flexibility in a
protocol was a mistake; or is it random vendors or network operators
that decide what they support per their convenience or that of their
marketing department with the side effect that the Internet is driven
to support only the least common denominator of protocols and protocol
functionality?

> The problem is not ossification as such. It’s ossification of things that we intended to be changeable.
Not sure I see the difference. In any case, the irony of this
discussion is that ossification of the transport layer by middleboxes
is precisley a major motivation driving encryption the transport
layer. E.g. a principle of QUIC protocol design is "Beyond the obvious
privacy benefits, encryption prevents ossification of the protocol by
middleboxes, which can't make routing decisions based on information
they can't understand." I doubt that a one-off statement that
ossification could be a good thing will much effect on those building
new transport protocols for widescale deployment. For that matter, I'm
still doubtful that any of the purported benefits listed in the draft
are sufficient rationale to convince any transport layer and
application developers not to encrypt the transport layer.

Tom

---

From: Colin Perkins <[email-masked]>
Date: Wed, 10 Jul 2019 00:38:05 +0100

> On 10 Jul 2019, at 00:16, Tom Herbert <[email-masked]> wrote:
> On Tue, Jul 9, 2019 at 3:35 PM Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
>> 

An IETF working group might decide to document such properties in the RFC describing a particular protocol. The QUIC invariants draft does this, for example. 

> application developers not to encrypt the transport layer.

I’m certainly not saying that we shouldn’t encrypt the transport layer. I am saying that encrypting the transport layer has some benefits, but also has some costs. There might be reasons to encrypt all the transport headers, but there might also be reasons to intentionally expose some information and accept that it will be ossified. There’s a trade-off, and different protocols  might make different choices here.

QUIC chooses to encrypt almost everything, for example, and that might be the right trade-off for its users. By way of contrast, when Secure RTP was being designed the working group intentionally decided to leave some of the transport headers unencrypted, because it was considered important to support hop-by-hop compression of IP/UDP/RTP headers by middleboxes. That was a conscious design choice at the time, since the group perceived a benefit from allowing those headers to be ossified.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Jul 2019 19:04:25 -0700

Colin,

I agree that loss of visibility adversely impacts middleboxes
consuming the information, similar to how the ramp up of TLS adversely
impacted middelboxes that were parsing HTTP to optimize
communications. But, I disagree with the idea that purposely hacking
up transport layer protocols to make parts of the protocol visible in
plain text is the right solution. What we need is explicit host to
network signaling. This should be in the network layer and can convey
information about the transport layer, application layer, or other
useful information to the network. This would be protocol agnostic
(get middleboxes out ossifying DPI), under application control as to
what is made visible to network, and could be scoped to restrict
visibility of information to trusted parties. Extension headers are
the correct mechanism for this signaling. IMO, this draft dismisses
them as a possible solution too easily, but I think things will move
in that direction regardless.

Tom