Re: Common implementation bug in migration
Dmitri Tikhonov <dtikhonov@litespeedtech.com> Thu, 05 November 2020 13:22 UTC
Return-Path: <dtikhonov@litespeedtech.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 46B963A1120 for <quic@ietfa.amsl.com>; Thu, 5 Nov 2020 05:22:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 IyGGw8_lXaoO for <quic@ietfa.amsl.com>; Thu, 5 Nov 2020 05:22:26 -0800 (PST)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 E789D3A110F for <quic@ietf.org>; Thu, 5 Nov 2020 05:22:25 -0800 (PST)
Received: by mail-qv1-xf2b.google.com with SMTP id 13so636604qvr.5 for <quic@ietf.org>; Thu, 05 Nov 2020 05:22:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=jH+6xRFUARrQ7Nj3seKCRSpdrG7o2RuOlKp2yvZcIRE=; b=VJSEnLTvl0RhQLB+gw18uJcyBqfqEQ35JvObicF1fStBhlTB/AtZZGoHDPBAfRlTTH RQ5sYVx8W4ROEMzbE63ICNFbot9tw6raPCtf2pBCExztHLsIvUXCq4IPM1aL3YWxsCwW cbL3nUQOUHcH++xygwr+rDua6qdPPigAPzcXkjqR386SRWOl7XIlV4nKeWpCecTsyuLc nuauj9+2euQo9q3ZNGfsuFAFIvjoVXrOgq6QQy7hM1MEU5sJq9Zlw5cTE1yCYw3pdJp7 rXRpi9s2f3M0lkgNmaTpEEQTAre/9M55xt8k/Qw+qs8gG34NTlk28CNatE/1BFd/m5nd yDTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=jH+6xRFUARrQ7Nj3seKCRSpdrG7o2RuOlKp2yvZcIRE=; b=P7i3dZXJEw7LM6RtB0DgcdhwmeOyTSvxKfOGBCS2mKbRciYilSzNbreTwKPkXq86IL h5GwxmRA4+Ul0pCkTvzvfmB60QxnBqhMarDCs5ZtOD31b3fE6h0iYSaiTKV4/QyFjZaP e3Q9Y9X9QhQdqCtGW18LUa57sDpOePOCPQnTDf+qSJs5h+pWSysSXGUlpsL6C0UvpEeb SLq4Q2Cwyw3SciGiVa1Pl6s0zDmR1vD5Oeg2fIn54+WAzAvK3DMlITwuLxPPd9OSA9Cv nOvru6qcvqHyrz7LprXxQxfdCqk5SloGouIX6gNjDcLrw3DXx1j4Va9ckYnEImlydxuQ lPPw==
X-Gm-Message-State: AOAM533VEpIBvaG3IZ450SQ28+HWcVzgEuxFueMuOLVfHkZorsuliqo7 a59YE4qqYVyojql7WdJrpOsW+6aIGoah8w==
X-Google-Smtp-Source: ABdhPJx+EWT7mlj6HMwC7kSoUAAkE/850iEovNCXWzy6wXK6cMgjr1tC7Aa2j+L4JVcYA3HnRQn07w==
X-Received: by 2002:a0c:9bac:: with SMTP id o44mr1960176qve.43.1604582544552; Thu, 05 Nov 2020 05:22:24 -0800 (PST)
Received: from okhta (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id f1sm847559qto.18.2020.11.05.05.22.22 for <quic@ietf.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2020 05:22:23 -0800 (PST)
Date: Thu, 05 Nov 2020 08:22:21 -0500
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: quic@ietf.org
Subject: Re: Common implementation bug in migration
Message-ID: <20201105132221.GB73963@okhta>
Mail-Followup-To: quic@ietf.org
References: <6374da64-195c-4308-987c-4d1fce993f6f@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6374da64-195c-4308-987c-4d1fce993f6f@www.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/H3sDWMq8WK3uzOH5tEbDBlirUaY>
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: Thu, 05 Nov 2020 13:22:27 -0000
Thank you for this report, Martin. On Thu, Nov 05, 2020 at 08:13:32PM +1100, Martin Thomson wrote: > One thing that is hard to determine from my testing is that no > implementations (other than my own) seems to send probes on the > old path after the client migrates to the preferred address. > This is probably OK, because my address isn't changing, or at > least the port is the only change. However, it's not clear > that we have reliable implementations of that anti-DoS measure. Here you must refer to Section 9.3.3: Off-Path Packet Forwarding. I have to admit I had to go back to the draft and re-read the Migration section to find the requirement you alluded to. Even though that section has been in the transport draft for two years, we missed it and lsquic does not validate the old path. One more item for the TODO list! - Dmitri.
- Common implementation bug in migration Martin Thomson
- Re: Common implementation bug in migration Dmitri Tikhonov