Re: Back to work
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 28 October 2020 06:18 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 B415C3A0FC0 for <quic@ietfa.amsl.com>; Tue, 27 Oct 2020 23:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 WP1T3rOBTjY8 for <quic@ietfa.amsl.com>; Tue, 27 Oct 2020 23:18:28 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 837AC3A0FBD for <quic@ietf.org>; Tue, 27 Oct 2020 23:18:28 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id a4so3320124ybq.13 for <quic@ietf.org>; Tue, 27 Oct 2020 23:18:28 -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=CMUKluyvJgeLEE0eDbW/bwboiibbV7f0fQIx5pEgllI=; b=Wn+geR1peGKzLZvh/ec50p/gfja+buWZ3Pg79cKoJN9j+uuPYnIw7UEGV0T6Y903Cs cDPHQj3wXf59PyRfqwSkUM2ySi10kq3+UtebdeHNhtQjmzdnVsTi267a04mAnKHrUL67 LcrJdCWfMAtAiz6jP70PYvveaeWaTzRHDBIF8KE/Ti6xm6lElcxsvSfkp43flfUZ6+LJ zQ2GEAecoq25QY2N4q3RSucVe3SG04L98MsK+aKbD/hZ9NSNTbrQmwJ3t1p2KocuEGDF 4SMhQp2QySkhKDqqa3naZBlzSIOthtrBh5r7byWvnjSiDtdDcB8+2Zkks3C2IB+YjzFW o2mg==
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=CMUKluyvJgeLEE0eDbW/bwboiibbV7f0fQIx5pEgllI=; b=W3PAVD2q3zsnJPmcdgUZd9MuCTvqKOAcp5/aAwjTBSjFvoIDhW2y5YMLVb6SBvGPn9 yEuASmY/OZLfrvqTayMHUzhLRxT1276wcQXw1hynFUrIxQfsxbP9t812kr4fK0fEcTt9 vJjeKxXYSUEcO2PFUETfJDFl4NHXpl6ok58TCFhxPSYwIo9yw/h+o/JJGhU34F2F8FL6 vu+O5WYPSY4qrSQcRrCPfRrfKOZxegvjLJMDxaEjOFbjIIsIqHHH53Z49B1lUKE0A/xv CWVJjQPfaxEHjTQLxZWiVpo0SKN/gF17VqxKTxjVLlwm3UN3wT9lSBGCVa7RgR7sCwUY YNQg==
X-Gm-Message-State: AOAM530tRrthjBk4Myeo8dmiBCU6Wy9wqRWpAxSsWlddQdR4Ye3OCMBa Km/w3CI7Sjxq7+OC+nxTUqS+8ds8/r4LLNWq32A=
X-Google-Smtp-Source: ABdhPJyllDCx2lOg/zkXjXSy0xN5myxaOPxlpTu4wz/CVqWPE6TsqaAkzA+mamorO24pDNMWrvRZ5GbGi4cY9+M063Q=
X-Received: by 2002:a25:c74a:: with SMTP id w71mr8559625ybe.128.1603865907730; Tue, 27 Oct 2020 23:18:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 27 Oct 2020 23:18:27 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <41A07550-1BFA-43E6-83A0-93FA96DF1E9B@apple.com>
References: <0f150dec-e408-48bf-8e54-05e3e96e7a85@www.fastmail.com> <CALZ3u+a1fBq1MB52H-h-JYY=OOkOo9=jEu7smNVeyy_9U3abEw@mail.gmail.com> <CAKcm_gNoB=nP050VRfw5MXAAw-HhpnKHp6pAx9onaA4a5CH5-Q@mail.gmail.com> <b80cf41524865c171712bfcfca7ef92e2a472044.camel@ericsson.com> <efe63bdf-7af2-49c0-932d-3a36de61bdd6@www.fastmail.com> <41A07550-1BFA-43E6-83A0-93FA96DF1E9B@apple.com>
MIME-Version: 1.0
Date: Tue, 27 Oct 2020 23:18:27 -0700
Message-ID: <CAN1APddS_qtMoUiUL9uwtAB3rXuAQ0NmiipXGDkS4hcA5od6Ag@mail.gmail.com>
Subject: Re: Back to work
To: Martin Thomson <mt@lowentropy.net>, Eric Kinnear <ekinnear=40apple.com@dmarc.ietf.org>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b29f1605b2b521e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/R8IhuXKTaTjUuWTaTjXbTy9jC8c>
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, 28 Oct 2020 06:18:31 -0000
Rather than a race to the top with padding, would it be possible to do the opposite: Force challenges and responses to occur in their packets and also UDP datagrams. This prevents other traffic until a path is confirmed. The initial handshake has several concerns with padding: - amplification attack mitigation - PMTU discovery - reply capacity for completing handshake Since new paths do not need a handshake, there is less need for large replies. Of course there is the PMTU issue still. Kind Regards, Mikkel Fahnøe Jørgensen On 28 October 2020 at 03.55.46, Eric Kinnear ( ekinnear=40apple.com@dmarc.ietf.org) wrote: This is an interesting PR, and likely accomplishes the goals at the moment. I do really like how we’ve kept some bidirectionally of the approach and the padding can stay as is. Just thinking things through a little bit: (This is all discussed below by Ian/Magnus/Martin/Kazuho, and others, just restating so we have it in one place) At any point, either endpoint can choose to send a PATH_CHALLENGE. The presence of a PATH_CHALLENGE always evokes a PATH_RESPONSE. Therefore, we assume that in order to restrict folks from being able to spoof a source address when sending a PATH_CHALLENGE and attack the real owner of that source address with the PATH_RESPONSE, we need to make the PATH_CHALLENGE very large as well. However, there’s another situation where PATH_CHALLENGE is sent, and that's whenever we receive a non-probing packet that arrives on a new path without any prior validation, and we send that PATH_CHALLENGE on both the old and the new path. This is where we haven’t fully plugged the amplification hole, since an attacker can use *any other, smaller datagram* to cause the other endpoint to generate full-size datagrams containing PATH_CHALLENGE. This wasn’t previously a huge issue since PATH_CHALLENGE wasn’t meaningfully larger than the smallest packet you’d otherwise be able to send (slash the per-packet costs were potentially higher than the cost of the data inside that packet). ——— One other approach we could take here would be to restrict ourselves to only covering the cases where you’re actively generating a PATH_CHALLENGE to validate a new path, not responding to a new non-probing packet on an unvalidated path. In other words: Only the client needs to pad PATH_CHALLENGE and any response to a padded PATH_CHALLENGE should also be padded. That also fits nicely into the unidirectionality of path validation as it stands today. The other option that we haven’t discussed much is if we’d rather live with the previous pre-padding problem and remove the padding. My initial inclination was to avoid this, but actually we’d be returning to a state where the main risk was that the path wasn’t MTU compatible and any implementation migrating is likely already dealing with cases where packets aren’t going through on a path in at least one direction. So, the natural responses to path validation failures (for MTU reasons or otherwise), if you map them all out, generally result in the “correct” behavior. We could then say “any endpoint using a new path is encouraged to do PMTUD or otherwise be careful that the path may not work in at least one direction” and leave it at that. ——— Overall, I suspect we’re probably headed in the right direction by making the 3x limit more universal, although it does seem like it introduces some really interesting cases to code around, and that limit and double path validation might be more painful than just checking for “am I client, therefore I should pad” which is annoying because it has a client/server distinction but does likely cause less churn and risk for later fallout. Thanks, Eric On Oct 27, 2020, at 7:41 PM, Martin Thomson <mt@lowentropy.net> wrote: Thanks to everyone for the feedback. I've written up a draft pull request here: https://github.com/quicwg/base-drafts/pull/4264 This does something like what Magnus suggests below. It's not pretty, because in some very common cases path validation could take twice as long, and it's more complicated, but I think that it is at least principled. On Wed, Oct 28, 2020, at 04:04, Magnus Westerlund wrote: On Tue, 2020-10-27 at 09:12 -0400, Ian Swett wrote: Thanks for summarizing this issue. I think the above discussion is about immediate migration and repeated immediate migrations, but I also wonder if we've introduced a single packet amplification attack by requiring PATH_RESPONSEs be padded on new paths without a requirement on the size of PATH_CHALLENGE(see first item)? Validating a new path If one receives only a PATH_CHALLENGE on a new path, then the server responds with a full-sized PATH_RESPONSE. This seems safe. If a non-padded PATH_CHALLENGE is received on a new path, then the peer is supposed to send a fully padded PATH_RESPONSE on the path, which could be >20x larger. I'm not sure if we care about this, but I wanted to point it out. Immediately migrating to a new path I think we should remove the text about allowing kMinimumWindow each kInitialRtt after migration and change it to the 3x limit. I'm actually surprised the text about 2*kInitialWindow still exists, since recovery says "Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.". In order to not get deadlocked by the 3x factor, I think we should change the newly added MUSTs to only apply to path validation prior to migration, not the peer responding to migration. My reasoning is that if a peer migrates prior to validating the path, it means it's either unintentional or they have no other choice, so the migrating peer has implicitly decided that validating PathMTU is not a prerequisite to migrating. So some quesitons and ideas as I think it is relevant to resolve this as best as possible. So isn't this recreating the issue that if the client initiates a migration to a new path that is not QUIC compatible, by responding with a minimal size packet and completing the migration and then if the server performs the path verification with 1200 bytes UDP payload it fails. Thus maintaining a broken path. So is there need for the non pre-validated path migration case that one need need to do a two step process where one will ACK with minimal packet while initiating path validation. If path validatation fails then maybe one need to close down the connection as the migration ended up on a path that was unable to support QUIC. The question here is how to avoid the DoS attack this may open up if an attack rewrites source address of packets. So Maybe the path validation needs to be a two step process. First a return routability over the new path to verify that it is bi-directional. When that has been verified one does a test with minimal MTU to prove it to be QUIC compatible. This might even be done with application data if there is some that are available to send. But, I think that one needs to work through the criterias for when the QUIC connection is shut down under the conditions that the path available is not supporting 1200 bytes. Also do we end up in a situation where the client needs to do the second step itself towards the server to verify the path so that it can determine if it needs to try another path if this one doesn't work? Cheers Magnus Attachments: * smime.p7s
- Re: Back to work Christian Huitema
- Re: Back to work Jana Iyengar
- Back to work Martin Thomson
- Re: Back to work Töma Gavrichenkov
- Re: Back to work Ian Swett
- RE: Back to work Nick Banks
- Re: Back to work Magnus Westerlund
- Re: Back to work Martin Duke
- Re: Back to work Kazuho Oku
- Re: Back to work Martin Duke
- Re: Back to work Kazuho Oku
- Re: Back to work Martin Thomson
- Re: Back to work Eric Kinnear
- Re: Back to work Eric Kinnear
- Re: Back to work Mikkel Fahnøe Jørgensen
- Re: Back to work Ian Swett
- Re: Back to work Martin Duke
- Re: Back to work Eric Kinnear
- Re: Back to work Ian Swett
- Re: Back to work Martin Thomson
- Re: Back to work Eric Kinnear
- Re: Back to work Martin Thomson
- Re: Back to work Christian Huitema
- Re: Back to work Martin Thomson
- Re: Back to work Eric Kinnear
- Re: Back to work Ian Swett
- Re: Back to work Martin Duke
- Re: Back to work Ian Swett
- Re: Back to work Martin Duke
- Re: Back to work Ian Swett
- Re: Back to work Magnus Westerlund
- Re: Back to work Gorry Fairhurst