target = "https://www.rfc-editor.org/rfc/rfc9000#section-8.1"

# 8.1.  Address Validation during Connection Establishment
#
# Connection establishment implicitly provides address validation for
# both endpoints.  In particular, receipt of a packet protected with
# Handshake keys confirms that the peer successfully processed an
# Initial packet.  Once an endpoint has successfully processed a
# Handshake packet from the peer, it can consider the peer address to
# have been validated.
# 
# Additionally, an endpoint MAY consider the peer address validated if
# the peer uses a connection ID chosen by the endpoint and the
# connection ID contains at least 64 bits of entropy.
# 
# For the client, the value of the Destination Connection ID field in
# its first Initial packet allows it to validate the server address as
# a part of successfully processing any packet.  Initial packets from
# the server are protected with keys that are derived from this value
# (see Section 5.2 of [QUIC-TLS]).  Alternatively, the value is echoed
# by the server in Version Negotiation packets (Section 6) or included
# in the Integrity Tag in Retry packets (Section 5.8 of [QUIC-TLS]).
# 
# Prior to validating the client address, servers MUST NOT send more
# than three times as many bytes as the number of bytes they have
# received.  This limits the magnitude of any amplification attack that
# can be mounted using spoofed source addresses.  For the purposes of
# avoiding amplification prior to address validation, servers MUST
# count all of the payload bytes received in datagrams that are
# uniquely attributed to a single connection.  This includes datagrams
# that contain packets that are successfully processed and datagrams
# that contain packets that are all discarded.
# 
# Clients MUST ensure that UDP datagrams containing Initial packets
# have UDP payloads of at least 1200 bytes, adding PADDING frames as
# necessary.  A client that sends padded datagrams allows the server to
# send more data prior to completing address validation.
# 
# Loss of an Initial or Handshake packet from the server can cause a
# deadlock if the client does not send additional Initial or Handshake
# packets.  A deadlock could occur when the server reaches its anti-
# amplification limit and the client has received acknowledgments for
# all the data it has sent.  In this case, when the client has no
# reason to send additional packets, the server will be unable to send
# more data because it has not validated the client's address.  To
# prevent this deadlock, clients MUST send a packet on a Probe Timeout
# (PTO); see Section 6.2 of [QUIC-RECOVERY].  Specifically, the client
# MUST send an Initial packet in a UDP datagram that contains at least
# 1200 bytes if it does not have Handshake keys, and otherwise send a
# Handshake packet.
# 
# A server might wish to validate the client address before starting
# the cryptographic handshake.  QUIC uses a token in the Initial packet
# to provide address validation prior to completing the handshake.
# This token is delivered to the client during connection establishment
# with a Retry packet (see Section 8.1.2) or in a previous connection
# using the NEW_TOKEN frame (see Section 8.1.3).
# 
# In addition to sending limits imposed prior to address validation,
# servers are also constrained in what they can send by the limits set
# by the congestion controller.  Clients are only constrained by the
# congestion controller.

[[spec]]
level = "MAY"
quote = '''
Additionally, an endpoint MAY consider the peer address validated if
the peer uses a connection ID chosen by the endpoint and the
connection ID contains at least 64 bits of entropy.
'''

[[spec]]
level = "MUST"
quote = '''
Prior to validating the client address, servers MUST NOT send more
than three times as many bytes as the number of bytes they have
received.
'''

[[spec]]
level = "MUST"
quote = '''
For the purposes of
avoiding amplification prior to address validation, servers MUST
count all of the payload bytes received in datagrams that are
uniquely attributed to a single connection.
'''

[[spec]]
level = "MUST"
quote = '''
Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding PADDING frames as
necessary.
'''

[[spec]]
level = "MUST"
quote = '''
To
prevent this deadlock, clients MUST send a packet on a Probe Timeout
(PTO); see Section 6.2 of [QUIC-RECOVERY].
'''

[[spec]]
level = "MUST"
quote = '''
Specifically, the client
MUST send an Initial packet in a UDP datagram that contains at least
1200 bytes if it does not have Handshake keys, and otherwise send a
Handshake packet.
'''