Re: How does a server identify a new connection?

Chuck Crisler <chuck_crisler@affirmednetworks.com> Mon, 03 December 2018 15:55 UTC

Return-Path: <chuck_crisler@affirmednetworks.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 6115D130E5F for <quic@ietfa.amsl.com>; Mon, 3 Dec 2018 07:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] 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 H9up8I64fpRH for <quic@ietfa.amsl.com>; Mon, 3 Dec 2018 07:55:19 -0800 (PST)
Received: from out.exch021.serverdata.net (out.exch021.serverdata.net [64.78.24.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3FD12D7EA for <quic@ietf.org>; Mon, 3 Dec 2018 07:55:18 -0800 (PST)
Received: from MBX021-E6-VA-2.exch021.domain.local (10.216.132.150) by MBX021-E6-VA-2.exch021.domain.local (10.216.132.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.1531.3; Mon, 3 Dec 2018 10:55:17 -0500
Received: from MBX021-E6-VA-2.exch021.domain.local ([10.216.132.150]) by MBX021-E6-VA-2.exch021.domain.local ([10.216.132.150]) with mapi id 15.01.1531.007; Mon, 3 Dec 2018 10:55:17 -0500
From: Chuck Crisler <chuck_crisler@affirmednetworks.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
CC: Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Subject: Re: How does a server identify a new connection?
Thread-Topic: How does a server identify a new connection?
Thread-Index: AQHUh4uY03YsJ93/A0Ovj3peHAA1PaVmXZ2AgAABMACAAmsogIAACJAAgAAKMICAA7NNgIAAIVWAgAARfQCAAKHjgIAACi8AgAADJYD//7/ipg==
Date: Mon, 03 Dec 2018 15:55:17 +0000
Message-ID: <5250b1be4c8f450f877f310aff0f0785@affirmednetworks.com>
References: <CANatvzzaW-y6y6qN-K4W91WL+3A0fV3SLbOqcq5+SB=qXDpRXw@mail.gmail.com> <CABkgnnV9ONF5LEuCnpy8BsOHnFGidFbVKoMOeM9EohabMBMV6A@mail.gmail.com> <CANatvzxyUm86dNYAwiXeY_xHtcQBKuVWxa_3=9rgmFJtC4u+yw@mail.gmail.com> <20181130153734.GB19030@ubuntu-dmitri> <4A523623-09FD-4101-90A2-FCE202585B01@huitema.net> <20181130164440.GC19030@ubuntu-dmitri> <CANatvzw6+HKbXqqP_MK1rvF3dSiLryhMRABnxV6VUmdJnNQoKw@mail.gmail.com> <20181203031430.GA29864@ubuntu-dmitri> <CANatvzxicJ2D48cpNJe3Cz8+ju0VJmf25+8NTdjSvJXH8j9bog@mail.gmail.com> <20181203135630.GA8140@ubuntu-dmitri> <CAN1APdd8h0wVSr6kpLXnc7T7O5tbPBbsij9jyV6ooUxMAHg8Xw@mail.gmail.com>, <CAN1APdceYdWGGBgBLc-b6+SLP0x_dZHXDhDqq3TCpPmYdbssbA@mail.gmail.com>
In-Reply-To: <CAN1APdceYdWGGBgBLc-b6+SLP0x_dZHXDhDqq3TCpPmYdbssbA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.203.66.100]
Content-Type: multipart/alternative; boundary="_000_5250b1be4c8f450f877f310aff0f0785affirmednetworkscom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/XzAy5OiMETspBiGboT0Kct2zHaw>
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, 03 Dec 2018 15:55:22 -0000

For transmission to the Moon, Mars and deep space you use really good FEC. 😊

________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Sent: Monday, December 3, 2018 9:44:13 AM
To: Kazuho Oku; Dmitri Tikhonov
Cc: Christian Huitema; IETF QUIC WG; Martin Thomson
Subject: Re: How does a server identify a new connection?

An attacker might be able to force a slower packet route by misleading backplane routers.

There is also connectivity to the Moon, Mars and deep space to consider. I’m not sure if QUIC can handle the level of latency though.




On 3 December 2018 at 15.32.58, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>) wrote:

It ought not be that difficult to race packets. I know someone who measured a cross Atlantic datacenter to datacenter vs public network to same location.
It was 30ms faster on the internal network. It might have been RTT in which case a packet race it is still 15ms faster.

So if you have good connectivity it is viable to race packets over longer distances.




On 3 December 2018 at 14.56.54, Dmitri Tikhonov (dtikhonov@litespeedtech.com<mailto:dtikhonov@litespeedtech.com>) wrote:

On Mon, Dec 03, 2018 at 01:17:06PM +0900, Kazuho Oku wrote:
> 2018年12月3日(月) 12:14 Dmitri Tikhonov <dtikhonov@litespeedtech.com<mailto:dtikhonov@litespeedtech.com>>:
> > Why is the client struggling? In other words, what attack are we
> > defending against? Is this a real attack -- an adversary racing
> > against the very first client packet -- or a theoretical attack?
>
> I am not sure if the question is good way to consider how QUIC will be
> attacked, because the security properties (and therefore the attack
> vectors) of QUIC is different from that of TCP (that optionally have
> used TLS older than 1.3).

The question is asked in order to understand whether the proposed
defense mechanism is reasonable to implement. The implementation
cost on the server is high given that the attack does not exist.

> Having that said, what we know is that 1) man-on-the-side reset
> injection is a common technique, and 2) it is often coupled with
> packet payload inspection [1].

The reset injection attack described in the referred paper (Section
4.2.3) injects RST packets into an-already established connection.
Both in this and in the Quantum Insert scenarios the injected
packets do not have to race the legitimate packet(s) that were used
to construct them. This seems like an impossible problem for the
man-on-the-side to solve.

> With TLS 1.3, the only remaining way for a middlebox to inspect the
> payload of a packet in practice is to look at the SNI of the
> ClientHello. With QUIC, injection during the exchange of Initial
> packets would be the only way for a man-on-the-side attacker to
> disrupt the connection (assuming that we address the issue with
> spoofing path challenges / responses).
>
> Considering that, I would assume that racing a spoofed Initial to the
> server will be one of the vectors to be considered by the attackers,
> and therefore it's worth considering, documenting and encouraging
> implementations to have the countermeasures.

I agree that it's worth considering. I have been wanting to see how
this vector could be used for an attack by the man-on-the-side, but
no explanation has been put forth so far.

- Dmitri.

> [1] https://tools.ietf.org/html/draft-hall-censorship-tech-06