From nobody Wed Oct 28 13:04:09 2020 Return-Path: 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 4F5BA3A0953 for ; Wed, 28 Oct 2020 13:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Odr29Woid3pw for ; Wed, 28 Oct 2020 13:04:05 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 990013A0934 for ; Wed, 28 Oct 2020 13:04:05 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id b138so217825yba.5 for ; Wed, 28 Oct 2020 13:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+SFp78UJVgzkR4tTCIVrSjaH6wqk/Pzx4q9mkXK5YSs=; b=dVOhXI28aSAnfShToDT3xEq9zKo6xSE/waQYfTxApAEKA86ixwybEMRdoRl9TCyqdz YKOynSVw8oI4BI0NyjUnymvisZsY7ybsrMmGtYTGH7hUjYg1+M7i6Pcc8EGJYczUc99C aCpUoljWAu4vKoLVuUn4RwFNsI6q8iIZno/s0lCpoup5wpLaPEZr6UEmKVGcDIAFVpty fnD6SK8ImPu55sIvsPe0N+7v7eydGOCngCQyhsukGjSplQrY7Hqeoojls+hjcQ3uOMmH N2TBmjc1tubKr4FUzvENKGMg8KHVOqr8EdSxcMqijJd+H/VEWxefyBvQ9KxfosAhG6Pv snhQ== 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=+SFp78UJVgzkR4tTCIVrSjaH6wqk/Pzx4q9mkXK5YSs=; b=ngS5XOW/Cc0sORSxKI1GxI+T1vEup0Ydv3xX+t7EWBKorgrKn+DpbH6LehIhTd4rJ+ TyPsp/YpJ4VUyy7lJwBItwTeJxLlMe8R1ZKF/LrKSC11vUROykD2It3SsLFV7PEmM+ZB KzpD0WhTcbOT8YkN6x/WO1LVbWGd9CPJq+k3OsTThV8lA2Ix+pQMFbg0nUIHhsf9ojDq mmWkMpf0/3w3OyFhwxGn5OQnyuza5y5XECb+tGY9myQ87fS/J8U4fOCcO6X/dAFFRSH7 ycv5LZnxMG/OwFeGdPfkqsI5WNmvWpM5Wf4qJDS8H60FZpQXyvT8kpxKpdhflJbfixOX Dwag== X-Gm-Message-State: AOAM530P7bJVHevJVWWNVkOKtLjlrPZHxpArtAnd3tpj43THBE8UQzWF gxOh9TdLP4sfahcx/k45vIk9FM9rY1VaejD8ZYz5gg== X-Google-Smtp-Source: ABdhPJzS6v4bUwpwPLG1+ReRL8YjIa7Eex3ViZo1bifbqXt+uP5A9WfhhoumXEwTBLuRWdFrT1i7fNpcaM1KpPw3UEY= X-Received: by 2002:a25:a221:: with SMTP id b30mr1269063ybi.130.1603915444436; Wed, 28 Oct 2020 13:04:04 -0700 (PDT) MIME-Version: 1.0 References: <0f150dec-e408-48bf-8e54-05e3e96e7a85@www.fastmail.com> <41A07550-1BFA-43E6-83A0-93FA96DF1E9B@apple.com> In-Reply-To: From: Ian Swett Date: Wed, 28 Oct 2020 16:03:52 -0400 Message-ID: Subject: Re: Back to work To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , Eric Kinnear , Magnus Westerlund , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000514b4605b2c0aa11" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 20:04:08 -0000 --000000000000514b4605b2c0aa11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'll note that this problem is created/worsened by the fact that the congestion controller is reset. If it was not reset, you'd be limited by the existing congestion controller. That would allow you to build up a big window and direct it at another path, but creating a larger window is more work on top of completing the handshake. NAT rebinds don't require resetting the congestion controller if my memory is correct, so I don't believe they don't need to be covered by this new amplification factor. Ian On Wed, Oct 28, 2020 at 2:18 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Rather than a race to the top with padding, would it be possible to do th= e > 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=C3=B8e J=C3=B8rgensen > > > On 28 October 2020 at 03.55.46, Eric Kinnear ( > ekinnear=3D40apple.com@dmarc.ietf.org) wrote: > > This is an interesting PR, and likely accomplishes the goals at the momen= t. > I do really like how we=E2=80=99ve kept some bidirectionally of the appro= ach 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, jus= t > 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=E2=80=99s another situation where PATH_CHALLENGE is sent, = and > that's whenever we receive a non-probing packet that arrives on a new pat= h > without any prior validation, and we send that PATH_CHALLENGE on both the > old and the new path. > > This is where we haven=E2=80=99t fully plugged the amplification hole, si= nce an > attacker can use *any other, smaller datagram* to cause the other > endpoint to generate full-size datagrams containing PATH_CHALLENGE. This > wasn=E2=80=99t previously a huge issue since PATH_CHALLENGE wasn=E2=80=99= t meaningfully > larger than the smallest packet you=E2=80=99d otherwise be able to send (= slash the > per-packet costs were potentially higher than the cost of the data inside > that packet). > > =E2=80=94=E2=80=94=E2=80=94 > > One other approach we could take here would be to restrict ourselves to > only covering the cases where you=E2=80=99re actively generating a PATH_C= HALLENGE > 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=E2=80=99t discussed much is if we=E2=80=99= d rather live > with the previous pre-padding problem and remove the padding. > My initial inclination was to avoid this, but actually we=E2=80=99d be re= turning > to a state where the main risk was that the path wasn=E2=80=99t MTU compa= tible and > any implementation migrating is likely already dealing with cases where > packets aren=E2=80=99t 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 =E2=80=9Ccor= rect=E2=80=9D > behavior. We could then say =E2=80=9Cany endpoint using a new path is enc= ouraged to > do PMTUD or otherwise be careful that the path may not work in at least o= ne > direction=E2=80=9D and leave it at that. > > =E2=80=94=E2=80=94=E2=80=94 > > Overall, I suspect we=E2=80=99re probably headed in the right direction b= y making > the 3x limit more universal, although it does seem like it introduces som= e > really interesting cases to code around, and that limit and double path > validation might be more painful than just checking for =E2=80=9Cam I cli= ent, > therefore I should pad=E2=80=9D 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 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 lon= g, > 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 o= f > 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 sa= ys > "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, no= t > 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 whil= e > initiating path validation. If path validatation fails then maybe one nee= d > 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 retu= rn > 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 som= e > that > are available to send. > > But, I think that one needs to work through the criterias for when the QU= IC > connection is shut down under the conditions that the path available is n= ot > 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 tha= t > it > can determine if it needs to try another path if this one doesn't work? > > Cheers > > Magnus > > > Attachments: > * smime.p7s > > > > --000000000000514b4605b2c0aa11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll note that this problem is created/worsened by the= fact that the congestion=C2=A0controller is reset.=C2=A0 If it was not res= et, you'd be limited by the existing congestion controller.

That would allow you to build up a big window and direct it at anot= her path, but creating a larger window is more work on top of completing th= e handshake.

NAT rebinds don't require resetti= ng the congestion controller if my memory is correct, so I don't believ= e they don't need to be covered by this new amplification factor.
=

Ian

On Wed, Oct 28, 2020 at 2:18 AM Mikkel Fahn= =C3=B8e J=C3=B8rgensen <mikkelfj@g= mail.com> wrote:
Rath= er than a race to the top with padding, would it be possible to do the oppo= site:

Force challen= ges and responses to occur in their packets and also UDP datagrams. This pr= events other traffic until a path is confirmed.

The initial handshake has several concerns wit= h padding:
<= br>
- amplif= ication attack mitigation
- PMTU discovery
- reply capacity for completing handshake

Since new paths do not need a han= dshake, there is less need for large replies. Of course there is the PMTU i= ssue still.
=


Kin= d Regards,
M= ikkel Fahn=C3=B8e J=C3=B8rgensen


On 28 October 2= 020 at 03.55.46, Eric Kinnear (ekinnear=3D40apple.com@dmarc.ietf.org) w= rote:

This is an i= nteresting PR, and likely accomplishes the goals at the moment.
I do re= ally like how we=E2=80=99ve kept some bidirectionally of the approach and t= he padding can stay as is.=C2=A0

Just thinking things th= rough a little bit:=C2=A0
(This = is all discussed below by Ian/Magnus/Martin/Kazuho, and others, just restat= ing so we have it in one place)

At any point, either endpoint can choose to send a PA= TH_CHALLENGE.
The presence of a PATH_C= HALLENGE always evokes a PATH_RESPONSE.

Therefore, we assume that in or= der to restrict folks from being able to spoof a source address when sendin= g a PATH_CHALLENGE and attack the real owner of that source address with th= e PATH_RESPONSE, we need to make the PATH_CHALLENGE very large as well.=C2= =A0

However, there=E2=80=99s 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=E2=80=99t ful= ly plugged the amplification hole, since an attacker can use=C2=A0any ot= her, smaller datagram=C2=A0to cause the other endpoint to generate full= -size datagrams containing PATH_CHALLENGE. This wasn=E2=80=99t previously a= huge issue since PATH_CHALLENGE wasn=E2=80=99t meaningfully larger than th= e smallest packet you=E2=80=99d otherwise be able to send (slash the per-pa= cket costs were potentially higher than the cost of the data inside that pa= cket).

=E2=80=94=E2=80=94=E2=80=94=C2=A0

One other approach we coul= d take here would be to restrict ourselves to only covering the cases where= you=E2=80=99re actively generating a PATH_CHALLENGE to validate a new path= , not responding to a new non-probing packet on an unvalidated path.=C2=A0<= /div>

In other words:=C2=A0
Only the cli= ent needs to pad PATH_CHALLENGE and any response to a padded PATH_CHALLENGE= should also be padded.=C2=A0That also fits nicely into the unidirectionali= ty of path validation as it stands today.


The other option that we haven=E2=80=99t discussed much is if = we=E2=80=99d rather live with the previous pre-padding problem and remove t= he padding.=C2=A0
My initial inclinati= on was to avoid this, but actually we=E2=80=99d be returning to a state whe= re the main risk was that the path wasn=E2=80=99t MTU compatible and any im= plementation migrating is likely already dealing with cases where packets a= ren=E2=80=99t going through on a path in at least one direction. So, the na= tural responses to path validation failures (for MTU reasons or otherwise),= if you map them all out, generally result in the =E2=80=9Ccorrect=E2=80=9D= behavior. We could then say =E2=80=9Cany endpoint using a new path is enco= uraged to do PMTUD or otherwise be careful that the path may not work in at= least one direction=E2=80=9D and leave it at that.

=E2=80=94=E2=80=94= =E2=80=94=C2=A0

Overall, I suspect we=E2=80=99re probably headed in t= he right direction by making the 3x limit more universal, although it does = seem like it introduces some really interesting cases to code around, and t= hat limit and double path validation might be more painful than just checki= ng for =E2=80=9Cam I client, therefore I should pad=E2=80=9D which is annoy= ing because it has a client/server distinction but does likely cause less c= hurn and risk for later fallout.

<= /div>
Thanks,
Eric


On Oct 27, 2020, at 7:41 PM, Martin Thomson <mt@lowentropy.net&g= t; wrote:

Thanks to everyone for the feedback.

I&= #39;ve written up a draft pull request here: https://github.com/quicwg/b= ase-drafts/pull/4264

This does something like what Magnus sugges= ts below.=C2=A0 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 su= mmarizing this issue. I think the above discussion is about
immediate mi= gration and repeated immediate migrations, but I also wonder if
we'v= e introduced a single packet amplification attack by requiring
PATH_RESP= ONSEs be padded on new paths without a requirement on the size of
PATH_C= HALLENGE(see first item)?

Validating a new path
If one receives o= nly a PATH_CHALLENGE on a new path, then the server
responds with a full= -sized PATH_RESPONSE.=C2=A0 This seems safe.=C2=A0 If a non-padded
PATH_= CHALLENGE is received on a new path, then the peer is supposed to send afully padded PATH_RESPONSE on the path, which could be >20x larger.=C2= =A0 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 t= he text about allowing kMinimumWindow each
kInitialRtt after migration a= nd change it to the 3x limit.=C2=A0 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
o= f data it can send is limited to three times the amount of data received, a= s
specified in Section 8.1 of {{QUIC-TRANSPORT}}.".

In order= to not get deadlocked by the 3x factor, I think we should change the
ne= wly added MUSTs to only apply to path validation prior to migration, not th= e
peer responding to migration.

My reasoning is that if a peer mi= grates prior to validating the path, it means
it's either unintentio= nal or they have no other choice, so the migrating peer
has implicitly d= ecided that validating PathMTU is not a prerequisite to
migrating.

So some quesitons and ideas as I think it is relevant to res= olve this as best as
possible.

So isn't this recreating the i= ssue 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 wit= h 1200 bytes UDP payload it fails. Thus maintaining a broken
path.
<= br>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 packe= t while
initiating path validation. If path validatation fails then mayb= e one need to
close down the connection as the migration ended up on a p= ath that was unable to
support QUIC. The question here is how to avoid t= he DoS attack this may open up
if an attack rewrites source address of p= ackets.

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-d= irectional. 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 applica= tion data if there is some that
are available to send.

But, I th= ink that one needs to work through the criterias for when the QUIC
conne= ction is shut down under the conditions that the path available is not
s= upporting 1200 bytes. Also do we end up in a situation where the client nee= ds
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:
* smim= e.p7s


--000000000000514b4605b2c0aa11--