Re: quic protection against replayed packets

Christian Huitema <huitema@huitema.net> Wed, 06 June 2018 22:45 UTC

Return-Path: <huitema@huitema.net>
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 ECD3C130DE6 for <quic@ietfa.amsl.com>; Wed, 6 Jun 2018 15:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HiV7P6TIuOx2 for <quic@ietfa.amsl.com>; Wed, 6 Jun 2018 15:45:40 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 1EBC8130DE1 for <quic@ietf.org>; Wed, 6 Jun 2018 15:45:40 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1fQhBR-0007by-Lg for quic@ietf.org; Thu, 07 Jun 2018 00:45:38 +0200
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1fQhBM-00036q-UU for quic@ietf.org; Wed, 06 Jun 2018 18:45:33 -0400
Received: (qmail 26090 invoked from network); 6 Jun 2018 22:45:28 -0000
Received: from unknown (HELO [192.168.0.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.104]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 6 Jun 2018 22:45:28 -0000
To: quic@ietf.org
References: <CA+tEvRTTyOove9pTfcUx3Z-B1G96Gz960ts4vC4cirx=yJTPxQ@mail.gmail.com> <CAN1APdfioOBXQZTP-ELspW4O-WK1eB5RtwwgHduUijoFnTXkMw@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <500105a3-ce68-682f-638c-8ef88b19207e@huitema.net>
Date: Wed, 6 Jun 2018 15:45:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAN1APdfioOBXQZTP-ELspW4O-WK1eB5RtwwgHduUijoFnTXkMw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------553F0C7898441B33ACE28036"
Content-Language: en-US
Subject: Re: quic protection against replayed packets
X-Originating-IP: 168.144.250.231
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.21)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5qdPPB2jC7jTI2z10eNhjMp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViw8DYIND/DzXBuw/UGiR4P87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBy0LkIcQZ+RRGzUcmNZyDXh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXXTg8/eGzRNUUVgcQ9smKz+YGaFKm4C5XbPm1ymSRhtX6AB68OLez+ eojwzjYnNgaU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRhK7unSGReaJhoESbMmiSIuggKW28pboyZCmKkHUYXamhm18qCfn8BSDP h8R09528Ws4d1Ezu4znpE/pclEKTkXtB4/4Pbrz2QtFuyl+Sh6eSMv+rdVKXDLDaTBj+LzkUfqb5 R4VemuUI6bcEARsm0KnLtMabt6P+t78klMitoc+NZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/k-K2h8sB80wB5EaUTrv3OQpFYUk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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, 06 Jun 2018 22:45:46 -0000

On 6/6/2018 2:32 PM, Mikkel Fahnøe Jørgensen wrote:

> The first line of defence is that most implementations would filter
> duplicate packets by tracking recently received packets, and dropping
> anything with a packet number older than what is tracked.

The packet number filed only contains the lower bits of the packet
sequence number -- 32, 14 or 6 bits depending on encoding. The higher
order bits are filled up based on currently expected value. The
completed 64 bit number (62 bit really) is then used as part of the
initialization vector when decrypting the packet. If a very old packet
is replayed, the receiver fill guess the high order bits wrong, the
decryption will fail, and the packet will be rejected.

If the packet is relatively recent, then most implementations rely on
packet tracking to detect that this packet is not expected. The tracking
data is the same data as the "dashboard" that is needed to implement the
selective ack process. So in practice, one way or another, the duplicate
packet will be ignored.

The threat analysis envisages a different attack: intercept a packet,
suppress the original transmission, and resend the same packet from a
different address. This is one of the reasons why the migration
specification includes a challenge/response mechanism.


>
> Assuming duplicates are not filtered:
>
> It depends on the packet content, or frame type more precisely. Some
> frames deliver flow control credits or ACK’s and here the problem is
> not only duplicates but also out of order delivery of same type of
> content in different packets. Here flow control cannot be reduced, so
> out of date content is ignored, and ACK’s cannot be unacked.
>
> For stream frames, each stream keeps track of already received ranges.
> An implementation could replace a range in the receive buffer with
> same content which is harmless, or with different content (for
> retransmissions done badly), but in either the case the application
> would (normally) only see a single coherent range. QUIC must offer
> that view to the application, but an implementation may expose more
> details and out of order ranges if so desired, but that is outside the
> protocol.

Frames can be repeated, not because of a replay attack but because of
"spurious retransmission", which can happen for a variety of reasons. So
yes, applications have to be able to tolerate that and not break.

-- Christian Huitema