Subject: [quicwg/base-drafts] Discarding connection state at server on unvalidated client (#2656)

From: Jana Iyengar <[email-masked]>
Date: Sun, 28 Apr 2019 00:14:01 -0700

The recovery draft says:
```
Until the server has validated the client's address on the path, the amount of	
data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.	
If not all unacknowledged CRYPTO data can be sent, then all unacknowledged	
CRYPTO data sent in Initial packets should be retransmitted.  If no data can be	
sent, then no alarm should be armed until data has been received from the	
client.
```
@mikkelfj notes in #2655 that the sender should discard connection state after some time.

This should probably happen after the idle timeout. In which case, the idle timeout timer ought to be armed. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656

---

From: MikkelFJ <[email-masked]>
Date: Sun, 28 Apr 2019 01:50:01 -0700

I think idle timeout might be too long depending on have cheaply a rogue client can initiate new connection attempts, possibly from spoofed source addresses, but that needs more analysis.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656#issuecomment-487359066

---

From: ianswett <[email-masked]>
Date: Sun, 28 Apr 2019 16:49:16 -0700

I agree there should be a handshake timeout, which I believe is what you're discussing.  But if so, that seems like a transport issue?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656#issuecomment-487425763

---

From: Marten Seemann <[email-masked]>
Date: Sun, 28 Apr 2019 20:06:46 -0700

I agree with @ianswett that this is a transport issue, and doesn't belong in the recovery document. There we are only talking about the timers needed for loss recovery, and I would find it confusing to talk about closing connections there.
I'm not sure if we need to have any text about a handshake timeout. An idle timeout should be sufficient to garbage-collect connections that aren't active any more. Having a (shorter) handshake timeout is an optimization that implementations might or might not want to have, depending on the threat model.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656#issuecomment-487441082

---

From: MikkelFJ <[email-masked]>
Date: Sun, 28 Apr 2019 22:48:52 -0700

More generally on idle timeout - would it be OK to do a periodic GC scan risking up to 100% later timeout than the advertised idle timeout? Avoiding timers in passive connections is much cheaper.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656#issuecomment-487457679

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Apr 2019 22:55:06 -0700

Yes, idle timeout on a periodic sweep is likely better than assuming that a timer is in play.  As @marten-seemann says, anything we say here is in optimization territory.  It is likely a very useful optimization, but we don't need to say too much in the spec unless there is an interop or security hazard.  Offhand, I can't see anything other than a resource exhaustion problem, but that's clearly something that the periodic sweep should address.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656#issuecomment-487458422

---

From: MikkelFJ <[email-masked]>
Date: Sun, 28 Apr 2019 23:42:58 -0700

Am I correct in assuming that the PTO timer is not generally armed when data is transmitted actively on quality connections, or a while after data has been delivered?

Combined with idle timeout scans this would mean that most long running connections would likely not have an active timer.

This is a highly desirable property since a precise timer is O(log N). As far as I can tell theoretically O(1) timer wheels are no more effective than a good O(log N) implementation, including foregoing ordering below a certain resolution. There is a big difference between 1,000 entries and 100,000 timer entries.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656#issuecomment-487466431

---

From: ianswett <[email-masked]>
Date: Tue, 30 Apr 2019 15:48:18 -0700

This seems somewhat related to Issue #2602

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656#issuecomment-488142890

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 30 Apr 2019 15:49:15 -0700

Fair point, @ianswett (and others) -- this should be against transport. It's probably worth clarifying that last sentence so it's not confusing to implementers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2656#issuecomment-488143085