IETF Logo Mail Archive

Re: ALPN negotiation (was Re: Add extension work to Interop matrix)

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 07 January 2020 19:52 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 DBFAA12085A for <quic@ietfa.amsl.com>; Tue, 7 Jan 2020 11:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] autolearn=no 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 HddG_4aL9c0R for <quic@ietfa.amsl.com>; Tue, 7 Jan 2020 11:52:06 -0800 (PST)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 62793120251 for <quic@ietf.org>; Tue, 7 Jan 2020 11:52:06 -0800 (PST)
Received: by mail-ua1-x936.google.com with SMTP id o42so178255uad.10 for <quic@ietf.org>; Tue, 07 Jan 2020 11:52:06 -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; bh=f2Cx0tRbJEc72k3DTBWhxrb+D1DfdFOt+RlXjbQm3Vk=; b=hCpAj9rz6tSPv2K9Hc2vyKjN3pro+tbmEkRLVcpM2mfCOtd62d3QH6TgbHVwqo5xhv 8/PE0Z0veklISb8UI8cbwdF+EycNDcHxU22fNviGWZvgC2Y7dvoLFG5aIvAFlCIbBK8k /s8VG4pRL+4yVdHYrv/UHhQVaynoyq6dI9GiAG+Ik6/0oTyDF7yFIpDWFM8d8plrijzT MrOcgAfsQTEnLU1xFXL1Qkz6ThXPP+5n5cLspk8DFjJc0WLfTIIBIWLCCv4j3rfcOMD1 tyQob+gcWTFiTSAFwFAivAP1+hhNj3u+5tvFNC/ezeE+nbLo2d4mG98MBS830lQTcg4S E2Vw==
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; bh=f2Cx0tRbJEc72k3DTBWhxrb+D1DfdFOt+RlXjbQm3Vk=; b=MhzqkxkDs0iNlHSEkAfCVMmhKakaS6lAOY9fbmhqkJBUDYAIwIocjJWPaliciLUrWT FQVPdt4id07oyWxfPnXpY7gOVdbXJtzOr+tA/2Nqq2zy254U8sBXZFbANQT0d/FSZamz c3sazU5p+M7jIL/DqV9cRrDVm0uHmHmgHodQ7WLt7zaro1JkX2Q6Z4Pq0wNAywt9U3f9 V0U5m8FNkDpzX16Shjup5KcvU7vhqtbcAs9sLF6IfmDFfT45xuTKx1FIKBi9WxL54Dl8 hZqwLSeMfr5u3OxEQmHFW0ae8qmH7asymZzpNmWNrDbEVxx5ZBvHygJcuDumfZFK4Lt5 5lkg==
X-Gm-Message-State: APjAAAVLAWBgPtcc2aHbNkg3aEh3A1GhYfHBGQjK3kJYURHPvFCIrsPa vOegw4uxUyjHJx/eY2+lndxu9TT0gJ7jY2mHrRTTiw==
X-Google-Smtp-Source: APXvYqzcaWIl3AKq6KzuzYfTKqmSCfOmyFSaytP+IkNgA6cbl0iIzZ+S0s7JdNLfrK412lCHUnulOBE4DywKe+rgArk=
X-Received: by 2002:ab0:280c:: with SMTP id w12mr765586uap.79.1578426725384; Tue, 07 Jan 2020 11:52:05 -0800 (PST)
MIME-Version: 1.0
References: <20200107143114.GC14229@ubuntu-dmitri> <d27fc30c-7f51-85f3-4bb1-e7b7b500ac72@huitema.net> <20200107194543.GK14229@ubuntu-dmitri>
In-Reply-To: <20200107194543.GK14229@ubuntu-dmitri>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 07 Jan 2020 19:51:54 +0000
Message-ID: <CALGR9oboJhewv4tdF9G_WZsxZ4gO2ZQ-H6teFSgr3+-WSrds4A@mail.gmail.com>
Subject: Re: ALPN negotiation (was Re: Add extension work to Interop matrix)
To: Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004548f7059b921c3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/57CuyDiCp-bmUnE4ZlkIxx8KHNg>
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: Tue, 07 Jan 2020 19:52:11 -0000

Probably a good idea.

IIUC I think you could solve the multi- version problem by creating two (or
more) aliases for each version of the same protocol. This means testing of
ALPN ordering but implementations don't need to support protocol level
changes.

The upshot is that this could also be used for Alt-Svc testing.

Lucas

On Tue, 7 Jan 2020, 19:45 Dmitri Tikhonov, <dtikhonov@litespeedtech.com>
wrote:

> On Tue, Jan 07, 2020 at 09:06:49AM -1000, Christian Huitema wrote:
> > It seems that ALPN negotiation is going to be a practical requirement
> > going forward. Not so much for negotiating H09 versus H3, we can expect
> > H09 to fade away at some point. But we will have to negotiate h3-24 vs
> > h3-25 and similar transitions for a good bit of time, and then we will
> > probably move to h4-00, h4-01, etc. So maybe we should start testing
> that.
>
> I would be for it.  Is the testing as simple as
>
>     1. Client sends (h3-X, h3-Y), server responds with h3-X; and
>     2. Client sends (h3-Y, h3-X), server responds with h3-Y?
>
> Of course, this assumes that the server support both h3-X and h3-Y.
> For example, supporting drafts 23 and 24 at the same time was easy;
> 24 and 25 might not be as easy.
>
>   - Dmitri.
>
>

v2.23.0 | Report a Bug | By Email