From nobody Thu Nov 12 15:23:17 2020 Return-Path: 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 8BAE23A0EF2 for ; Thu, 12 Nov 2020 15:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 bH3LxQp7Vpqq for ; Thu, 12 Nov 2020 15:23:13 -0800 (PST) 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 9ED143A0ECC for ; Thu, 12 Nov 2020 15:23:13 -0800 (PST) Received: from xse3.mail2web.com ([66.113.196.3] helo=xse.mail2web.com) by mx128.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kdLvo-0006xA-1F for quic@ietf.org; Fri, 13 Nov 2020 00:23:10 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CXHhW2lmwz515L for ; Thu, 12 Nov 2020 15:23:07 -0800 (PST) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kdLvn-000270-8S for quic@ietf.org; Thu, 12 Nov 2020 15:23:07 -0800 Received: (qmail 15035 invoked from network); 12 Nov 2020 23:23:07 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.90]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Nov 2020 23:23:07 -0000 To: Martin Thomson , quic@ietf.org References: <20201112181509.GB98816@okhta> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Subject: Re: [New Issue] CID based attacks Message-ID: <965fa1e3-1cd2-1c76-6966-35eb5395095d@huitema.net> Date: Thu, 12 Nov 2020 15:23:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0EF755B7A269A43889383F27" Content-Language: en-US X-Originating-IP: 66.113.196.3 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.3/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.3/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0cThwnZT+ODcFyeCwCHoUjupSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fu/OisfnEY04p9DKLjoKerTU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/+iU2d2HKPwiXQ4BZ4N2yebyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilUN7TTX3qb0a 8RNcOLCOSd4jWNjicid92+JsmBTBq789D+OlGs8WYo6xXMPhdiglxYj0sOjeekoQCPq/61Rz3xua O75ywFmUG/yBLieSBzSQvmslaR4tDn8LFSxb+xTMCRg66gs5OuzYxJgw5atIxeMSWlPquJoiJm+Y dI8PappRBLboNblxAkv88QN/My/4aVSOooz8yQ9mVKKuRzwBLToBQiPgeiQlR5feV9uViHUFXPWl FdaGOH191uXjgjQN/fm03Pjl8H9TodtJfdqYop2CfrA6+JiIGkK7HEN/6KLYNWOfRy3it5pbjqbJ QF61U112fwop9BTafX0DKHjywhGbO+8nMRYL9kekVL4dhx06ifnL+9wgoTj4ygNPw1XfN0zsCG5v xMF5WG1gYscNCfISP4VPJRUjPgTf43t5z5OGMMhkxyAKDRV/o3FuwxpnRHnKFOL2qbwhklIekV0n lts= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 23:23:16 -0000 This is a multi-part message in MIME format. --------------0EF755B7A269A43889383F27 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/12/2020 2:15 PM, Martin Thomson wrote: > On Fri, Nov 13, 2020, at 05:15, Dmitri Tikhonov wrote: >> My question would be: Why aren't connections in the other 11 implemen= tations >> enter the Draining State? > Neqo should. (I'm not sure that I have a test against our command-line= server though, that is almost certainly doing bad things.) The description of the experiment says "*To conduct the experiment, I had the client open and hold a QUIC connection with source CID 1 and destination CID 2 for a maximum of 10s with the server, and then close it. We then idle for 10s and repeat the steps a second time." Should the draining period be longer than 10 seconds? Section 10.2 of the transport spec says: "*The closing and draining connection states exist to ensure that connections close cleanly and that delayed or reordered packets are properly discarded. These states SHOULD persist for at least three times the current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY ]." That's what picoquic implements, and that's typically way less than 10 seconds. The description of the experiment does not say whether the successive connection attempts used the same IP address. For Picoquic at least that's important, because Picoquic retrieves the handshake context using the combination of Initial DCID and client IP + port. Multiple connection attempts using the same Initial DCID and different IP addresses will be treated as independent connections. This was one of the suggestion in https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-01.= -- Christian Huitema --------------0EF755B7A269A43889383F27 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/12/2020 2:15 PM, Martin Thomson wrote:

On Fri, Nov 13, 2020, at 05:15, Dmitri Tikhonov wrote:

My question would be:  Why aren't connections in the other 11 implementations
enter the Draining State?

Neqo should.  (I'm not sure that I have a test against our command-line server though, that is almost certainly doing bad things.)

The description of the experiment says "To conduct the experiment, I had the client open and hold a QUIC connection with source CID 1 and destination CID 2 for a maximum of 10s with the server, and then close it. We then idle for 10s and repeat the steps a second time." Should the draining period be longer than 10 seconds? Section 10.2 of the transport spec says: "The closing and draining connection states exist to ensure that connections close cleanly and that delayed or reordered packets are properly discarded. These states SHOULD persist for at least three times the current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY]." That's what picoquic implements, and that's typically way less than 10 seconds.

The description of the experiment does not say whether the successive connection attempts used the same IP address. For Picoquic at least that's important, because Picoquic retrieves the handshake context using the combination of Initial DCID and client IP + port. Multiple connection attempts using the same Initial DCID and different IP addresses will be treated as independent connections. This was one of the suggestion in https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-01.

-- Christian Huitema


    

  


--------------0EF755B7A269A43889383F27--