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

[Tom Herbert <[e-mail]>]

On Tue, Jul 9, 2019 at 4:38 PM Colin Perkins <[e-mail]> wrote:
>
> On 10 Jul 2019, at 00:16, Tom Herbert <[e-mail]> wrote:
> On Tue, Jul 9, 2019 at 3:35 PM Colin Perkins <[e-mail]> wrote:
>
>
> On 9 Jul 2019, at 05:35, Joe Touch <[e-mail]> wrote:
>
> On Jul 8, 2019, at 8:05 AM, Tom Herbert <[e-mail]> wrote:
>
> "A reliance on the presence and semantics of specific header
> 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”
>
>
> I am dubious about any statement that protocol ossification of
> 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.
>
>
> 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.
>
>
> 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?
>
>
> 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.
>
> 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.
>
>
> 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.

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

>
> 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/
>
>
>
>