Draft: draft-ietf-quic-transport

Commentary: and probably fixes some others as well . Trying to address one thing wound up pulling on some other pieces as well , so this is larger than I intended . Key changes are : Added discussion of 0 - RTT Protected Packets , which were mysteriously absent , to Section 17 Moved discussion of starting packet numbers for each space from the Initial Packet definition to the existing Packet Numbers section ( 17.1 ) Moved Short Header packets to end of 17 ( from 17.3 to 17.8 ) to get all the long - header packet types together Removed the non - invariant fields (  , Packet Number , Payload ) from the definition of the Long Header and made them type - specific fields for those packets which contain them ; this reduces explanation for packet types which do n't Reordered forward references in Section 10 so the references in each paragraph are to sequential sections , with some text updates to accommodate the new order If a comparison of the output doc is more useful than the Markdown diff , try or the . 
 This adds a lot of duplicate text . Can we avoid that , so we do n't make a change in one spot and miss the other 3 spots ? 
 I think the way we would get there is to make Initial / Handshake/0 - RTT subsections of one section that defines some common fields after the long header . The " longer " header ? 
 Done -- dubbed it the " Extended Long Header . " 
 The comments in this PR discuss an " Extended Long Header " but I do n't see it in the actual diff . Was it removed ? I tried to address this in but I 'm happy to have it be fixed here with an explicit extended long header . 
 Yes -- because it 's subtly different in the different packets , I changed it to an overarching description of fields which occur in multiple packet types , but indicate which fields are present in each packet type 's section . 
 These references should be delimited with parentheses , as is done in the other paragraphs : It also seems odd that our references are to subsections ( 5 , 7 , 6 ) rather than matching the order of the actual sections , and that three of the references are to 17.x while one is to 12.1 . Can we make these a little more symmetric ? 
 PRs welcome . 
 This is not correct b / c the long header has length and PN . 
 Retry uses a long header as defined in Invariants , but does n't include the extra fields defined for the long header in v1 . Perhaps we need different names for the two long - header references , or perhaps the length / PN should be defined as part of the body of each packet type . 
 I believe  is initial(and Retry ) only?Everything looks good besides the one comment / question I had on the starting packet number . This is good . Thanks for doing the hard work here . Thanks for doing this !
Paragraph (version A):
In order to prevent a handshake deadlock as a result of the server
being unable to send, clients SHOULD send a packet upon a handshake
timeout, as described in QUIC-RECOVERY.  If the client has no data to
retransmit and does not have Handshake keys, it SHOULD send an
Initial packet in a UDP datagram of at least 1200 bytes.  If the
client has Handshake keys, it SHOULD send a Handshake packet.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame.  Tokens obtained
in Retry packets MUST NOT be discarded.
Paragraph (version A):
Path validation tests that packets can be both sent to and received
from a peer on the path.  Importantly, it validates that the packets
received from the migrating endpoint do not carry a spoofed source
address.
Paragraph (version A):
The endpoint MUST use fresh random data in every PATH_CHALLENGE frame
so that it can associate the peer's response with the causative
PATH_CHALLENGE.
Paragraph (version B):
The endpoint MUST use unpredictable data in every PATH_CHALLENGE
frame so that it can associate the peer's response with the
corresponding PATH_CHALLENGE.
Paragraph (version A):
A new address is considered valid when a PATH_RESPONSE frame is
received containing data that was sent in a previous PATH_CHALLENGE.
Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE
frame is not adequate validation, since the acknowledgment can be
spoofed by a malicious peer.
Paragraph (version A):
For path validation to be successful, a PATH_RESPONSE frame MUST be
received from the same remote address to which the corresponding
PATH_CHALLENGE was sent.  If a PATH_RESPONSE frame is received from a
different remote address than the one to which the PATH_CHALLENGE was
sent, path validation is considered to have failed, even if the data
matches that sent in the PATH_CHALLENGE.
Paragraph (version A):
Additionally, the PATH_RESPONSE frame MUST be received on the same
local address from which the corresponding PATH_CHALLENGE was sent.
An endpoint considers the path to be valid when a PATH_RESPONSE frame
is received on the same path with the same payload as the
PATH_CHALLENGE frame.
Paragraph (version A):
If a PATH_RESPONSE frame is received on a different local address
than the one from which the PATH_CHALLENGE was sent, path validation
is not considered to be successful, even if the data matches the
PATH_CHALLENGE.  This doesn't result in path validation failure, as
it might be a result of a forwarded packet (see off-path-forward) or
misrouting.
Paragraph (version A):
Endpoints SHOULD abandon path validation based on a timer.  When
setting this timer, implementations are cautioned that the new path
could have a longer round-trip time than the original.  A value of
three times the current Retransmittion Timeout (RTO) as defined in
QUIC-RECOVERY is RECOMMENDED.
Paragraph (version A):
The closing and draining connection states exist to ensure that
connections close cleanly and that delayed or reordered packets are
properly discarded.  These states SHOULD persist for three times the
current Retransmission Timeout (RTO) interval as defined in QUIC-
RECOVERY.
Paragraph (version A):
An endpoint could receive packets from a new source address,
indicating a client connection migration (migration), while in the
closing period.  An endpoint in the closing state MUST strictly limit
the number of packets it sends to this new address until the address
is validated (see migrate-validate).  A server in the closing state
MAY instead choose to discard packets received from a new source
address.
Paragraph (version A):
The value for an idle timeout can be asymmetric.  The value
advertised by an endpoint is only used to determine whether the
connection is live at that endpoint.  An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the
packets arrive.  If a peer could timeout within an RTO (see
Section 5.3.3 of QUIC-RECOVERY), it is advisable to test for liveness
before sending any data that cannot be retried safely.
Paragraph (version A):
Allowing retransmission of a packet contradicts other advice in
this document that recommends the creation of new packet numbers
for every packet.  Sending new packet numbers is primarily of
advantage to loss recovery and congestion control, which are not
expected to be relevant for a closed connection.  Retransmitting
the final packet requires less state.
Paragraph (version A):
A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header.  The remainder of the first byte
and an arbitrary number of random bytes following it are set to
unpredictable values.  The last 16 bytes of the datagram contain a
Stateless Reset Token.
Paragraph (version A):
A stateless reset will be interpreted by a recipient as a packet with
a short header.  For the packet to appear as valid, the Random Bits
field needs to include at least 182 bits of random or unpredictable
values (or 24 bytes, less the two fixed bits).  This is intended to
allow for a destination connection ID of the maximum length
permitted, with a minimal packet number, and payload.  The Stateless
Reset Token corresponds to the minimum expansion of the packet
protection AEAD.  More random bytes might be necessary if the
endpoint could have negotiated a packet protection scheme with a
larger minimum AEAD expansion.
Paragraph (version A):
The design of a Stateless Reset is such that it is indistinguishable
from a valid packet.  This means that a Stateless Reset might trigger
the sending of a Stateless Reset in response, which could lead to
infinite exchanges.
Paragraph (version B):
The design of a Stateless Reset is such that without knowing the
stateless reset token it is indistinguishable from a valid packet.
For instance, if a server sends a Stateless Reset to another server
it might receive another Stateless Reset in response, which could
lead to an infinite exchange.
Paragraph (version A):
Initial packets are protected using keys that are statically derived.
This packet protection is not effective confidentiality protection,
it only exists to ensure that the sender of the packet is on the
network path.  Any entity that receives the Initial packet from a
client can recover the keys necessary to remove packet protection or
to generate packets that will be successfully authenticated.
Paragraph (version A):
The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet
protection is applied (see QUIC-TLS for details).  The underlying
packet number increases with each packet sent, see packet-numbers for
details.
Paragraph (version A):
To limit ACK Blocks to those that have not yet been received by the
sender, the receiver SHOULD track which ACK frames have been
acknowledged by its peer.  Once an ACK frame has been acknowledged,
the packets it acknowledges SHOULD NOT be acknowledged again.
Paragraph (version B):
To limit the ranges of acknowledged packet numbers to those that have
not yet been received by the sender, the receiver SHOULD track which
ACK frames have been acknowledged by its peer.  The receiver SHOULD
exclude already acknowledged packets from future ACK frames whenever
these packets would unnecessarily contribute to the ACK frame size.
Paragraph (version A):
Data sent in CRYPTO frames is retransmitted according to the rules
in QUIC-RECOVERY, until all data has been acknowledged.
Paragraph (version A):
On receiving a QUIC packet with an ECT or CE codepoint, an endpoint
that can access the ECN codepoints from the enclosing IP packet
increases the corresponding ECT(0), ECT(1), or CE count, and includes
these counters in subsequent ACK frames (see processing-and-ack and
frame-ack).
Paragraph (version A):
If an endpoint receives a QUIC packet without an ECT or CE codepoint
in the IP packet header, it responds per processing-and-ack with an
ACK frame without increasing any ECN counters.  Similarly, if an
endpoint does not have access to received ECN codepoints, it does not
increase ECN counters.
Paragraph (version A):
Each packet number space maintains separate acknowledgement state and
separate ECN counters.  For example, if one each of an Initial,
0-RTT, Handshake, and 1-RTT QUIC packet are coalesced, the
corresponding counters for the Initial and Handshake packet number
space will be incremented by one and the counters for the 1-RTT
packet number space will be increased by two.
Paragraph (version A):
The increase in ECT(0) and ECT(1) counters MUST be at least the
number of QUIC packets newly acknowledged that were sent with the
corresponding codepoint minus the increase in the CE counter.
This detects network remarking between ECT(0) and ECT(1).
Paragraph (version A):
The total increase in ECT(0), ECT(1), and CE counters reported in
the ACK frame MUST be at least the total number of QUIC packets
newly acknowledged in this ACK frame.  This detects if the network
changes ECT(0), ECT(1) or CE to Not-ECT.
Paragraph (version A):
This validation is only performed if the ACK frame increases the
largest received packet number.  Reordered acknowledgments could have
lower counter values and might not be successfully validated as a
result.
Paragraph (version A):
These counts might be inflated if acknowledgments are never received
for packets that were successfully delivered.  If validation
succeeds, an endpoint MUST increase its expected counter values to
those it receives.
Paragraph (version A):
An endpoint could miss acknowledgements for a packet when ACK frames
are lost.  It is therefore possible for the total increase in ECT(0),
ECT(1), and CE counters to be greater than the number of packets
acknowledged in an ACK frame.  When this happens, the local reference
counts MUST be increased to match the counters in the ACK frame.
Paragraph (version A):
If an endpoint sets ECT codepoints on outgoing IP packets and
encounters a retransmission timeout due to the absence of
acknowledgments from the peer (see QUIC-RECOVERY), or if an endpoint
has reason to believe that an element on the network path might be
corrupting ECN codepoints, the endpoint MAY cease setting ECT
codepoints in subsequent packets.  Doing so allows the connection to
traverse network elements that drop IP packets with ECT or CE
markings or corrupt ECN codepoints in the IP header.
Paragraph (version A):
Clients MUST ensure they send the first Initial packet in a UDP
datagram that is at least 1200 bytes.  The payload of a UDP datagram
carrying the Initial packet MUST be expanded to at least 1200 bytes,
by adding PADDING frames to the Initial packet and/or by combining
the Initial packet with a 0-RTT packet (see packet-coalesce).
Sending a UDP datagram of this size ensures that the network path
supports a reasonable Maximum Transmission Unit (MTU), and helps
reduce the amplitude of amplification attacks caused by server
responses toward an unverified client address, see address-
validation.
Paragraph (version A):
If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below the size needed to support
the smallest allowed maximum packet size, it MUST immediately cease
sending QUIC packets on the affected path.  An endpoint MAY terminate
the connection if an alternative path cannot be found.
Paragraph (version A):
PMTU discovery RFC1191 RFC8201 relies on reception of ICMP messages
(e.g., IPv6 Packet Too Big messages) that indicate when a packet is
dropped because it is larger than the local router MTU.  DPLPMTUD can
also optionally use these messages.  This use of ICMP messages is
potentially vulnerable to off-path attacks that successfully guess
the IP address 3-tuple and reduce the PMTU to a bandwidth-inefficient
value.
Paragraph (version A):
QUIC endpoints SHOULD provide validation to protect from off-path
injection of ICMP messages as specified in RFC8201 and Section 5.2 of
RFC8085.  This uses the quoted packet supplied in the payload of an
ICMP message, which, when present, can be used to associate the
message with a corresponding transport connection DPLPMTUD.
Paragraph (version A):
When a randomized source port is used for a QUIC connection, this can
provide some protection from off path attacks that forge ICMP
messages.  The source port in a quoted packet can be checked for UDP
transports RFC8085 such as QUIC.  When used, a stack will only pass
ICMP messages to a QUIC endpoint where the port information in quoted
packet within the ICMP payload matches a port used by QUIC.
Paragraph (version A):
As a part of ICMP validation, QUIC endpoints SHOULD validate that
connection ID information corresponds to an active session.
Paragraph (version A):
The endpoint SHOULD ignore all ICMP messages that are not validated
or do not carry sufficient quoted packet payload to perform
validation.  Any reduction in the QUIC maximum packet size MAY be
provisional until QUIC's loss detection algorithm determines that the
quoted packet has actually been lost.
Paragraph (version A):
The first Initial packet sent by either endpoint contains a packet
number of 0.  The packet number MUST increase monotonically
thereafter.  Initial packets are in a different packet number space
to other packets (see packet-numbers).
Paragraph (version B):
Any data in CRYPTO frames is discarded - and no longer retransmitted
- when Initial keys are discarded.
Paragraph (version A):
The first Handshake packet sent by a server contains a packet number
of 0.  Handshake packets are their own packet number space.  Packet
numbers are incremented normally for other Handshake packets.
Paragraph (version B):
Handshake packets are their own packet number space, and thus the
first Handshake packet sent by a server contains a packet number of
0.
Paragraph (version A):
If the client received and processed a Retry packet, it validates
that the original_connection_id transport parameter is present and
correct; otherwise, it validates that the transport parameter is
absent.  A client MUST treat a failed validation as a connection
error of type TRANSPORT_PARAMETER_ERROR.
Paragraph (version A):
Receivers send ACK frames (types 0x02 and 0x03) to inform senders of
packets they have received and processed.  The ACK frame contains one
or more ACK Blocks.  ACK Blocks are ranges of acknowledged packets.
If the frame type is 0x03, ACK frames also contain the sum of QUIC
packets with associated ECN marks received on the connection up until
this point.
Paragraph (version A):
The ACK frame uses the least significant bit (that is, type 0x03) to
indicate ECN feedback and report receipt of QUIC packets with
associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP
header.
Paragraph (version A):
The ECN section should only be parsed when the ACK frame type is
0x03.  The ECN section consists of 3 ECN counters as shown below.
Paragraph (version B):
A variable-length integer indicating the number of contiguous
packets preceding the Largest Acknowledged that are being
acknowledged.  The First ACK Range is encoded as an ACK Range (see
ack-ranges) starting from the Largest Acknowledged.  That is, the
smallest packet number included in the range is determined by
subtracting the First ACK Range value from the Largest
Acknowledged.
Paragraph (version B):
Contains additional ranges of packet numbers which are alternately
not acknowledged (Gap) and acknowledged (ACK Range), see ack-
ranges.
Paragraph (version B):
An ACK Range acknowledges all packet numbers between the smallest
packet number and the largest, inclusive.
Paragraph (version A):
ECN counters are maintained separately for each packet number space.
Paragraph (version B):
ECN counts are maintained separately for each packet number space.
Paragraph (version A):
A server sends a NEW_TOKEN frame (type=0x07) to provide the client a
token to send in the header of an Initial packet for a future
connection.
Paragraph (version B):
A server sends a NEW_TOKEN frame (type=0x07) to provide the client
with a token to send in the header of an Initial packet for a future
connection.
Paragraph (version A):
The first byte in the stream has an offset of 0.  The largest offset
delivered on a stream - the sum of the re-constructed offset and data
length - MUST be less than 2^62.
Paragraph (version A):
A variable-length integer specifying the length of the reason
phrase in bytes.  Note that a CONNECTION_CLOSE frame cannot be
split between packets, so in practice any limits on packet size
will also limit the space available for a reason phrase.
Paragraph (version B):
A variable-length integer specifying the length of the reason
phrase in bytes.  Because a CONNECTION_CLOSE frame cannot be split
between packets, any limits on packet size will also limit the
space available for a reason phrase.