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

[ianswett <[e-mail]>]

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