Subject: [quicwg/base-drafts] be197b: Address validation is stateless reject

From: Martin Thomson <[email-masked]>
Date: Tue, 09 May 2017 23:36:48 -0700

Branch: refs/heads/invert_connection_id
  Home:   https://github.com/quicwg/base-drafts
  Commit: be197b6477363914433c444c778db6b8d7e3231d
      https://github.com/quicwg/base-drafts/commit/be197b6477363914433c444c778db6b8d7e3231d
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-tls.md

  Log Message:
  -----------
  Address validation is stateless reject

We already have enough text on how to tell a client to go away and come back.
But we don't really say how a server might do that statelessly.  Add a small
bit of text on that and we're done.

Closes #60

  Commit: 98683738eb3cddd7eb0d3713127dfa62d7dc8f4b
      https://github.com/quicwg/base-drafts/commit/98683738eb3cddd7eb0d3713127dfa62d7dc8f4b
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-tls.md

  Log Message:
  -----------
  Expand description

  Commit: 4d2e62cdd2ac132a16a3451c8d71db145f39a753
      https://github.com/quicwg/base-drafts/commit/4d2e62cdd2ac132a16a3451c8d71db145f39a753
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Rework cleartext packet descriptions

This defines a new packet type for the initial client cleartext packet, and
stateless rejects.  The remaining packets that carry cleartext messages remain
the same.  The final packet from the server is removed; instead the server
cleartext packet carries the server-selected connection ID.  The server can
propose a new connection ID in any of its cleartext packets, including the
version negotiation packet.

This will need to roll up changes from stateless rejects.  I'll merge that
branch after this commit.

Things that I might do differently: require the client to send an initial
packet after version negotiation on the basis that version negotiation is a
complete do-over.  Maybe also after a stateless reject, which would mean that
all packets containing the ClientHello would use that "initial" type.  That
would mean that only the initial type would have packet size restrictions,
which is nice.

Those alternatives give the server more options for changing connection ID as
well, but it also removes the ability for a server-side load balancer to easily
distinguish between connection IDs that the client proposes and those that the
server has provided.  Not sure which way that goes, I've opted to keep the
signal in place until we've had some more discussion.

  Commit: 9ba0fcc0a2251c7a923a6943a348e79db2a23fb0
      https://github.com/quicwg/base-drafts/commit/9ba0fcc0a2251c7a923a6943a348e79db2a23fb0
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-tls.md

  Log Message:
  -----------
  Expand on HelloRetryRequest rules

  Commit: e0473bb3e7a17ed228dd66ee620fe2494884f3cf
      https://github.com/quicwg/base-drafts/commit/e0473bb3e7a17ed228dd66ee620fe2494884f3cf
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Tidy up grammar

  Commit: ba82028683b070be98b6981a23a04a16d5b3f2c8
      https://github.com/quicwg/base-drafts/commit/ba82028683b070be98b6981a23a04a16d5b3f2c8
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-tls.md
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Jana's review comments

  Commit: f393f4ea86b0ef38afe280957f1e0a97f1b4291b
      https://github.com/quicwg/base-drafts/commit/f393f4ea86b0ef38afe280957f1e0a97f1b4291b
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Reset more completely for stateless retry and version negotiation

This is based on the discussion between editors and thus far on the list.  The
idea here is, in summary:

* Client Initial packets are always a complete reset, always contain a
ClientHello, are always padded to the minimum size, and include a randomized
packet number (except for retransmissions).  STREAM frames in these packets
always start at an offset of 0, even if the cryptographic handshake is
continued.  There can only be one of these packets.  The server can propose a
new connection ID in response to one of these packets (giving the server up to
three re-routing options).

* Server Stateless Retry packets cause the client to start over, retaining only
cryptographic handshake state.  There can only be one of these packets in a
flight.  This includes a server-proposed connection ID and an echo of the
client packet number.  This is because the server can't be expected to remember
what it chose when it sends subsequent packets.

* Version Negotiation packets also cause a reset.  This has the same rules for
connection ID and packet number as the Server Stateless Retry.

* Client Cleartext and Server Cleartext contain the other handshake messages.
These aren't really special in any way.

  Commit: 947522e1d31823ebcfe8c04baee9d1d8a5aeac45
      https://github.com/quicwg/base-drafts/commit/947522e1d31823ebcfe8c04baee9d1d8a5aeac45
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  MUST MUST MUST

  Commit: 0d40738b6427b747e6c6170ab5d3ffb0635719a1
      https://github.com/quicwg/base-drafts/commit/0d40738b6427b747e6c6170ab5d3ffb0635719a1
  Author: Martin Thomson <[email-masked]>
  Date:   2017-05-10 (Wed, 10 May 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Describe stateless retry in terms of a transport reset

This requires that we describe the exceptions to the process.

Minimally, this is the state necessary to ensure the integrity of the
handshake.  That is, the cryptographic handshake state continues and the client
has to remember what happened during version negotiation.  We can also point
out that keeping an RTT estimate is worthwhile, as is any congestion signals,
though these might be low value.

Compare: https://github.com/quicwg/base-drafts/compare/84410a748fd4...0d40738b6427