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

[Martin Thomson <[e-mail]>]

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.

> +
+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

Removed.  Also, some more rewording above.

>  
+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

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.

>  
+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

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

> +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

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