Subject: Re: How many Initial packets shall carry the retry token?

From: Ian Swett <[email-masked]>
Date: Sat, 1 Dec 2018 16:09:22 -0500

PR sent: https://github.com/quicwg/base-drafts/pull/2089

On Thu, Nov 29, 2018 at 11:57 AM Dmitri Tikhonov <
[email-masked]> wrote:

> Works for me as well.
>
>   - Dmitri.
>
> On Thu, Nov 29, 2018 at 11:55:34AM -0500, Ian Swett wrote:
> > That's fine with me.  I'd also really like to get this written down
> before
> > we forget again.
> >
> > On Thu, Nov 29, 2018 at 11:39 AM Christian Huitema <[email-masked]>
> > wrote:
> >
> > >
> > > > On Nov 29, 2018, at 7:09 AM, Ian Swett <[email-masked]> wrote:
> > > >
> > > > All retransmittable Initial packets works for me, if the goal is to
> > > avoid including it in ACK-only Initials.
> > >
> > > That requires using knowledge of the packet content to format and
> validate
> > > the header, which doesn't look right. Also, we are making assumptions
> here
> > > that middle boxes properly maintain state, which is dubious.
> > >
> > > I would prefer to just include the token in every initial packet.
> There is
> > > overhead indeed but that's only on the last ACK. And we can optimize
> that
> > > out by using implicit ACK.
> > >
> > >  -- Christian Huitema
> > >
>

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 2 Dec 2018 07:55:21 +0900

iPhoneから送信

2018/11/30 1:38、Christian Huitema <[email-masked]>のメール:

>> All retransmittable Initial packets works for me, if the goal is to avoid including it in ACK-only Initials.
> 
> That requires using knowledge of the packet content to format and validate the header, which doesn't look right. Also, we are making assumptions here that middle boxes properly maintain state, which is dubious.
> 
> I would prefer to just include the token in every initial packet. There is overhead indeed but that's only on the last ACK. And we can optimize that out by using implicit ACK.

Sorry I missed the responses in the thread.

I think the reasoning misses what happens in case of HRR.

Therefore, I propose to state that the client MUST send Initial packets with tokens until it sees an Initial sent by the server.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 1 Dec 2018 15:29:02 -0800

> Therefore, I propose to state that the client MUST send Initial packets with tokens until it sees an Initial sent by the server.

I would rather have a bit of overhead in the case of HRR than an
ambiguous rule. I understand the reasoning that receiving a packet from
the server means that the server has installed state for the connection,
but this only applies to the server. It does not necessarily apply to
the firewall in front of the server farm. Many of these firewalls are
stateless, and will just send a retry if they see an Initial without a
token, and then everyone will be very confused.

-- Christian Huitema

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 3 Dec 2018 09:36:11 +0900

2018年12月2日(日) 8:29 Christian Huitema <[email-masked]>:
> I would rather have a bit of overhead in the case of HRR than an ambiguous rule. I understand the reasoning that receiving a packet from the server means that the server has installed state for the connection, but this only applies to the server. It does not necessarily apply to the firewall in front of the server farm. Many of these firewalls are stateless, and will just send a retry if they see an Initial without a token, and then everyone will be very confused.

I am not sure if I agree with your assumption that firewall will be
stateless in sense that it does not remember the paths that are
validated.

IIUC, the primary role of a firewall installed on path is to mitigate
bandwidth exhaustion attacks. It is important because it is often the
case that the server does not have a connection as wide as what a
firewall could have. A "stateless" firewall cannot block 1-RTT packets
coming from unvalidated client addresses. Therefore, it does not meet
the primary requirement.

The other issue of requiring every Initial to include a token is that
we cannot enforce it (or at least I am opposed to servers enforcing
it), because it is essentially about creating a new attack vector for
man-on-the-side attackers to disrupt a connection.

-- 
Kazuho Oku