Subject: [quicwg/base-drafts] Move and consolidate address validation (#1886)

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Oct 2018 01:07:38 +0000 (UTC)

The two disparate sections on address validation are better together.  That means deferring the description of Retry to after the connection establishment section, but I think that makes sense.  I've added a forward reference.

Aside from moves there is a tiny bit of new glue text in the top of the respective sections.  I had to tweak some of it to reflect the reorganization, and I noticed some duplication that I eliminated from the first two paragraphs of the path migration section.

I added a picture showing how Retry is added to the handshake flow, addressing a TODO.

I merged the sections on dealing with NEW_TOKEN and address validation for future connections (or should that be returning connections...).  That was just removing the section heading.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Move and consolidate address validation
  * Move cross references

-- File Changes --

    M draft-ietf-quic-transport.md (363)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1886.patch
https://github.com/quicwg/base-drafts/pull/1886.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/1886

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Oct 2018 21:40:45 -0700

@martinthomson pushed 1 commit.

5d0379b  Remove redundant retry section

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/c952551f9b65ded819a6e5ced04174228671de03..5d0379b828bc23dc2bb0adf4b73c7c9d34c84b72

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Oct 2018 16:16:16 -0700

789db42  Restructure slightly

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/5d0379b828bc23dc2bb0adf4b73c7c9d34c84b72..789db42c6b0aa75b9b02ae9dc971893dbb204caf

---

From: ianswett <[email-masked]>
Date: Mon, 22 Oct 2018 18:43:59 -0700

ianswett commented on this pull request.

Thanks for the reorg.  I think this text needs some work.

> @@ -1365,7 +1203,9 @@ packets.
 
 The first client packet of the cryptographic handshake protocol MUST fit within
 a 1232 octet QUIC packet payload.  This includes overheads that reduce the space
-available to the cryptographic handshake protocol.
+available to the cryptographic handshake protocol.  This forms part of the

I don't feel like this is at the right spot.  This is saying the Initial CRYPTO message needs to fit into 1232 bytes, but doesn't talk about the min packet size.

> @@ -1656,34 +1496,193 @@ One way that a new format could be introduced is to define a TLS extension with
 a different codepoint.

-## Stateless Retries {#stateless-retry}
-<!-- TODO: Move this section elsewhere. -->
+# Address Validation
+
+Address validation is used by QUIC to avoid being used for a traffic
+amplification attack.  In such an attack, a packet is sent to a server with
+spoofed source address information that identifies a victim.  If a server
+generates more or larger packets in response to that packet, the attacker can
+use the server to send more data toward the victim than it would be able to send
+on its own.
+
+The primary defense against amplification attack is verifying that an endpoint
+is able to receive packets at the transport address that it claims.  Address
+validation is performed both during connection establishment (see
+{{validate-new}}) and during connection migration (see {{migrate-validate}}).

nit: how about validate-handshake or something similar as the section title?  I was a bit confused about what validate-new might be talking about prior to reading this sentence.

> +validation is performed both during connection establishment (see
+{{validate-new}}) and during connection migration (see {{migrate-validate}}).
+
+
+## Address Validation During Connection Establishment {#validate-new}
+
+During the initial handshake, QUIC requires that clients send UDP datagrams with
+at least 1200 octets of payload until the server has completed address
+validation. A server can thereby send more data to an unproven address without
+increasing the amplification advantage gained by an attacker.
+
+A server eventually confirms that a client has received its messages when the
+first Handshake-level message is received. This might be insufficient, either
+because the server wishes to avoid the computational cost of completing the
+handshake, or it might be that the size of the packets that are sent during the
+handshake is too large.  This is especially important for 0-RTT, where the

is -> are

> +on its own.
+
+The primary defense against amplification attack is verifying that an endpoint
+is able to receive packets at the transport address that it claims.  Address
+validation is performed both during connection establishment (see
+{{validate-new}}) and during connection migration (see {{migrate-validate}}).
+
+
+## Address Validation During Connection Establishment {#validate-new}
+
+During the initial handshake, QUIC requires that clients send UDP datagrams with
+at least 1200 octets of payload until the server has completed address
+validation. A server can thereby send more data to an unproven address without
+increasing the amplification advantage gained by an attacker.
+
+A server eventually confirms that a client has received its messages when the

I'd drop eventually.

> +
+The primary defense against amplification attack is verifying that an endpoint
+is able to receive packets at the transport address that it claims.  Address
+validation is performed both during connection establishment (see
+{{validate-new}}) and during connection migration (see {{migrate-validate}}).
+
+
+## Address Validation During Connection Establishment {#validate-new}
+
+During the initial handshake, QUIC requires that clients send UDP datagrams with
+at least 1200 octets of payload until the server has completed address
+validation. A server can thereby send more data to an unproven address without
+increasing the amplification advantage gained by an attacker.
+
+A server eventually confirms that a client has received its messages when the
+first Handshake-level message is received. This might be insufficient, either

insufficient for what?

> +
+The primary defense against amplification attack is verifying that an endpoint
+is able to receive packets at the transport address that it claims.  Address
+validation is performed both during connection establishment (see
+{{validate-new}}) and during connection migration (see {{migrate-validate}}).
+
+
+## Address Validation During Connection Establishment {#validate-new}
+
+During the initial handshake, QUIC requires that clients send UDP datagrams with
+at least 1200 octets of payload until the server has completed address
+validation. A server can thereby send more data to an unproven address without
+increasing the amplification advantage gained by an attacker.
+
+A server eventually confirms that a client has received its messages when the
+first Handshake-level message is received. This might be insufficient, either

Or maybe this whole paragraph should be removed, because it's really not easy to read for me and I'm not sure what it's attempting to add.

> +
+Initial[0]: CRYPTO[CH] ->
+
+                                                <- Retry+Token
+
+Initial+Token[0]: CRYPTO[CH] ->
+
+                                 Initial[0]: CRYPTO[SH] ACK[0]
+                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
+                                 <- 1-RTT[0]: STREAM[1, "..."]
+~~~~
+{: #fig-retry title="Example Handshake Showing Retry"}
+
+A connection MAY be accepted without address validation - or with only limited
+validation - but a server SHOULD limit the data it sends toward an unvalidated
+address.  Successful completion of the cryptographic handshake implicitly

I think this last sentence is slightly incorrect.  Given it's covered above, maybe remove it?  Also, the limit towards an unvalidated address is covered above, so if there's anything important being added here, maybe move it above?

> +
+Initial+Token[0]: CRYPTO[CH] ->
+
+                                 Initial[0]: CRYPTO[SH] ACK[0]
+                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
+                                 <- 1-RTT[0]: STREAM[1, "..."]
+~~~~
+{: #fig-retry title="Example Handshake Showing Retry"}
+
+A connection MAY be accepted without address validation - or with only limited
+validation - but a server SHOULD limit the data it sends toward an unvalidated
+address.  Successful completion of the cryptographic handshake implicitly
+provides proof that the client has received packets from the server.
+
+
+### Address Validation for Future Connections {#validation-future}

Technically this is still token based address validation, so the previous heading was a bit misleading.  Possibly it should be renamed Retry based address validation?

+There is no need for a single well-defined format for the token because the
+server that generates the token also consumes it.  A token could include

If the token includes this information, should we say something like.  If any information is included, it SHOULD be encrypted to avoid spoofing or leaking of information?

+There is no need for a single well-defined format for the token because the
+server that generates the token also consumes it.  A token could include
+information about the claimed client address (IP and port), a timestamp, and any
+other supplementary information the server will need to validate the token in
+the future.
+
+An address validation token MUST be difficult to guess.  Including a large

This seems like the most critical requirement, so maybe it should be first?  Especially since the first and third paragraphs of this section flow together better than having this one in the middle.

-- 
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/1886#pullrequestreview-167155971

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Oct 2018 22:58:40 -0700

@martinthomson pushed 3 commits.

54c6a7e  Add version negotiation picture
05ec2f6  Consistency fixes
534a4e3  Reorder section

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/789db42c6b0aa75b9b02ae9dc971893dbb204caf..534a4e32629d3bc0c02a74447124c5e5e2fa4bda

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Oct 2018 23:20:34 -0700

@martinthomson pushed 2 commits.

e189a0e  Reword the address validation section heaviy
18835d7  Reorder the section as well

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/534a4e32629d3bc0c02a74447124c5e5e2fa4bda..18835d7ef7334276e9d0b796c9bb2e349e48cfeb

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Oct 2018 23:21:24 -0700

martinthomson commented on this pull request.

Thanks for reading Ian.

Clearly the bit on address validation during the handshake was unclear, so I've worked on it some more.  That bit is all new, so read carefully.

Other comments should be addressed.

Removed.  Also, some more rewording above.

There isn't any need to encrypt in many cases.  The information you tend to want here is an IP and maybe port, maybe with a timestamp.  All of which is already visible to any observer.  I expect that many implementations will encrypt, just to keep the details of their DoS mitigation secret, but I don't want too much hand-holding, especially when we'd be basing that recommendation on information we can't really describe in any detail.

I've moved the first paragraph to the end instead.

+

Well, this is a very important point.  Namely that address validation is a natural by-product of the handshake completing.

-- 
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/1886#pullrequestreview-167224384

---

From: ianswett <[email-masked]>
Date: Tue, 23 Oct 2018 22:44:09 +0000 (UTC)

ianswett approved this pull request.

I still think validate-new is a weird heading name, but that's just because I'm reading the markdown.

-- 
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/1886#pullrequestreview-167668650

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:20:33 -0700

de33af6  Remove more text
1bd4472  TODO structure
fcdfbba  s/Source/Client/

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/18835d7ef7334276e9d0b796c9bb2e349e48cfeb..fcdfbba5e63f01887f15a0494de25873290c2d32

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 16:21:36 -0700

janaiyengar commented on this pull request.

> +handshake, the server then needs to validate that the client owns the address
+that it claims.  QUIC therefore provides mechanisms for source address
+validation during connection establishment.
+
+Source addresses can be verified through an address validation token.  This
+token is delivered during connection establishment with a Retry packet (see
+{{validate-retry}}) or in a previous connection using the NEW_TOKEN frame (see
+{{validate-future}}).
+
+
+### Address Validation using Retry Packets {#validate-retry}
+
+QUIC uses token-based address validation during connection establishment.  Any
+time the server wishes to validate a client address, it provides the client with
+a token.  As long as it is not possible for an attacker to generate a valid
+token for its address (see {{token-integrity}}) and the client is able to return

```suggestion
token for its address (see {{token-integrity}}) and the client is able to return
token for its own address (see {{token-integrity}}) and the client is able to return
```

-- 
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/1886#pullrequestreview-167677222

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 16:22:35 -0700

+### Address Validation using Retry Packets {#validate-retry}
+
+QUIC uses token-based address validation during connection establishment.  Any
+time the server wishes to validate a client address, it provides the client with
+a token.  As long as it is not possible for an attacker to generate a valid
+token for its address (see {{token-integrity}}) and the client is able to return
+that token, it proves to the server that it received the token.
+
+Upon receiving the client's Initial packet, the server can request address
+validation by sending a Retry packet ({{packet-retry}}) containing a token. This
+token is repeated by the client in an Initial packet after it receives the Retry
+packet.  In response to receiving a token in an Initial packet, a server can
+either abort the connection or permit it to proceed.
+
+

```suggestion
```

-- 
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/1886#pullrequestreview-167677421

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 16:22:54 -0700

+
+A server can also use the Retry packet to defer the state and processing costs

```suggestion
A server can also use the Retry packet to defer the state and processing costs
A server can also use a Retry packet to defer the state and processing costs
```

-- 
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/1886#pullrequestreview-167677480

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 23:25:35 +0000 (UTC)

+of connection establishment.  By giving the client a different connection ID to
+use, the connection might be routed to a different server instance, which have

```suggestion
use, a server can cause the connection to be routed to a server instance with
more resources available for new connections.
```

-- 
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/1886#pullrequestreview-167678067

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 16:25:44 -0700

+additional capacity for new connections.

```suggestion
```

-- 
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/1886#pullrequestreview-167678108

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 23:26:16 +0000 (UTC)

16a714d  own

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/fcdfbba5e63f01887f15a0494de25873290c2d32..16a714d64ed1e5029450d3d96225554115fc908d

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 23:26:25 +0000 (UTC)

f819aba  remove line

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/16a714d64ed1e5029450d3d96225554115fc908d..f819abac302c7b0b34bd104d22dc7affecac6c5f

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:26:29 -0700

20f10bb  a

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/f819abac302c7b0b34bd104d22dc7affecac6c5f..20f10bb411e65506c97631e0cc998c9d272cc576

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:26:44 -0700

fedd189  routing change

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/20f10bb411e65506c97631e0cc998c9d272cc576..fedd1894702300479390cd535cdafff8efcd24c9

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 23:26:54 +0000 (UTC)

3bbc4bf  fixup

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/fedd1894702300479390cd535cdafff8efcd24c9..3bbc4bfd26dfc5e7117f4cd20dcb74c6d01c903c

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:28:03 -0700

a1e1377  line length fix

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/3bbc4bfd26dfc5e7117f4cd20dcb74c6d01c903c..a1e137754521aff50442e951c731ba23baff524e

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 23:28:58 +0000 (UTC)

+The server uses the NEW_TOKEN frame {{frame-new-token}} to provide the client
+with an address validation token that can be used to validate future
+connections.  The client may then use this token to validate future connections
+by including it in the Initial packet's header.  The client MUST NOT use the
+token provided in a Retry for future connections.
+
+Unlike the token that is created for a Retry packet, there might be some time
+between when the token is created and when the token is subsequently used.
+Thus, a resumption token SHOULD include an expiration time.  The server MAY
+include either an explicit expiration time or an issued timestamp and
+dynamically calculate the expiration time.  It is also unlikely that the client
+port number is the same on two different connections; validating the port is
+therefore unlikely to be successful.
+
+A resumption token SHOULD be easily distinguishable from tokens that are sent in

```suggestion
A resumption token SHOULD be constructed to be easily distinguishable from tokens that
are sent in Retry packets as they are carried in the same field.
```

-- 
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/1886#pullrequestreview-167678790

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 23:29:18 +0000 (UTC)

+Retry packets as they are carried in the same field.

```suggestion
```

-- 
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/1886#pullrequestreview-167678852

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 16:31:47 -0700

+A token allows a server to correlate activity between connections.

```suggestion
A token allows a server to correlate activity between the connection where the token
was issued and any connection where it is used.
```

-- 
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/1886#pullrequestreview-167679410

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 16:32:09 -0700

+A token allows a server to correlate activity between connections.
+Specifically, the connection where the token was issued, and any connection

```suggestion
```

-- 
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/1886#pullrequestreview-167679481

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 16:32:22 -0700

+A token allows a server to correlate activity between connections.
+Specifically, the connection where the token was issued, and any connection
+where it is used.  Clients that want to break continuity of identity with a

```suggestion
Clients that want to break continuity of identity with a
```

-- 
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/1886#pullrequestreview-167679522

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 23:33:28 +0000 (UTC)

+A client SHOULD NOT reuse a token.  Reusing a token allows connections to be

```suggestion
A client SHOULD NOT use a token more than once.  Reusing a token allows connections to be
```

-- 
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/1886#pullrequestreview-167679749

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:34:59 -0700

c7e243d  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/9bb19697ff64cbb6a943cc7f2171a819cba2b319..c7e243dc0a43d8f2a77baea4046dce299866dc3f

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:35:09 -0700

6b6af8d  remove extra

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/c7e243dc0a43d8f2a77baea4046dce299866dc3f..6b6af8dc2da53638d133e8d72409448a3cb4a15c

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 23:35:23 +0000 (UTC)

04e2d13  correlation expansion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/6b6af8dc2da53638d133e8d72409448a3cb4a15c..04e2d13af62dbb3269aea1c3130fecac002ba2ef

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:35:30 -0700

5dea042  remove extra

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/04e2d13af62dbb3269aea1c3130fecac002ba2ef..5dea042bf53916e4329e4fd6a4281f2caa02928f

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:35:39 -0700

ca7b73d  remove extra

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1886/files/5dea042bf53916e4329e4fd6a4281f2caa02928f..ca7b73d47a74ffa73753f3a3560627480c0c50e0

---

From: janaiyengar <[email-masked]>
Date: Tue, 23 Oct 2018 16:36:48 -0700

janaiyengar approved this pull request.

-- 
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/1886#pullrequestreview-167680294

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 16:37:13 -0700

Merged #1886 into master.

-- 
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/1886#event-1922009165

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 20:55:09 -0700

a different codepoint.

In 7dc45966

-- 
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/1886#discussion_r227635358