target = "https://www.rfc-editor.org/rfc/rfc9000#section-17.2.2" # 17.2.2. Initial Packet # # An Initial packet uses long headers with a type value of 0x00. It # carries the first CRYPTO frames sent by the client and server to # perform key exchange, and it carries ACK frames in either direction. # # Initial Packet { # Header Form (1) = 1, # Fixed Bit (1) = 1, # Long Packet Type (2) = 0, # Reserved Bits (2), # Packet Number Length (2), # Version (32), # Destination Connection ID Length (8), # Destination Connection ID (0..160), # Source Connection ID Length (8), # Source Connection ID (0..160), # Token Length (i), # Token (..), # Length (i), # Packet Number (8..32), # Packet Payload (8..), # } # # Figure 15: Initial Packet # # The Initial packet contains a long header as well as the Length and # Packet Number fields; see Section 17.2. The first byte contains the # Reserved and Packet Number Length bits; see also Section 17.2. # Between the Source Connection ID and Length fields, there are two # additional fields specific to the Initial packet. # # Token Length: A variable-length integer specifying the length of the # Token field, in bytes. This value is 0 if no token is present. # Initial packets sent by the server MUST set the Token Length field # to 0; clients that receive an Initial packet with a non-zero Token # Length field MUST either discard the packet or generate a # connection error of type PROTOCOL_VIOLATION. # # Token: The value of the token that was previously provided in a # Retry packet or NEW_TOKEN frame; see Section 8.1. # # In order to prevent tampering by version-unaware middleboxes, Initial # packets are protected with connection- and version-specific keys # (Initial keys) as described in [QUIC-TLS]. This protection does not # provide confidentiality or integrity against attackers that can # observe packets, but it does prevent attackers that cannot observe # packets from spoofing Initial packets. # # The client and server use the Initial packet type for any packet that # contains an initial cryptographic handshake message. This includes # all cases where a new packet containing the initial cryptographic # message needs to be created, such as the packets sent after receiving # a Retry packet; see Section 17.2.5. # # A server sends its first Initial packet in response to a client # Initial. A server MAY send multiple Initial packets. The # cryptographic key exchange could require multiple round trips or # retransmissions of this data. # # The payload of an Initial packet includes a CRYPTO frame (or frames) # containing a cryptographic handshake message, ACK frames, or both. # PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also # permitted. An endpoint that receives an Initial packet containing # other frames can either discard the packet as spurious or treat it as # a connection error. # # The first packet sent by a client always includes a CRYPTO frame that # contains the start or all of the first cryptographic handshake # message. The first CRYPTO frame sent always begins at an offset of # 0; see Section 7. # # Note that if the server sends a TLS HelloRetryRequest (see # Section 4.7 of [QUIC-TLS]), the client will send another series of # Initial packets. These Initial packets will continue the # cryptographic handshake and will contain CRYPTO frames starting at an # offset matching the size of the CRYPTO frames sent in the first # flight of Initial packets. [[spec]] level = "MUST" quote = ''' Initial packets sent by the server MUST set the Token Length field to 0; clients that receive an Initial packet with a non-zero Token Length field MUST either discard the packet or generate a connection error of type PROTOCOL_VIOLATION. ''' [[spec]] level = "MUST" quote = ''' Initial packets sent by the server MUST set the Token Length field to 0; clients that receive an Initial packet with a non-zero Token Length field MUST either discard the packet or generate a connection error of type PROTOCOL_VIOLATION. ''' [[spec]] level = "MAY" quote = ''' A server MAY send multiple Initial packets. '''