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

"Deval, Manasi" <manasi.deval@intel.com> Mon, 15 April 2019 18:48 UTC

Return-Path: <manasi.deval@intel.com>
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 2B52812017D for <quic@ietfa.amsl.com>; Mon, 15 Apr 2019 11:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 gEzsGbLRydYB for <quic@ietfa.amsl.com>; Mon, 15 Apr 2019 11:47:55 -0700 (PDT)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617D1120046 for <quic@ietf.org>; Mon, 15 Apr 2019 11:47:55 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Apr 2019 11:47:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.60,354,1549958400"; d="scan'208,217";a="149639879"
Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by FMSMGA003.fm.intel.com with ESMTP; 15 Apr 2019 11:47:53 -0700
Received: from orsmsx123.amr.corp.intel.com (10.22.240.116) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Apr 2019 11:47:53 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.39]) by ORSMSX123.amr.corp.intel.com ([169.254.1.141]) with mapi id 14.03.0415.000; Mon, 15 Apr 2019 11:47:52 -0700
From: "Deval, Manasi" <manasi.deval@intel.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Ted Hardie <ted.ietf@gmail.com>, "Brian Trammell (IETF)" <ietf@trammell.ch>
CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "quic@ietf.org" <quic@ietf.org>, "Border, John" <john.border@hughes.com>, Roberto Peon <fenix@fb.com>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Subject: RE: Is "Version Greasing" a new benfit or a new obstacle?
Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle?
Thread-Index: AQHU73pCar/cuMtfrEumudEVMGce4KY2EbmAgAACAICAAAdtgIAADYsAgAAcxQCAAMryAIAABNSAgAZaAACAAAJpgIAAHasAgABG84CAAARsAIAAA2YA//+ycFA=
Date: Mon, 15 Apr 2019 18:47:52 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998BA3EF85@ORSMSX111.amr.corp.intel.com>
References: <5CADADDD.7010005@erg.abdn.ac.uk> <EBF1BF30-62A5-4659-8AEC-0D5B3F2D65C6@fb.com> <BL0PR11MB3394294313F8F54A3D0CF4A3902E0@BL0PR11MB3394.namprd11.prod.outlook.com> <CAN1APdcm0hnT_Mu7D7x5QM6pApOQw1RdWCBkgY16bd5YWNtFkA@mail.gmail.com> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <CAN1APdeSF0-_N=mb1xkoe_qLwoVqP+X9_Wawi=Zu__6wdHtbOQ@mail.gmail.com> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <CAN1APde2SO6fkNzyznbv2-xNuXkkuC=bN3p8xRgwmRAmsZxrgA@mail.gmail.com> <EC83F879-6A46-405E-B0A1-777B7A5AF55B@trammell.ch> <CAN1APdcCAK9aaGVA2aRUaOytmpzof3LB_XVVsasKmJaK5=d2hQ@mail.gmail.com> <C09D5A73-E83A-4096-864D-456A684EE1E2@trammell.ch> <CA+9kkMAbLr_EUPfmyORo8Rg3ydza+gwkQdX7fFexETZs9THESQ@mail.gmail.com> <CAN1APddKgPPOfKU7oqyq92a=eTewDyoSGo=PMaBWO-H+hxyTGw@mail.gmail.com> <CAN1APddFUg25BRpdKqLFvefFLXSD+knCNvODxSeWo9zXdGOSUQ@mail.gmail.com>
In-Reply-To: <CAN1APddFUg25BRpdKqLFvefFLXSD+knCNvODxSeWo9zXdGOSUQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.22.254.138]
Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998BA3EF85ORSMSX111amrcor_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/JYF255wFS4zX88rCs7Jog_KUKXA>
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: Mon, 15 Apr 2019 18:48:00 -0000

The current connection setup happens from client to server. Version negotiation draft states that:
the client
   maintains a list of QUIC versions it supports, ordered by preference.
   Its Initial packet is sent using the version that the server is most
   likely to support

The initiator of the greased version value is crucial for this definition. Is this agreed upon already? If the greased version value was chosen by a client, this can get inconsistent very quickly, so greased values must universally correspond to particular QUIC operational version.

For the middleboxes doing loadbalancing and firewall, they need to identify and classify incoming packets based on the IP, UDP and QUIC header fields for effective operation. We are already seeing that the length of connection Id cannot be deciphered in short header packets. Would the version number negotiation open up more issues like this.

Manasi




From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Monday, April 15, 2019 8:57 AM
To: Ted Hardie <ted.ietf@gmail.com>; Brian Trammell (IETF) <ietf@trammell.ch>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; quic@ietf.org; Border, John <john.border@hughes.com>; Roberto Peon <fenix@fb.com>; Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?

s/TLS/TCP/ first line

19 at 17.44.44, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>) wrote:
Sure, these examples are chosen exactly because they don’t work well with TLS. If you argue that TLS fallback doesn’t always work, it is no good coming up with examples where they do work, especially when it is not contested that there are cases where fallback is valid.

Since QUIC is QUIC, any cloaking applies to all application classes. You can’t argue cloaking is not needed because HTTP and DNS does not need it due to fallback. Besides, it is an unproven assumption that cloaking is not worthwhile for cases where fallback is required. If both peers accept QUIC and the network generally does not block random appearing UDP cloaking could work, although it does not guarantee privacy. Part of the concerns are that when recognised as QUIC, only certain QUIC versions are permitted. That could happen due to broken subsystems where packets go to bucket A or B, where A is QUIC and B is everything else.

FWIW I’m not convinced that this version negotiation cloaking is worthwhile or even beneficial, I’m just pointing out that whatever you do, it has consequences.

On the specific example of DNS falling back to TLS. That might not work if QUIC-DNS introduces a higher level of privacy. A fallback would be a privacy leak. Of course, that would then break things on another level, so it would be an opt-in, but if chosen, fallback should be disabled.

Mikkel

On 15 April 2019 at 17.29.22, Ted Hardie (ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>) wrote:
Howdy,

On Mon, Apr 15, 2019 at 4:15 AM Brian Trammell (IETF) <ietf@trammell.ch<mailto:ietf@trammell.ch>> wrote:


> On 15 Apr 2019, at 11:28, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>> wrote:
>
> QUIC is not going to be used only for HTTP/3 and I don’t see how TCP fallback will work for the general case.
>
> A lot of games, VR applications, streaming services etc. are going to build semi-proprietary QUIC versions, or at least use QUIC with customised application protocols where TCP fallback is simply pointless because it doesn’t support the framing needed and if it were possible, why would adapt an application layer protocol to work on TCP if you don’t have to - of course you have to if it gets blocked - hence try to avoid that.

So you see the deployment strategy for these applications to be "zero availability on non-UDP-accessible networks"? That seems bold to me unless you're talking about QUIC being used as a replacement for "application-provided transport layer over UDP", which is certainly a big part of the market but not all of it.

There are classes of applications for which it is not particularly bold, since they don't function well at all with TCP.

There are also classes where the fallback would be to a different stack.  DNS over QUIC might fall back to DNS over TLS if UDP is blocked, for example.  QUIC doesn't need a fallback there because the DNS stack has one.

Ted


You could always tunnel UDP over TCP of course, but from a transport layer perspective (and a transport-visible wire image perspective), that's a TCP fallback.

> I don’t have any numbers on transparency, but given the reach of voice call applications, you can probably safely assume that UDP will be supported through most networks.

When we looked at this, admittedly a few years ago, we saw UDP blocking on par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of paths. That's one nine of availability pathwise, which is... not great.

> The problem again is if only some UDP is allowed through traffic inspection or at least port numbering.
>
> It can be a good thing that a QUIC version is detectable if the alternative is that anything unknown gets blocked. That is the big unknown.

As I said in my other message this morning, I don't think version negotiation greasing is useful at this time because there is no reasonable model of a wire-visible version difference where an on-path device might want to let through one greased-version and not another greased-version, because the wire-image profiles and semantic properties of those two versions are by definition of greasing identical.

At this point, given connection-availability as the metric to optimize for, it seems like reducing features that might be mistaken for QUIC-distinguishers in the wire image would be useful, and version greasing seems like one such feature.

> Will it help to be is opaque as possible, or not? Some of the scenarios I posted earlier show that no matter what you do, something will get in the way.

This all comes down to the threat model, and the model of incentives for on-path devices.

I personally think the correct design target is to put trivial QUIC-discriminability into the wire image, since there will be a lot of pressure to distinguish QUIC from not-QUIC traffic regardless of what we do, and if we don't put grippy bits in the wire image, the distinguishing functions will grip on to the slippy bits, with difficult to predict outcomes. I recognize I am in the minority (of people who speak up) on this issue, though.

Cheers,

Brian

> On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch<mailto:ietf@trammell.ch>) wrote:
>
>> hi Mikkel,
>>
>> perhaps a bit late to this party, I'm not sure I understand the process you envision by which the TCP fallback will go away.
>>
>> Once it's in, it'll get used in a high enough proportion of cases that the availability risk of turning it off, balanced against the fact that it already works (as it's pretty much mandatory for deploying in today's 95%-UDP-transparent Internet), will go away very slowly indeed.
>>
>> Cheers,
>>
>> Brian
>>
>> > On 11 Apr 2019, at 10:20, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>> wrote:
>> >
>> > In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC.
>> > If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything.
>> > Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not.
>> >
>> >
>> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind (mirja.kuehlewind@ericsson.com<mailto:mirja.kuehlewind@ericsson.com>) wrote:
>> >
>> >> Hi Mikkel,
>> >>
>> >> I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP).
>> >>
>> >> Mirja
>> >>
>> >>
>> >>
>> >> On 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahnøe Jørgensen" <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org> on behalf of mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>> wrote:
>> >>
>> >>
>> >> Let’s say China makes a deal with Google to allow their search engine (a not entirely unreasonably proposition).
>> >> The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1.
>> >>
>> >>
>> >>
>> >> Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised
>> >> zone and users use Chrome).
>> >>
>> >>
>> >> Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC.
>> >>
>> >>
>> >> Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down
>> >> its service.
>> >>
>> >>
>> >> Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range.
>> >>
>> >>
>> >> Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area.
>> >>
>> >>
>> >> Disclaimer: I’m not affiliated with Google and this might not at all be how things would work, but it does highlight some of the challenges.
>> >>
>> >>
>> >> Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing
>> >> to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations.. Advisers point out that those services
>> >> run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently
>> >> use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are
>> >> the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus.
>> >>
>> >>
>> >> Or an endless number of other developments over the next few decades if the past few years is anything to go by.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>) wrote:
>> >>
>> >> Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion.
>> >>
>> >>
>> >> Gorry
>> >>
>> >> On 10 Apr 2019, at 18:25, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>> wrote:
>> >>
>> >>
>> >>
>> >> China blocks as a rule.
>> >> Russia is running an experiment to block the rest of the internet.
>> >> USA blocks net neutrality.
>> >> EU blocks cookies.
>> >> GB blocks itself.
>> >>
>> >>
>> >> So blocking is not limited to what an operator considers best for business.
>> >>
>> >>
>> >>
>> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com<mailto:john.border@hughes.com>) wrote:
>> >>
>> >>
>> >> I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to
>> >> not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others...
>> >>
>> >>
>> >>
>> >> John
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: QUIC <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>> On Behalf Of Roberto Peon
>> >> Sent: Wednesday, April 10, 2019 12:52 PM
>> >> To: G Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>;
>> >> quic@ietf.org<mailto:quic@ietf.org>
>> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?
>> >>
>> >> WARNING: The sender of this email could not be validated and may not match the person in the "From" field.
>> >>
>> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>> >>
>> >>
>> >> You're kinda between a rock-and-a-hard-place either way:
>> >>
>> >> - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification.
>> >> - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not.
>> >>
>> >> My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate.
>> >>
>> >> My guesses:
>> >> IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In
>> >> other words, I have a doubt that stating the version in an observable way will prevent the use of such tools.
>> >>
>> >> Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe).. If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation
>> >> fingerprints.
>> >> -=R
>> >>
>> >>
>> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org> on behalf of
>> >> gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>> wrote:
>> >>
>> >> 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