IETF Logo Mail Archive

RE: Proposal to replace ACK block count with ACK length

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 19 June 2018 18:25 UTC

Return-Path: <mikkelfj@gmail.com>
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 A103C130E10 for <quic@ietfa.amsl.com>; Tue, 19 Jun 2018 11:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S1XPWfd4A1VZ for <quic@ietfa.amsl.com>; Tue, 19 Jun 2018 11:25:49 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866B6130DF6 for <quic@ietf.org>; Tue, 19 Jun 2018 11:25:49 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id l25-v6so1083954ioh.12 for <quic@ietf.org>; Tue, 19 Jun 2018 11:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=amyh2LkS78pU6WFLOKl5fZd4v9JNjqWRBoq+g4zcQyM=; b=uPR6Rjy9+an6jM2VQTEEk3RVbH4tMTpEw1VL5lf84CaYOOvPeqOnkUQ9YbPTTpf5S/ eFFQBcI3jqQHs7RwP82f63sQ0qtcVfqZ+JCyYOKf7Le/kkoCcal9HG+6V/Y9xjeVGXoG eeQaHSSXfNpBwbO2JH4HUlBpYD+F5Sp4a8C40Ww3T1RGghjFAiXTxMQrCzjme5yVwY9D bupklt7f+rW0tWxlPLN/DyPtJXGG6yJgveb714TSacy2dyvzY1kOs5lnjqcA+VI6wIT9 OLikFQ4nrBLKDCV1Nc6qLZrf9E/oNoRLSXDbiEavpE8kuTk5cRG7NpXpu4qG3w2MeG3z YhOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=amyh2LkS78pU6WFLOKl5fZd4v9JNjqWRBoq+g4zcQyM=; b=rcDnoFOgoGID8cHw4DIVWyObOK25gJfq9eNFp+cpHULsNYl59GnR5AGSfdw+xD6fKH b5T3kh8XWziB1lz0fVqVRpWmlRQZqfhVDNKTkmz7cNnPBudrHJpwYwX0ZBN8UkMbCRqg 2mvqOH7qUb5Vk6S1FnJkhThG44lx6YyMwUh2fxOELcXlEGaF9UawmELbc1Vw17UYWDrQ Y8PoeIeuPn6pwACU+Q1YgNe8CWGPAT6H3o3VUjCEV7/iMbbB84UEVKOGQEOoSMPEPGGe hKOBtEBpWuiHif/IeT2BUcet8dL6PZhutg7xZiSUAl6/hT2ps8AbJivjBTf++xSedtp2 AEuQ==
X-Gm-Message-State: APt69E2QSVNnFK2R4c37WYp/ahx9YBkrVQ8Di9ITF1Gd1SkUyuK7VjiG DA22HZNg8O64B9j3nFQuv6gV8oD6g6gGyO1AXK0=
X-Google-Smtp-Source: ADUXVKK2A6ymSH86D7zMgBW8UlQ2GReC7+Zf3gyTzSn4eBHD3aq+xlqbxN6Lhu/3i1NkcY61tE8w2vCj6WjnWshukds=
X-Received: by 2002:a6b:1e91:: with SMTP id e139-v6mr15147699ioe.36.1529432748947; Tue, 19 Jun 2018 11:25:48 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Jun 2018 11:25:48 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <CACpbDcdxzRxeiN93kKoj__vo2TERm4QZKqaesL=jr4wQUN1gXA@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <CABcZeBOjjRrX+AsXdgcUKpL=ciL8U_U1+WVAhQv-ZjwGxkQxYw@mail.gmail.com> <MWHPR21MB0638068EFA850328793E55F6B67C0@MWHPR21MB0638.namprd21.prod.outlook.com> <CACpbDcdbTKKEh8dcshWM6-7vq2hBFJC1myL1+H6etpMMjth+wg@mail.gmail.com> <CABkgnnV_thWcAi=AdwV+Za5rXywiUvtOYpsNNp1y7=RvL2MvWA@mail.gmail.com> <CAOYVs2qE=Tw_7eax9HwaESaQPMh7k3BSVV112d+pPeSfZ09EjQ@mail.gmail.com> <CABcZeBOCRHAuh44CrMH02UZ3Ar_2sa5M1c3LG_A-RPzXX+H+Yw@mail.gmail.com> <CAKcm_gOeZHR-BGJiqK=zQKqbgq=briQuH+fzHrkUYbhQx3B_sw@mail.gmail.com> <CANatvzyKv8EGVR-Z5WMDKbeuKHP791OynsTqX=+HriKBxFnafA@mail.gmail.com> <CAOYVs2oE6yawW04MVH1ApewSJ+0g9g2oMxCj+CU+butfiAe8kA@mail.gmail.com> <CANatvzxniU0AUEi5tuKzmX45uTUV6-y0JbqcdKTpu1J4WQR7JA@mail.gmail.com> <CAOYVs2p9vJrCVuXqGsR29rOGj=CNt1m7TcavGV9Kwk-9hA4sPQ@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 19 Jun 2018 11:25:47 -0700
Message-ID: <CAN1APdfYmj4M0mVedCUhRG9qYXpDSoN8TgYY_X72HkV6+ixEbg@mail.gmail.com>
Subject: RE: Proposal to replace ACK block count with ACK length
To: Kazuho Oku <kazuhooku@gmail.com>, "Deval, Manasi" <manasi.deval@intel.com>, Marten Seemann <martenseemann@gmail.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>, Eric Rescorla <ekr@rtfm.com>, Jana Iyengar <jri.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b57d9b056f02cf58"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2YSoIPFuMO_5tJKAs-rOBrmZsSw>
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: Tue, 19 Jun 2018 18:25:52 -0000

I don’t think you addressed e) at all. Clearly there is an end of buffer
check, but that is not the same as requiring additonal checks at many other
levels.


On 19 June 2018 at 20.22.03, Deval, Manasi (manasi.deval@intel.com) wrote:



e.      Every encodable value should be valid

Not every length will be valid. This is inherent to lengths. This same
issue ails the ‘payload length’ in QUIC header. Not only does the issue
exist for small values, it also applies to large values since data stream
will be sent after crypto negotiation.  E.g.  - how does one craft a
payload with 62 bit payload length in a large header?

v2.23.0 | Report a Bug | By Email