IETF Logo Mail Archive

Re: [quicwg/base-drafts] ICMP and ICMPv6 PMTUD with asymmetric connection-ids (#1243)

Kazuho Oku <notifications@github.com> Tue, 05 June 2018 07:19 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAF0130F08 for <quic-issues@ietfa.amsl.com>; Tue, 5 Jun 2018 00:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 GpbB6t3RTtxN for <quic-issues@ietfa.amsl.com>; Tue, 5 Jun 2018 00:19:51 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC20130F0E for <quic-issues@ietf.org>; Tue, 5 Jun 2018 00:19:51 -0700 (PDT)
Date: Tue, 05 Jun 2018 00:19:49 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1528183189; bh=1KqlTiADc7a3os0UC+fhU8d47yRhHe+xSUsoWJSYvAw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ls+kX3K1L6vKWq29eN7U34yz5Butlv7Gfzm0x5vWYnjLwVRm5o8a6+eb2GhScRGji YnWHp0c2GXbqzqM8gkOTyCladuFDxqvVD/A7Hai0pSxKWANFsmx5m73H/r5Fgg4Yru v2LItKQHfl7S0UwP+kDXWeClYvDSKgpvTYSr2SMs=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab3db73bbe5100a8295c12a0fe2efef040dc99a78992cf00000001172dfb9592a169ce124738ff@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1243/394607390@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1243@github.com>
References: <quicwg/base-drafts/issues/1243@github.com>
Subject: Re: [quicwg/base-drafts] ICMP and ICMPv6 PMTUD with asymmetric connection-ids (#1243)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b1639958f5e3_21e42acab7510f5c10279a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/8cKUFzgOouIiWHVK5W4pqYSjIpE>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2018 07:19:53 -0000

> Any party that keeps dumping invalid packets might be flagged, also otherwise competent QUIC peers. Seeing something suspect in a packet is reasonable cause for rejecting the entire transmission.

I disagree. As stated in my comment above, terminating the connection due to seeing suspicious QUIC packets is equal to allowing attackers reset the connection. That goes against our principal of having "authenticated reset."

I believe that the same holds for coalesced packets. An attacker can break the packet by modifying it. But that should not lead to the connection being terminated.

FWIW, section 4.6 of the transport draft says: "The receiver of coalesced QUIC packets MUST individually process each QUIC packet and separately acknowledge them, as if they were received as the payload of different UDP datagrams."


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-394607390

v2.23.0 | Report a Bug | By Email