Is "Version Greasing" a new benfit or a new obstacle?

G Fairhurst <gorry@erg.abdn.ac.uk> Wed, 10 April 2019 08:48 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1C91201B2 for <quic@ietfa.amsl.com>; Wed, 10 Apr 2019 01:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaRsAIz83ira for <quic@ietfa.amsl.com>; Wed, 10 Apr 2019 01:48:30 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 58F7A1202BB for <quic@ietf.org>; Wed, 10 Apr 2019 01:48:30 -0700 (PDT)
Received: from G-MacBook.local (unknown [152.71.207.141]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 84DC61B002A1 for <quic@ietf.org>; Wed, 10 Apr 2019 09:48:27 +0100 (BST)
Message-ID: <5CADADDD.7010005@erg.abdn.ac.uk>
Date: Wed, 10 Apr 2019 09:48:29 +0100
From: G Fairhurst <gorry@erg.abdn.ac.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: quic@ietf.org
Subject: Is "Version Greasing" a new benfit or a new obstacle?
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/gt-Av1tqFSsaypzJI0OXC4vUJwQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2019 08:48:33 -0000

Obscuring the version of a protocol seems like a major design design 
decision for wider use cases. So, I'm trying to understand the 
motivation for version greasing.

(1) I know there were instances where some early versions of QUIC were 
blocked due to an uninitentional matching of the header. Is there 
evidence of intentional attempts to block updates to protocols?

(2) Thinking about operating a network that cares about user support and 
protection from unwanted traffic, I would expect that there would be 
cases where traffic pattern anomolies are found and the appropriate 
thing would be to try to determine if a new protocol had been deployed 
and monitor it, if not, then the next most obvious thing could be to 
block all unexpected traffic, that seems like a decision to hide the 
version could increase ossification for new versions in these cases.

(3) Similarly, if a threat is known to impact only a specific (older) 
version, it would seem to motivate a drop of that traffic that seeks to 
use that version, while still permitting other traffic. Forcing version 
detection to use pattern matching/ML will lead to less predictable 
outcomes, or blocking based on address, etc.

(4) This obfusticates the most basic piece of reporting information used 
for support. It hides the extent of deployment of the current protocol 
version and prevlance of old implementations.

(5) On the support, if a problem only emerges when a particular version 
is used with a particular address, then this helps pinpoint the issues. 
Matching client versions to servers is much more of an issue if the user 
community uses a wide range of servers (less so, I expect for major 
providers: google, facebook, etc, etc), but significant when there is a 
use of a diverse set of external sites and sites with their own load 
balancers, etc and a need to manage interactions with L2 services.

I am intersted in knowing if this is likely to benefit or be a new obstacle?

Gorry