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

Tom Herbert <> Wed, 10 July 2019 02:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D72A1200F6 for <>; Tue, 9 Jul 2019 19:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mdkGPSdGPVbM for <>; Tue, 9 Jul 2019 19:04:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49E8D120048 for <>; Tue, 9 Jul 2019 19:04:38 -0700 (PDT)
Received: by with SMTP id v15so343984eds.9 for <>; Tue, 09 Jul 2019 19:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wrYjno+mbnpZU30jpjfcey2GqC3Ih1O7WbEiq3QLN9Y=; b=f0gFXBa+fZzvCK1eb5cFUabXcBAGpJI9qkcAYm44RRf7FLAm6MAqXs4Xf/gHFfcZbk EBQDSCsWN/a/+hG70JL5G91iI/dH/Z2ytAybn68kooRzDBOj0JNTr8iy6nW4ktHtZYsG J2sjcExRPc5G2IGCjziH+uCuFvn02kMFWNerkl2sbrEthMiJ51RG+sbqvg3EIAYWdshb n7dDvJsMmBSrUloNOlFtsSMLP/Dqo4p9TAvSF41ivPK7OeAEjqNUWpkdVhOYz2oTlpl5 8hToHpy1Zw8MXq10NhDnAb5E83d1cRf1/eJ/U6vprf2+7vC+V9sfX7F3x2AScvAkjBOP 2BBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wrYjno+mbnpZU30jpjfcey2GqC3Ih1O7WbEiq3QLN9Y=; b=T7qPO5juecj8xZhE3MrOE9E5o/QjYIXVAUDPJ2IJJDFr1eT81EMLJpIy/ANGUVxDpY O1ljkMcpDEfRq0PDcvtWgZhM04ud5pRnIg7BnyPvDrsxabTVfOo1ms25G6MCNbEaaCMN AvxJDRZc/3ZrKPF0bWlSoCJaL+2zctJG+TOMEAPfzXNNlmTq6mLEZVoa1gy8kiTio4P1 Oh8MjT8dtxQu7JvZN83wbQwoJ4m8cJU490vyvU6Ef+a5pFmNS8RdQbc6IRFmK8U6z+Vu YWQWy9wNfBhKXia+uKLp5xFWnyip/3fVpRNUEfM3Ro6R3/rUGL0tZSDF5EzlghMDYEWI 1lyA==
X-Gm-Message-State: APjAAAWlaWXf9u3uKa5+SmCWI1U7iEq4qfflzUzk4ReI9Wl91uXu91V3 S23WDzFEQ0j5SDOlsUI7CJvA+hJatEZqHbSGE1RdAw==
X-Google-Smtp-Source: APXvYqxbgRSo43ZnBy5rpDhV0UfUbyD+FDDszGC1BBdzL/5EUPP9458am2glM2QXbSqi1Sc1AEnOMRJtNoxxfb+9IBA=
X-Received: by 2002:a17:906:d183:: with SMTP id c3mr24154197ejz.149.1562724276602; Tue, 09 Jul 2019 19:04:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 9 Jul 2019 19:04:25 -0700
Message-ID: <>
To: Colin Perkins <>
Cc: Joe Touch <>, tsvwg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] Protocol ossification in draft-ietf-tsvwg-transport-encrypt-07.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Jul 2019 02:04:41 -0000

On Tue, Jul 9, 2019 at 4:38 PM Colin Perkins <>; wrote:
> On 10 Jul 2019, at 00:16, Tom Herbert <>; wrote:
> On Tue, Jul 9, 2019 at 3:35 PM Colin Perkins <>; wrote:
> On 9 Jul 2019, at 05:35, Joe Touch <>; wrote:
> On Jul 8, 2019, at 8:05 AM, Tom Herbert <>; 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.


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.


> 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