Re: Erik Kline's Yes on draft-ietf-quic-transport-33: (with COMMENT)

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 06 January 2021 03:42 UTC

Return-Path: <lucaspardue.24.7@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 03F243A0ADF; Tue, 5 Jan 2021 19:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 voDamVXp0SdH; Tue, 5 Jan 2021 19:42:11 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 C905F3A0ABB; Tue, 5 Jan 2021 19:42:10 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id g24so3076748edw.9; Tue, 05 Jan 2021 19:42:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mm967sQOdVCcSJHjqwyxrrpLZgm8XHyEME3Ly56Kz8Y=; b=Ii37eIS8tui34GzkncFkygyfaLWjrxd6N/7TBwNJlYzKRZFM9mGQyMmo0VM7iC1rW7 styC9lWxtkCxDwjTnQZPKjb1nfSJyGjmSjDNAW1c4u9O8XMvJ8yGh7qoahQJBeUCIAAb sJglcbdiyewXhcwZwSfU+9ozJG73IahtledvIE5vxafBLLVxXE5IofrZ8miKLbXgrKVA 5DGKEBX8HctCw5nQYSwmykThaQKyZY0x1MKUGNP1+avMsp/IKQbFFi9PzS8vV7MvpjD9 pWkY+/IFVHNVaUE0oRqZEFub3xSzW5WFH6Fan+/ZsL4GQz1HtA+k7uJ9KdRrEcBPMlQV vudQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mm967sQOdVCcSJHjqwyxrrpLZgm8XHyEME3Ly56Kz8Y=; b=FudACZkfGS3Wzwa/VMtJDGpbilzBNRl+rj7CelcbbEH8NTyAfppNyjBmv2TaV8CmJ+ G8a3JOxCByVuu8sOUlWOFXnLjlgkXZfirKqeJMyzofDZqhUoLuWBB+wq7g3NK0xhmJMi oB7M3yEPXruNiftPx3Xoe/cfePJ2smjYOn1zz6h7IsaHGHpZ+3njRcyUNK/SjoXxqEpl fn2jXbi0KyfxTZlog02b04g1kIhLwUJIYciBBjucJm+C91Gax2roD5PSBjfPMsdh3xM1 0IU1Ddi7E4mk20UO9BlweTVi+KDY6nKY66bb6BA0P4TchNBkjSBXRg1GwYrMT+9wFHFx OqYw==
X-Gm-Message-State: AOAM530U4NESJZYMay/4yVPVIxNEczQhWZrc1kWqs4hP8momywz6E/RK aTeuO4+KElj5/jXyhMOW92U2gtbWjHolHK9Hc0vkkEFx/hM=
X-Google-Smtp-Source: ABdhPJxlTSgEpjP9ayxL4ssRRxUx5VA26R0yor/5rsrS4eWiqoV8B5GKFmbR1aCnPs9lbmfgbtkLedgX6FR5ZJst7Yo=
X-Received: by 2002:aa7:db01:: with SMTP id t1mr2561679eds.185.1609904529378; Tue, 05 Jan 2021 19:42:09 -0800 (PST)
MIME-Version: 1.0
References: <160982748867.21655.18161467183403618406@ietfa.amsl.com>
In-Reply-To: <160982748867.21655.18161467183403618406@ietfa.amsl.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 06 Jan 2021 03:41:58 +0000
Message-ID: <CALGR9obtFu8-mvM=eba27=9a_vsvhZw-Yii82B3WHEY+TN-keQ@mail.gmail.com>
Subject: Re: Erik Kline's Yes on draft-ietf-quic-transport-33: (with COMMENT)
To: Erik Kline <ek.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-quic-transport@ietf.org, WG Chairs <quic-chairs@ietf.org>, QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>
Content-Type: multipart/alternative; boundary="00000000000098915305b8331bff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8S_xNkB2Twt-AJeZ4SfHpqu7Ebw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 06 Jan 2021 03:42:13 -0000

Hi Erik,

Thanks for the review. I've captured your comments as issues on the QUIC WG
GItHub repository. Links to each are provided as in-line responses.

On Tue, Jan 5, 2021 at 6:18 AM Erik Kline via Datatracker <noreply@ietf.org>
wrote:

> Erik Kline has entered the following ballot position for
> draft-ietf-quic-transport-33: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> [[ comments ]]
>
> [ section 8.2.3 ]
>
> * I found this wording a tad odd:
>
>     If the PATH_CHALLENGE frame that resulted in successful path
>     validation was sent in a datagram that was not expanded to at least
>     1200 bytes, the endpoint can regard the address as valid.
>
>   It seems like whether the frame was padded to 1200 or not, if the
> response
>   data matches the challenge data the address can be considered validated.
>
>   I think the point at the end of the sentence is to say that *only* the
>   address, but not the MTU, can be taken as validated.
>

https://github.com/quicwg/base-drafts/issues/4513


> [ section 9.6.3 ]
>
> * Entirely optional, but I wonder if it's worth noting that in certain
>   situations, for example an IPv6-only client and IPv4-only server, the
>   client might be required to evaluate use of an alternate address family
>   address if, for example, some transition mechanism (a la NAT64) was in
>   use.
>

https://github.com/quicwg/base-drafts/issues/4514


> [ section 9.7 ]
>
> * "as this would enable..." reads to me like the opposite of what's
> intended.
>   Perhaps: "as failure to do so would enable..."?
>

https://github.com/quicwg/base-drafts/issues/4515


> [ section 14.1 ]
>
> * I think it might be important to note that this strategy places some
>   restrictions on the use of things like IPv6 extension headers that can be
>   used in these packets.
>
>   For example, on an IPv6-only link with a 1280 MTU, enforcing a 1200 byte
>   UDP payload in these packets leaves only 32 bytes of space for any
>   extension headers.
>
>   I think this is likely fine for these initial packets (vis. section 8.1
> and
>   so on ), but as a general requirement for all packets this could
>   artificially constrain use of new extension headers.
>
>
https://github.com/quicwg/base-drafts/issues/4516

[ section 19.3.1 ]
>
> * This seems intricate enough that it might be nice if there were an
>   Appendix (A.5?) section walking through an example computation or two.
>
>
https://github.com/quicwg/base-drafts/issues/4517

[ section 19.18 ]
>
> * I'm idly wondering if there would be any debugging value in the response
>   including the IP & port to which the response is being sent (i.e. from
>   which the path challenge was received) ... assuming the packet with the
>   PATH_RESPONSE frame is protected.
>
>   Not important though, and perhaps it was already discussed and rejected.
>   (or maybe it's better as some future, entirely separate PATH_INFO frame)
>
>
https://github.com/quicwg/base-drafts/issues/4518


> [[ questions ]]
>
> [ section 8.2.4 ]
>
> * To be clear, this document is effectively saying that it takes no
> position
>   on the interpretation of any ICMP errors received?  Is it up to the
>   implementer to decide if "validated" (in as much as ICMP messages can be
>   validated) Admin Prohibited messages, for example, should constitute a
>   positive confirmation of path failure?  Or is there some very specific
>   stance that should be taken ("never trust that lyin' ICMP!")?
>
>
https://github.com/quicwg/base-drafts/issues/4519

[ section 10.3 ]
>
> * Does this "datagram ends with stateless reset token" scheme mean that
>   implementations must check the output of every packet, including post
>   encryption, and take some action if a (very low probability) collision
>   occurs (meaning the output accidentally produces this 16 byte value
>   but the packet is not intended to be a stateless reset)?
>
>
https://github.com/quicwg/base-drafts/issues/4520


> [[ nits ]]
>
> [ section 7 ]
>
> * There seem to be two paragraphs with the same text about how an endpoint
>   validates ECN support.  Seems like maybe only the first paragraph is
> really
>   necessary (or, put another way: I can't see what new information the
> second
>   paragraph adds).
>
>   (the paragraph below Figure 4 seems to be repeated information)
>

https://github.com/quicwg/base-drafts/issues/4521


> [ section 8.1.1 ]
>
> * "a NEW_TOKEN frames" -> "a NEW_TOKEN frame" or "NEW_TOKEN frames"
>

https://github.com/quicwg/base-drafts/issues/4522


> [ section 17.2.3 ]
>
> * ", as defined Section" -> ", as defined in Section"
>
>
https://github.com/quicwg/base-drafts/issues/4523

Cheers,
Lucas
On behalf of QUIC WG Chairs