The following errata report has been verified for RFC9000, "QUIC: A UDP-Based Multiplexed and Secure Transport".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7861 -------------------------------------- Status: Verified Type: Technical Reported by: Mike Bishop <[email protected]> Date Reported: 2024-03-20 Verified by: Zaheduzzaman Sarker (IESG) Section: 8.1.2 Original Text ------------- If a server receives a client Initial that contains an invalid Retry token but is otherwise valid, Corrected Text -------------- If a server receives a client Initial that contains a token that is identifiable as a Retry token, but the token is invalid or does not otherwise validate the client's address, Notes ----- Valid tokens MUST be a) integrity-protected (Section 8.1.4) and distinguishable as to purpose (Section 8.1.1), i.e. tokens from a Retry packet vs. tokens from NEW_TOKEN frames. To satisfy address validation, they should enable the server to verify the client's transport address. This text does not specify which form of invalidity is being discussed -- failure of integrity protection or a mismatch between the contents of the token and the client's address. Applying this text to all "invalid" tokens which appear to be Retry tokens does not allow for the scenario where the token was generated by another server / another QUIC implementation and is in fact unreadable. Such tokens, even if they appear to be Retry tokens, are supposed to be handled by the requirements in 8.1.3, i.e. ignore the token and handle the packet as if no token were present. This section should be scoped only to tokens which are correctly formatted and readable by the server, but whose contents are not sufficient to prove the client's transport address is valid. Otherwise, the determination that the token is a Retry token cannot be trusted. (This discrepancy appears in a multi-CDN context, where tokens generated by one CDN will sometimes be received by a different CDN; if these tokens appear to be "invalid Retry tokens", the connection is closed when the token should simply be ignored.) Also see the discusion here (https://mailarchive.ietf.org/arch/msg/quic/-NcqDysNsU7mSXhKdCdM63MLYOc/) -------------------------------------- RFC9000 (draft-ietf-quic-transport-34) -------------------------------------- Title : QUIC: A UDP-Based Multiplexed and Secure Transport Publication Date : May 2021 Author(s) : J. Iyengar, Ed., M. Thomson, Ed. Category : PROPOSED STANDARD Source : QUIC Stream : IETF Verifying Party : IESG
