Transport parameter "original connection ID" if no retry

[huitema]

The transport spec says in section "6.6.1. Transport Parameter Definitions" that "A server MUST include the original_connection_id transport parameter if it sent a Retry packet". It does not say what is the expected behavior if the server did not send a retry packet. There are two possible interpretations:

1. The client MUST ignore the original_connection_id parameter if it did not receive a retry packet; or,

2. The client MAY send terminate the connection with a TRANSPORT_PARAMETER_ERROR if it receive this parameter but did not receive a retry packet.

What would be the preferred behavior?

[janaiyengar]

Or a third way, which is my preferred way: the client MUST terminate the connection with a TRANSPORT_PARAMETER_ERROR if it receive this parameter but did not receive a retry packet.

[hardie]

On Fri, Oct 12, 2018 at 12:34 PM janaiyengar ***@***.***> wrote: Or a third way, which is my preferred way: the client MUST terminate the connection with a TRANSPORT_PARAMETER_ERROR if it receive this parameter but did not receive a retry packet. Section 4.4 says:

A server MAY send Retry packets in response to Initial and 0-RTT packets. A server can either discard or buffer 0-RTT packets that it receives. A server can send multiple Retry packets as it receives Initial or 0-RTT packets. This seems to acknowledge that it may take time and multiple attempts to get a retry packet through. I think that's a conflict with making this MUST as the decision on when to declare that it had not received a retry packet would still be client-driven. Ted

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1855 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVb5I-FNEoC9ptKAnwXXwGzJvkJl1v0ks5ukO7FgaJpZM4XZ883> .

[martinthomson]

The point here is that a client will know whether it responded to a Retry. The server should also know, because it has a token in the Initial packet from the server (that it should be able to identify as being from a Retry packet that it sent).

With that in mind, even if the server receives multiple packets and only sends Retry in response to some of them, the transport parameters that the server sends will always be sent with very clear knowledge about what is being responded to.

BTW, I thought that I had answered this question:

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.

-- https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#packet-retry

[janaiyengar]

Huh. @martinthomson: I thought so too, but I obviously seem to have missed reading the part saying "otherwise, it validates that the transport parameter is absent". I agree that this is addressed.

[janaiyengar]

I'll close this issue, since it seems that the original issue is in fact addressed. Open again if you disagree or want to see something else done.