IETF Logo Mail Archive

Re: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)

Christian Huitema <notifications@github.com> Tue, 29 October 2019 19:25 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 42E09120168 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 12:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Level:
X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 e5AzW7ENOcGF for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 12:25:40 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76311200A3 for <quic-issues@ietf.org>; Tue, 29 Oct 2019 12:25:40 -0700 (PDT)
Received: from github-lowworker-e8b54ca.ac4-iad.github.net (github-lowworker-e8b54ca.ac4-iad.github.net [10.52.23.39]) by smtp.github.com (Postfix) with ESMTP id C86796E14C3 for <quic-issues@ietf.org>; Tue, 29 Oct 2019 12:25:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572377139; bh=3dsQzvyqk2WzKLBleZraio8X+xXS2duYDXaFnbB6qQ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZzZt3lcqldGR7/uvp5mdW0N5R/oBJK9BAFSjm83XBKnEvq7RG/9aYiVchTjXALH4r ifIjmLPgor+2OWfvDSRK+My+vDlkW1MPKP2WIBkP2MBQvkHl68o8L62+IRMMsgMjYN 0QCdZPYmPqj9nDRQ2gsfogIfb2gBfUEV0W6jJrOQ=
Date: Tue, 29 Oct 2019 12:25:39 -0700
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2QITWY2IKAVWYFXNN3YXJMHEVBNHHB5GVBRY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3161/547589874@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3161@github.com>
References: <quicwg/base-drafts/issues/3161@github.com>
Subject: Re: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db89233b909d_78223fd0832cd95c1060b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/IIam4k8AZQSErOb1CNMvUgDNvIA>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Oct 2019 19:25:43 -0000

Isn't this concern why we designed the Retry mechanism in the first place? If we are concerned about address spoofing attacks, the simple solution might be to generalize retry. As in, "if the server can predict that its first flight will contain more than 3 times the amount of data received with the client's Initial packets, then it SHOULD verify the source address using Retry."

-- 
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/3161#issuecomment-547589874

v2.23.0 | Report a Bug | By Email