Subject: [quicwg/base-drafts] Move crypto to stream 0 (#247)

From: Mike Bishop <[email-masked]>
Date: Sun, 29 Jan 2017 16:37:19 -0800

In #246, we agreed that the crypto stream and only the crypto stream would be exempt from connection-level flow control.  It's also exempt from the congestion controller and has special rules about retransmissions.  Is there a logical reason to have stream-level flow control on a stream that is a control channel?

If not, let's make it clear that the crypto stream is special.  Make it Stream 0, the stream that can't be given any stream-level flow control credit because it's a reserved value.  The change is relatively modest, and seems like a good fit to our special snowflake stream.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/247

-- Commit Summary --

  * Remove connection-level flow control exclusion
  * The special snowflake is stream 0

-- File Changes --

    M draft-ietf-quic-http.md (11)
    M draft-ietf-quic-tls.md (28)
    M draft-ietf-quic-transport.md (21)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/247.patch
https://github.com/quicwg/base-drafts/pull/247.diff

-- 
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/pull/247

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jan 2017 16:46:04 -0800

The big change here is that stream-level flow control doesn't apply to TLS - it becomes impossible to give stream 0 stream-level credit.  Even with the exemption from the connection-level flow control, stream 0 was previously still subject to stream-level flow control.

The change is safe because stream 0 carries mostly cleartext data and WINDOW_UPDATE was previously treated with some suspicion anyway.  I'd like to confirm that this is acceptable with others before we merge this.

-- 
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/pull/247#issuecomment-275959967

---

From: ianswett <[email-masked]>
Date: Sun, 29 Jan 2017 17:12:20 -0800

To clarify, "this" is exempting stream 0 from stream level flow control as well?  If so, I think so, but I'd like to hear if others have concerns.

That conveniently still allows, stream 0 to be used in the WINDOW_UPDATE frame to indicate the connection's flow control window.

-- 
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/pull/247#issuecomment-275961873

---

From: Marten Seemann <[email-masked]>
Date: Sun, 29 Jan 2017 17:19:43 -0800

If stream 0 isn't controlled by stream-level flow control, this opens up a DoS. A peer introduce a gap in stream data and then just send arbitrary data with a higher offset. The receiver can't even verify if this data is a valid TLS message, because the gap would prevent reading from that stream.

-- 
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/pull/247#issuecomment-275962454

---

From: ianswett <[email-masked]>
Date: Sun, 29 Jan 2017 17:57:59 -0800

In reality, I don't think it's a DoS, because the receiver has an expected max size for a handshake message.  A CHLO is always 1 packet and a HRR(aka reject) is multiple.  If one side receives data way outside the expected range, they can just terminate the handshake.  In the case of the server, if you're only doing stateless rejects, all CHLO's better have a stream offset of 0.

Also, if the argument is that control messages(ie: public resets, flow control updates, etc) can be processed immediately, and that's why they don't count towards flow control, then I think the same argument applies for the crypto stream, modulo any concerns about the size of a reject/etc.

-- 
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/pull/247#issuecomment-275965599

---

From: Marten Seemann <[email-masked]>
Date: Sun, 29 Jan 2017 18:06:51 -0800

What about data received after the handshake? Terminating the connection if data beyond a certain offset is received sounds a lot like an implicit flow control window, just without the option to increase it. 

-- 
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/pull/247#issuecomment-275966346

---

From: ianswett <[email-masked]>
Date: Sun, 29 Jan 2017 18:14:49 -0800

I can't think of anything the client sends post-handshake, at least in QUIC crypto and TLS.

I'd like to think about it as imposing some sort of validity constraints on the crypto stream which are specific to the crypto being done.  ie: As long as you're doing the crypto the peer expects, then all should go well.  If you deviate, then given how important crypto is to QUIC, the connection is killed.

But tell me if I'm crazy.

-- 
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/pull/247#issuecomment-275966963

---

From: Marten Seemann <[email-masked]>
Date: Sun, 29 Jan 2017 19:20:47 -0800

@ianswett: Using TLS, there's the session ticket, but with reasonable limits this will probably not be a problem (I'm not sure if that's true for extremely long-lived connections though).
I was thinking about other handshake protocols that might have different requirements. But maybe I'm taking the generalization too far.

-- 
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/pull/247#issuecomment-275972739

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jan 2017 19:30:42 -0800

If we look at the crypto handshake in the abstract, the only two functions that are needed are tickets and source address tokens.  Both of these have to be less than 1280 octets.  If we went the way that this PR suggests, I'd be happy to write advice about how much of that to accept.  Maybe even require that a server not produce more than a small multiple of this limit without receiving any acknowledgment.  That would allow a client to police this.

The other thing that is somewhat unbounded is client certificates.  That too is probably manageable on the same basis.

-- 
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/pull/247#issuecomment-275973507

---

From: Patrick McManus <[email-masked]>
Date: Mon, 30 Jan 2017 02:08:30 -0800

I was going to mention client certs too - but I think I would rather have this PR and manage it heuristically than worry about the complications of flow control on a control stream. I favor merging.

-- 
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/pull/247#issuecomment-276023453

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Jan 2017 05:50:07 -0800

@MikeBishop pushed 1 commit.

fd152a3  Missed a Stream 1 reference

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/247/files/b328729632250a973a5f0fdbad1c3277ac28bfdf..fd152a371474d03bbbdee12e97ff3b90a0414409

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Jan 2017 05:57:40 -0800

c0f4e33  Notable enough for changelog entries

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/247/files/fd152a371474d03bbbdee12e97ff3b90a0414409..c0f4e33e86f843ef59a4cdfc351ae16476a3d469

---

From: janaiyengar <[email-masked]>
Date: Tue, 31 Jan 2017 13:58:41 -0800

I don't think you're simplifying things by removing flow control on the crypto stream. Is there a reason, besides textual simplicity, for doing this? I don't think it makes implementation any easier, but may make it harder, since there's basically no way for the implementation to send more than X bytes, and the receiver must enforce this, separate from any stream-level flow control logic (since that logic will be tied to sending WINDOW_UPDATE frames.) We'll also need to specify a required min window offset that MUST be supported on the crypto stream. This seems like a largely unnecessary limit and special case.

I'm not sure I see what real benefit it brings... I'm inclined towards keeping this as Stream 1 with stream-level flow control applied to it.

-- 
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/pull/247#issuecomment-276506147