Return-Path: 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 D224E130F56 for ; Fri, 29 Jun 2018 15:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.01 X-Spam-Level: X-Spam-Status: No, score=-8.01 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] 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 O0GDY587ei4v for ; Fri, 29 Jun 2018 15:12:44 -0700 (PDT) Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37EE130E31 for ; Fri, 29 Jun 2018 15:12:44 -0700 (PDT) Date: Fri, 29 Jun 2018 15:12:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1530310362; bh=yI0CHrJ22jYk4+loI2qnYF+vZBamMSugzOQBpcIw6+I=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=07zfC0bHOmeXLMPRDIlPj9zt8em+ZdbUgiSNJlDuPDFuD7kkREqZDWoLCAiXcPT1z ZbfK/RbuWeYtr3WjCBiCeeHkRfDSy50xsQ1V/uWPxK2IQQM5C5hhlfOR+PBU5fe8+m 9LZxrYD+iuJWixl2VgluzmAI6H/dyEroeofKU/kw= From: Igor Lubashev Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: Subject: [quicwg/base-drafts] Stateless Reset from clients, bis (#1505) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5b36aedae4573_401d3fbbb4c5af8010382e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: igorlord X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.26 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 22:13:05 -0000 ----==_mimepart_5b36aedae4573_401d3fbbb4c5af8010382e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit In #466, we left it as the client cannot use Stateless Reset, until the server starts to use to a CID provided by the client's NEW_CONNECTION_ID. (Something that is actually not stated explicitly in the draft.) This is certainly not great, hence this issue. To fix this, I can think of a few alternatives: 1. A new frame that provides the initial Stateless Reset Token from the client. It only applies to the initial CID (important to note, since you do not want it to override the token from a subsequent NEW_CONNECTION_ID in case of reordering). 2. If NEW_CONNECTION_ID frame is received from the client with Seq=0 and Length=0, it provides the initial Stateless Reset Token (and is considered to be Seq=-1, so the next NEW_CONNECTION_ID would actually be Seq=0). I do not love this and would prefer just a new frame. -- 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/1505 ----==_mimepart_5b36aedae4573_401d3fbbb4c5af8010382e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

In #466, we left it as the client cannot use Stateless Reset, until the server starts to use to a CID provided by the client's NEW_CONNECTION_ID. (Something that is actually not stated explicitly in the draft.)

This is certainly not great, hence this issue.

To fix this, I can think of a few alternatives:

  1. A new frame that provides the initial Stateless Reset Token from the client. It only applies to the initial CID (important to note, since you do not want it to override the token from a subsequent NEW_CONNECTION_ID in case of reordering).
  2. If NEW_CONNECTION_ID frame is received from the client with Seq=0 and Length=0, it provides the initial Stateless Reset Token (and is considered to be Seq=-1, so the next NEW_CONNECTION_ID would actually be Seq=0). I do not love this and would prefer just a new frame.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5b36aedae4573_401d3fbbb4c5af8010382e--