Subject: Expected Client Response to SERVER_BUSY

From: Nick Banks <[email-masked]>
Date: Tue, 19 Feb 2019 22:11:12 +0000

Hello Folks,

I've been looking at interim DDoS mitigation strategies for QUIC until we can have a more complete and QUIC aware DDoS and LB solution. One thing I came up with is just trying to force the client to fallback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and cooperation between the offload device and the backend server. Until that is complete, a simple solution could be a device in path just responding to new QUIC connection attempts (while an attack is in progress) with a connection close frame containing the SERVER_BUSY error. The logic to implement a simple device to do that should be quite trivial.

To that end, I was trying to figure out what the expected client response to any immediate (in the first RTT) connection close packets/frames would be and it seems we don't have anything in the spec. What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fallback to TCP immediately? Should we say anything in the spec?

Thanks,
- Nick

---

From: Ian Swett <[email-masked]>
Date: Wed, 20 Feb 2019 08:34:17 -0500

For HTTP/3, my intent was to close the connection immediately with a
connection close as you suggest, then the client would fall back to TCP,
and then ensure the next Alt-Svc advertisement via TCP cleared any existing
Alt-Svc entry so QUIC wasn't tried again in the immediate future.

I hadn't thought of assigning semantics to a specific error code, but I'm
reluctant to do so.  In our case, I think a more likely error code would
indicate the infrastructure doesn't support QUIC, rather than DDoS, but the
desired behavior of falling back to TCP and not attempting QUIC for a while
is the same.

The assumption I made above is that the client immediately falls back to
TCP.  That of course depends upon the type of client it is.  I'd expect a
browser to fall back, but I wouldn't expect curl or wget to.

There is a decent amount of text on fallback in the Applicability draft:
https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability.md

On Tue, Feb 19, 2019 at 5:11 PM Nick Banks <nibanks=
[email-masked]> wrote:

> Hello Folks,
>
>
>
> I’ve been looking at interim DDoS mitigation strategies for QUIC until we
> can have a more complete and QUIC aware DDoS and LB solution. One thing I
> came up with is just trying to force the client to fallback to TCP.
> Eventually, we will use Stateless Retry but that still requires a good bit
> of design work and cooperation between the offload device and the backend
> server. Until that is complete, a simple solution could be a device in path
> just responding to new QUIC connection attempts (while an attack is in
> progress) with a connection close frame containing the SERVER_BUSY error.
> The logic to implement a simple device to do that should be quite trivial.
>
>
>
> To that end, I was trying to figure out what the expected client response
> to any immediate (in the first RTT) connection close packets/frames would
> be and it seems we don’t have anything in the spec. What about SERVER_BUSY
> specifically? Is the client supposed to retry a new connection attempt?
> Should they fallback to TCP immediately? Should we say anything in the spec?
>
>
>
> Thanks,
>
> - Nick
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 20 Feb 2019 14:51:56 +0100

hi Ian,

Sent from my iPhone

> On 20 Feb 2019, at 14:34, Ian Swett <ianswett=[email-masked]> wrote:
> 
> For HTTP/3, my intent was to close the connection immediately with a connection close as you suggest, then the client would fall back to TCP, and then ensure the next Alt-Svc advertisement via TCP cleared any existing Alt-Svc entry so QUIC wasn't tried again in the immediate future.
> 
> I hadn't thought of assigning semantics to a specific error code, but I'm reluctant to do so.  In our case, I think a more likely error code would indicate the infrastructure doesn't support QUIC, rather than DDoS, but the desired behavior of falling back to TCP and not attempting QUIC for a while is the same.
> 
> The assumption I made above is that the client immediately falls back to TCP.  That of course depends upon the type of client it is.  I'd expect a browser to fall back, but I wouldn't expect curl or wget to.

This is a bit of an aside, but I’m curious here: why not? I’ve always thought of the semantics of TCP fallback as equivalent to a 3xx redirect (either temporary or permanent, depending on the client heuristics wrt the underlying reason for the redirect). curl won’t do this automagically unless you tell it to, but iirc wget will...

Am I wrong in thinking that most clients will see this as YA form of redirect?

Cheers,  

Brian

> There is a decent amount of text on fallback in the Applicability draft: https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability.md
> 
> 
> 
>> On Tue, Feb 19, 2019 at 5:11 PM Nick Banks <nibanks=[email-masked]> wrote:
>> Hello Folks,
>> 
>>  
>> 
>> I’ve been looking at interim DDoS mitigation strategies for QUIC until we can have a more complete and QUIC aware DDoS and LB solution. One thing I came up with is just trying to force the client to fallback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and cooperation between the offload device and the backend server. Until that is complete, a simple solution could be a device in path just responding to new QUIC connection attempts (while an attack is in progress) with a connection close frame containing the SERVER_BUSY error. The logic to implement a simple device to do that should be quite trivial.
>> 
>>  
>> 
>> To that end, I was trying to figure out what the expected client response to any immediate (in the first RTT) connection close packets/frames would be and it seems we don’t have anything in the spec. What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fallback to TCP immediately? Should we say anything in the spec?
>> 
>>  
>> 
>> Thanks,
>> 
>> - Nick

---

From: Ian Swett <[email-masked]>
Date: Wed, 20 Feb 2019 09:41:40 -0500

If a client follows 3xx redirects by default, then it seems sensible it'd
fall back to TCP automatically, but I'm not sure an immediate QUIC
connection close is equivalent to a redirect.  I can also imagine clients
that don't follow redirects by default falling back to TCP, so I think I
just chose a poor example.

On Wed, Feb 20, 2019 at 8:52 AM Brian Trammell (IETF) <[email-masked]>
wrote:

> This is a bit of an aside, but I’m curious here: why not? I’ve always
> thought of the semantics of TCP fallback as equivalent to a 3xx redirect
> (either temporary or permanent, depending on the client heuristics wrt the
> underlying reason for the redirect). curl won’t do this automagically
> unless you tell it to, but iirc wget will...
>
> https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability..md
> <https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability.md>
>
>
>
> [email-masked] <[email-masked]..org>> wrote:
>
>> Hello Folks,
>>
>>
>>

---

From: Nick Banks <[email-masked]>
Date: Wed, 20 Feb 2019 14:49:42 +0000

It would be nice to have a way for the server to say “QUIC is temporarily unavailable right now, please go use TCP instead.” Additionally, I don’t want to have to modify anything on the TCP side (Alt-Svc). The next connection after you fallback to TCP may try QUIC again, but you might just get the same behavior.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

________________________________
From: Ian Swett <[email-masked]>
Sent: Wednesday, February 20, 2019 6:41:40 AM
To: Brian Trammell (IETF)
Cc: Nick Banks; IETF QUIC WG; Mirja Kühlewind
Subject: Re: Expected Client Response to SERVER_BUSY

If a client follows 3xx redirects by default, then it seems sensible it'd fall back to TCP automatically, but I'm not sure an immediate QUIC connection close is equivalent to a redirect.  I can also imagine clients that don't follow redirects by default falling back to TCP, so I think I just chose a poor example.

On Wed, Feb 20, 2019 at 8:52 AM Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
hi Ian,

Sent from my iPhone

On 20 Feb 2019, at 14:34, Ian Swett <ianswett=[email-masked]<mailto:ianswett=[email-masked]>> wrote:

Cheers,

Brian

There is a decent amount of text on fallback in the Applicability draft: https://github.com/quicwg/ops-drafts/blob/master/draft-ietf-quic-applicability..md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fops-drafts%2Fblob%2Fmaster%2Fdraft-ietf-quic-applicability.md&data=02%7C01%7Cnibanks%40microsoft.com%7Cda54737de15f4f6a414d08d697419140%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636862705204591925&sdata=F7YkRR5oHUTuGTPGHdji929999WlXfSK7nIBeFohyLo%3D&reserved=0>

On Tue, Feb 19, 2019 at 5:11 PM Nick Banks <nibanks=[email-masked]<mailto:[email-masked]..org>> wrote:
Hello Folks,

Thanks,
- Nick

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 20 Feb 2019 07:03:49 -0800

On Wed, Feb 20, 2019 at 6:50 AM Nick Banks
<nibanks=[email-masked]> wrote:
> It would be nice to have a way for the server to say
> “QUIC is temporarily unavailable right now, please
> go use TCP instead.”

One issue here is that under a DDoS attack an ISP would just apply
selective blackholing or flow specification which would simply drop
all the incoming UDP traffic to protect the last mile. Depends on the
attack pattern somewhat, sometimes blackholing might be more granular,
but all in all you should expect that.

The only hope here is that a client would interpret response timeout
in the same way as SERVER_BUSY.

--
Töma

---

From: Nick Banks <[email-masked]>
Date: Wed, 20 Feb 2019 15:19:54 +0000

I want to support something a bit more efficient than simple rate limiting and packet drops. The client might have relatively large timeout in that case before falling back to TCP. If possible, I want to be able to give an immediate indication that it should try to fallback.

- Nick

-----Original Message-----
From: Töma Gavrichenkov <[email-masked]> 
Sent: Wednesday, February 20, 2019 7:04 AM
To: Nick Banks <[email-masked]>
Cc: Ian Swett <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; IETF QUIC WG <[email-masked]>; Mirja Kühlewind <[email-masked]>
Subject: Re: Expected Client Response to SERVER_BUSY

On Wed, Feb 20, 2019 at 6:50 AM Nick Banks <nibanks=[email-masked]> wrote:
> It would be nice to have a way for the server to say “QUIC is 
> temporarily unavailable right now, please go use TCP instead.”

One issue here is that under a DDoS attack an ISP would just apply selective blackholing or flow specification which would simply drop all the incoming UDP traffic to protect the last mile. Depends on the attack pattern somewhat, sometimes blackholing might be more granular, but all in all you should expect that.

The only hope here is that a client would interpret response timeout in the same way as SERVER_BUSY.

--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 20 Feb 2019 07:38:28 -0800

I mean, yes, handling such a case explicitly totally makes sense. I
just wanted to point out that there's an additional use case when UDP
transmission just suddenly stops under an attack.

Note that a DDoS attack towards a QUIC server isn't the only possible
scenario, the other one being a DDoS towards a client. In the latter
scenario, given the not-so-likely-but-completely-possible case when a
newly discovered DDoS amplifying protocol would be using port 443/udp,
even selective blackholing won't help to preserve QUIC connectivity.
As a matter of fact, there's no way to handle it
transport-protocol-wise, but maybe adding a timeout-related suggestion
of a SHOULD CONSIDER style to the spec would be a good idea.

| Töma Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 Feb 2019 10:49:42 -0800

Can we do better than an unauthenticated signal to "drop QUIC
immediately and use something else"?

I understand the desire of protecting servers against DOS attacks, but
the proposition here allows a middle-box or a man-on-the-side to send an
unencrypted signal and have the client immediately immediately drop the
connection. That does not feel right.

-- Christian Huitema

On 2/20/2019 7:38 AM, Töma Gavrichenkov wrote:
>> Cc: Ian Swett <[email-masked]>; Brian Trammell (IETF) <ietf@trammell..ch>; IETF QUIC WG <[email-masked]>; Mirja Kühlewind <[email-masked]>

---

From: Ian Swett <[email-masked]>
Date: Wed, 20 Feb 2019 13:52:16 -0500

Agreed it's not amazing, but stateless reset isn't available until the
handshake completes.  Did you have any suggestions?

On Wed, Feb 20, 2019 at 1:49 PM Christian Huitema <[email-masked]>
wrote:

> >> I want to support something a bit more efficient than simple rate
> limiting and packet drops. The client might have relatively large timeout
> in that case before falling back to TCP. If possible, I want to be able to
> give an immediate indication that it should try to fallback.
> >>
> >> - Nick
> >>
> >> Cc: Ian Swett <[email-masked]>; Brian Trammell (IETF)
> <ietf@trammell..ch>; IETF QUIC WG <[email-masked]>; Mirja Kühlewind <
> [email-masked]>
> selective blackholing or flow specification which would simply drop all the
> incoming UDP traffic to protect the last mile. Depends on the attack
> pattern somewhat, sometimes blackholing might be more granular, but all in
> all you should expect that.
> >>

---

From: Nick Banks <[email-masked]>
Date: Wed, 20 Feb 2019 18:58:27 +0000

The best thing I could think of is some client side logic that has a timer to wait for a possible valid server response for some short time after it receives the conn close frame. If it comes, ignore the close.

- Nick

From: Ian Swett <[email-masked]>
Sent: Wednesday, February 20, 2019 10:52 AM
To: Christian Huitema <[email-masked]>
Cc: Töma Gavrichenkov <[email-masked]>; Nick Banks <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; IETF QUIC WG <[email-masked]>; Mirja Kühlewind <[email-masked]>
Subject: Re: Expected Client Response to SERVER_BUSY

Agreed it's not amazing, but stateless reset isn't available until the handshake completes.  Did you have any suggestions?

On Wed, Feb 20, 2019 at 1:49 PM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:
Can we do better than an unauthenticated signal to "drop QUIC
immediately and use something else"?

-- Christian Huitema

On 2/20/2019 7:38 AM, Töma Gavrichenkov wrote:
> | mailto: [email-masked]<mailto:[email-masked]>
> | fb: ximaera
> | telegram: xima_era
> | skype: xima_era
> On Wed, Feb 20, 2019 at 7:19 AM Nick Banks <[email-masked]<mailto:[email-masked]>> wrote:
>> From: Töma Gavrichenkov <[email-masked]<mailto:[email-masked]>>
>> To: Nick Banks <[email-masked]<mailto:[email-masked]>>
>> Cc: Ian Swett <[email-masked]<mailto:[email-masked]>>; Brian Trammell (IETF) <ietf@trammell..ch<mailto:ietf@trammell..ch>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Mirja Kühlewind <[email-masked]<mailto:[email-masked]>>
>> On Wed, Feb 20, 2019 at 6:50 AM Nick Banks <nibanks=[email-masked]<mailto:[email-masked]>> wrote:

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 20 Feb 2019 11:43:08 -0800

> connection. That does not feel right.

A man-on-the-side (don't even mentioning a box-in-the-middle) could
*always* make a client drop a connection, e.g., by sending a large
amount of junk packets towards the client that the client would be
unable to correctly handle. It's just a matter of how much harm does
that box need to do to the network.

Any opposite approach I can think of requires to put the private key
of the server on a DDoS handling machine or to deploy it onto a DDoS
mitigation cloud, which not only increases exposure of the users' data
but is also explicitly forbidden in certain countries for companies
from certain industries. It's already only narrowly possible to avoid
doing so with QUIC (and that already requires either a collaboration
between the QUIC library supplier and the DDoS mitigation vendor —
which in turn leads to vendor lock — or a reverse engineering-based
design), so until we have a v2 which is (hopefully) more LB and
DDoS-aware, this is the lesser of two evils.

--
Töma

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Feb 2019 20:47:57 +0000

I believe that the solution to this problem (what a client does when the server is being DoS'd) is inherently out-of-band, and thus not part of the QUIC protocol.

Clients should do whatever they want to do as a response to SERVER_BUSY. We can't make the malicious ones stop, and anything we do to allow non-malicious ones to respond appropriately requires pre-sharing of something, or for the connection to succeed (which is essentially establishing a context for such sharing).

Designing policy around that is probably fodder for another discussion (that I hope we get together and have in the context of the HTTP wg).

-=R

On 2/20/19, 11:44 AM, "QUIC on behalf of Töma Gavrichenkov" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    --
    Töma

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 20 Feb 2019 21:02:16 +0000

Agreed that we cannot mandate any client behavior for malicious clients, but have clear guidance for well-behaved clients to fall back to TCP. This mechanism provides a very low CPU cost fast fallback to TCP under DoS attacks until all infrastructure can support QUIC natively. Certainly a big step up from just rate limiting UDP traffic. This way well behaved clients will have a good chance for connectivity and the malicious ones will be rate limited. And as pointed out middleboxes can do other bad things like drop all CIs.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Roberto Peon
Sent: Wednesday, February 20, 2019 12:48 PM
To: Töma Gavrichenkov <[email-masked]>; Christian Huitema <[email-masked]>
Cc: Nick Banks <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>; Mirja Kühlewind <[email-masked]>
Subject: Re: Expected Client Response to SERVER_BUSY

-=R

    

    --
    Töma

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Feb 2019 21:17:52 +0000

In some circumstances, falling back to TCP may be something that the application shouldn't do (TCP offers the wrong semantics, or there are concerns about visibility).

I think this is very much an application-level thing, and not so much a transport-level thing.

-=R

On 2/20/19, 1:02 PM, "Praveen Balasubramanian" <[email-masked]> wrote:

    -----Original Message-----
    From: QUIC <[email-masked]> On Behalf Of Roberto Peon
    Sent: Wednesday, February 20, 2019 12:48 PM
    To: Töma Gavrichenkov <[email-masked]>; Christian Huitema <[email-masked]>
    Cc: Nick Banks <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>; Mirja Kühlewind <[email-masked]>
    Subject: Re: Expected Client Response to SERVER_BUSY

    
    
    -=R

        

        --
        Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 20 Feb 2019 14:56:32 -0800

> This mechanism provides a very low CPU cost
> fast fallback to TCP under DoS attacks until all
> infrastructure can support QUIC natively

There are [a] few use cases when switching from TCP to QUIC v1 (in its
current state) is not feasible because of huge operational costs. So it
would be a more long term solution than that, probably till v2 or even
further.

> anything we do to allow non-malicious ones to
> respond appropriately requires pre-sharing,
> or for the connection to succeed

The question here is basically how to ensure the latter given a X00 Gbps
attack scale if you're neither Facebook nor Google.

> In some circumstances, falling back to TCP
> may be something that the application shouldn't do

Well, maybe, but then IMO the consequences of not being able to benefit
from switching to TCP if you're doing certain things with QUIC should be
outlined in the spec. Again, this is an application-level thing *now*, but
formerly the transport used to take full care of it, and the change in that
sort of breaks the habit of the users.

--
Töma

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Feb 2019 10:01:24 +0900

> Designing policy around that is probably fodder for another discussion (that I hope we get together and have in the context of the HTTP wg).

I think I mostly agree with Roberto here.

Anyways, the issue is with H3, not QUIC as a transport protocol. HTTP
is unique in sense that it can use either TCP or QUIC as a transport.
We cannot expect every application protocol to have that kind of
property.

And even in case of H3, our conclusion might depend on how the H3
endpoint was discovered. We might argue that it makes sense to permit
the fallback when the H3 endpoint was discovered due to an upgrade
from TCP (e.g. alt-svc). But the situation would be different if the
H3 endpoint was discovered through other means (e.g., extension field
of ESNI record).

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 21 Feb 2019 06:15:09 +0000

Why not deal with this at the DNS layer and work with the designs that are floating?

Other than that I agree with Roberto and Kazuho.

________________________________
Fra: QUIC <[email-masked]> på vegne af Kazuho Oku <[email-masked]>
Sendt: torsdag, februar 21, 2019 2:01 AM
Til: Roberto Peon
Cc: Töma Gavrichenkov; Ian Swett; Mirja Kühlewind; Christian Huitema; Nick Banks; Brian Trammell (IETF); IETF QUIC WG
Emne: Re: Expected Client Response to SERVER_BUSY

--
Kazuho Oku

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 21 Feb 2019 02:42:30 -0800

> We cannot expect every application protocol to have that kind of

— Well, I personally agree as long as two conditions are met:
1) The considerations discussed above are reflected in the HTTP/3 spec
— and that one certainly might be outside of this WG's area of
responsibility;
2) The QUIC spec is tailored for consistency with the charter,
specifically in the Section 1 "Introduction" where it states that, to
quote, "QUIC is a multiplexed and secure general-purpose transport
protocol".

As far as my myopic eyes can read, there's no requirement in the
charter for the protocol to be general purpose, and also effectively
the overall context of the discussions in the mailing list (as a
whole) and within this thread (in particular) doesn't imply generic
applicability, focusing strictly on the HTTP/X use case instead.

A "general purpose" goal IMO implies sort of more attention to the
variety of use cases, featuring probably some suggestions on how
[nearly] all the important applications active within the Internet
should be able to switch from the previous general purpose protocols
No. 6 and 17 towards the new 17+, or if some of them couldn't, then
why. If the new protocol only fits some certain use cases (e.g. HTTP),
then it's fine to release it under the existing charter, however, the
promise in the Section 1 in this case needs to be further reviewed.

1)
> H3 endpoint was discovered through other means
2)
> Why not deal with this at the DNS layer
> and work with the designs that are floating?

— This is totally correct as long as the required changes in the DNS
protocol — whatever they are — are implemented and deployed across the
DNS infrastructure before HTTP/3 sees the light of day.

--
Töma

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 21 Feb 2019 03:59:57 -0800

> effectively the overall context of the discussions in the mailing list
(as a
> applicability, focusing strictly on the HTTP/X use case instead.

I would strongly oppose that. While there are more general purpose features
schedule for v2 and the main driver for v1 is HTTP, a lot of design
decisions and discussion consider other uses cases, for example tunnelling,
extension frames, peer to peer networking, separation of stream id
semantics and the general layer segregation as is evident in error codes.

1)
2)

-- 
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 21 Feb 2019 06:52:00 -0800

On Thu, Feb 21, 2019, 3:59 AM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> I would strongly oppose that. While there are more general purpose
> features schedule for v2 and the main driver for v1 is HTTP, a lot of
> design decisions and discussion consider other uses cases,
>

Well, I agree with that, my point being that "a lot of" is not equal to
"all of the".

--
Töma

---

From: Nick Banks <[email-masked]>
Date: Thu, 21 Feb 2019 15:02:28 +0000

Ok, then perhaps I should pose a slightly more targeted question. What are people’s H3 implementations going to do if they get a SERVER_BUSY from a QUIC server? What should we recommend they do (either in applicability or h3 drafts)?

For Azure, we are seriously considering using this as a temporary DDoS protection solution until we can get a more fully functional system in place. I just want to make sure it doesn’t result in awful behavior on the client side.

Thanks,
- Nick

From: Töma Gavrichenkov <[email-masked]>
Sent: Thursday, February 21, 2019 6:52 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Christian Huitema <[email-masked]>; [email-masked]; Kazuho Oku <[email-masked]>; Nick Banks <[email-masked]>; Roberto Peon <[email-masked]>
Subject: Re: Expected Client Response to SERVER_BUSY

On Thu, Feb 21, 2019, 3:59 AM Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:
I would strongly oppose that. While there are more general purpose features schedule for v2 and the main driver for v1 is HTTP, a lot of design decisions and discussion consider other uses cases,

Well, I agree with that, my point being that "a lot of" is not equal to "all of the".

--
Töma

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 21 Feb 2019 16:32:45 +0100

As pointer out earlier in this thread there is text in https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/ (section 2). 

Do you think anything else is needed?

> Am 20.02.2019 um 23:56 schrieb Töma Gavrichenkov <[email-masked]>:
> 
> There are [a] few use cases when switching from TCP to QUIC v1 (in its current state) is not feasible because of huge operational costs. So it would be a more long term solution than that, probably till v2 or even further.
> 
> The question here is basically how to ensure the latter given a X00 Gbps attack scale if you're neither Facebook nor Google.
> 
> Well, maybe, but then IMO the consequences of not being able to benefit from switching to TCP if you're doing certain things with QUIC should be outlined in the spec. Again, this is an application-level thing *now*, but formerly the transport used to take full care of it, and the change in that sort of breaks the habit of the users.
> 
> --
> Töma

---

From: Nick Banks <[email-masked]>
Date: Thu, 21 Feb 2019 15:43:07 +0000

I read that section, generally, as you should support fallback to TCP. No real specifics.

I'm asking if we should add more. As Ian had already alluded to the client might take the Alt-Svc into account when falling back. How is it supposed to decide what to do if that says QUIC is available, but right now they just get a SERVER_BUSY error from QUIC?

It might be worth calling out a few possible scenarios that might be encountered and recommend a course of action. I can think of several scenarios that a client might encounter that might be interested to describe:

1. Client gets no response ever.
2. Client only gets a response after a long time.
3. Client gets some kind of protocol error in response (bad middlebox?).
4. Client gets a valid connection close in response.
5. Client handshake eventually fails (perhaps tampered with).

Thanks,
- Nick 

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Mirja Kühlewind
Sent: Thursday, February 21, 2019 7:33 AM
To: Töma Gavrichenkov <[email-masked]>
Cc: Praveen Balasubramanian <[email-masked]>; IETF QUIC WG <[email-masked]>; Roberto Peon <[email-masked]>
Subject: Re: Expected Client Response to SERVER_BUSY

As pointer out earlier in this thread there is text in https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-quic-applicability%2F&amp;data=02%7C01%7Cnibanks%40microsoft.com%7C0084d6c04e284f76cfd508d69811e099%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636863599903286321&amp;sdata=KO36Bt6jX5Xe%2B379FOfLYviKQNPRhJrwILSQr6oPKSA%3D&amp;reserved=0 (section 2). 

> > This mechanism provides a very low CPU cost fast fallback to TCP 
> > under DoS attacks until all infrastructure can support QUIC natively
> 
> > anything we do to allow non-malicious ones to respond appropriately 
> > requires pre-sharing, or for the connection to succeed
> 
> > In some circumstances, falling back to TCP may be something that the 
> > application shouldn't do
>

---

From: Ian Swett <[email-masked]>
Date: Thu, 21 Feb 2019 11:00:33 -0500

When the handshake fails for any reason, Chrome stops attempting to use
QUIC for 5 minutes to that hostname, and if the Alt-Svc is still present 5
minutes later(ie: it hasn't been cleared), then the next request to that
hostname after 5 minutes will try QUIC again.  If that QUIC handshake
fails, Chrome exponentially backs off and waits 10 minutes before trying
again.

An old, but fairly accurate doc describes this:
https://docs.google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2LFxPM/edit

I think breaking it down by reason makes sense, as you suggest.  If the
handshake fails due to a connection close, not trying that hostname for 5
minutes seems like a reasonable approach.  If you receive no packets in
response, then it might make more sense to assume that UDP 443 is blocked
completely and not try QUIC at all for 5 minutes(unless you have other
active/recent QUIC connections).

This is an area of heuristics, so we should be careful not to over-specify
what a client should do, but I'd be happy to see a bit more detail on the
blackhole and connection close cases at least.  I'm also curious what
people think we should do in response to 3 or 5?

On Thu, Feb 21, 2019 at 10:43 AM Nick Banks <nibanks=
[email-masked]> wrote:

> I'm asking if we should add more. As Ian had already alluded to the client
> might take the Alt-Svc into account when falling back. How is it supposed
> to decide what to do if that says QUIC is available, but right now they
> just get a SERVER_BUSY error from QUIC?
>
> It might be worth calling out a few possible scenarios that might be
> encountered and recommend a course of action. I can think of several
> scenarios that a client might encounter that might be interested to
> describe:
>
Defining 'a long time' is hard. I'd avoid trying to specify behavior for
this case separately.

> Cc: Praveen Balasubramanian <[email-masked]>; IETF QUIC WG <
> [email-masked]>; Roberto Peon <[email-masked]>
> As pointer out earlier in this thread there is text in
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-quic-applicability%2F&amp;data=02%7C01%7Cnibanks%40microsoft.com%7C0084d6c04e284f76cfd508d69811e099%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636863599903286321&amp;sdata=KO36Bt6jX5Xe%2B379FOfLYviKQNPRhJrwILSQr6oPKSA%3D&amp;reserved=0
> (section 2).
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 21 Feb 2019 08:45:55 -0800

Exponential backoff hopefully has a backstop (unlike the Iphone lockout
incident when you entered the wrong pin too many times).
How about a background QUIC poll ever so often while pursuing other
interests. Even if the connection cannot be used per se, it can provide
useful information. That might to an extend deal with some of the
interference events (3, 5).

On 21 February 2019 at 17.01.17, Ian Swett (
ianswett=[email-masked]) wrote:

An old, but fairly accurate doc describes this:
https://docs.google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2LFxPM/edit
<https://docs..google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2LFxPM/edit>

> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf..org%2Fdoc%2Fdraft-ietf-quic-applicability%2F&amp;data=02%7C01%7Cnibanks%40microsoft.com%7C0084d6c04e284f76cfd508d69811e099%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636863599903286321&amp;sdata=KO36Bt6jX5Xe%2B379FOfLYviKQNPRhJrwILSQr6oPKSA%3D&amp;reserved=0>
> (section 2).
>