Where can you send CONNECTION_CLOSE

[ekr]

If the connection has been successfully established, endpoints MUST send any
CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a
peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
in a Handshake packet.  If the endpoint does not have Handshake keys, or it is
not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE
frames in an Initial packet.  If multiple packets are sent, they can be
coalesced (see {{packet-coalesce}}) to facilitate retransmission.

Isn't the rule here that you always send it in the highest level?

[martinthomson]

The intent is for the peer to be able to read the packet, thus the recommendation to use a lower level if you aren't sure that they have the right keys. If they have the right keys, then they will ignore the Initial packet, if they don't then it's better to signal the error than have them keep trying.

I think that this is OK. Do you have a specific concern with this design? Or the specific text?

[ekr]

I'm not sure. It seems like there are two policies:

• Always use level N until you are sure that the other side has level N+1
• Always use the highest level.

I take you to be proposing the first of these, which, I believe, means "use the highest level where you have received packets from the peer in (or zero)". This text may say that, but all this stuff about certain is kind of hard to parse. Rather than making people reason it out, I think we should provide them with a clear rule (for instance the one above).

[mikkelfj]

An endpoint could logically migrate to the next packet number space / encryption level for new transmissions while still keeping the previous level for retransmissions. If the connection dies before retransmission the peer might not be able to read latest crypto level even if this is where you normally send new data. It is easier and safer to send CLOSE on both channels rather than retransmitting the handshake history.

[martinthomson]

I will await a PR then.

[huitema]

I had to fix a bug in which Picoquic was sending a connection close in handshake while the peer would not have the handshake key when receiving the message...
private-octopus/picoquic#485

[martinthomson]

Tokyo conclusion: the principle here is that we want to use the highest level we know the peer to be able to read. Reassign to editorial to a) include this principle, and b) make the text clearer.

[janaiyengar]

@mnot @larseggert : This issue is marked editorial, but it's borderline design. The PR that fixes it (#2688) introduces 2119 language and behavior that is new. I'll remove the editorial tag, but I'm not marking it as design. Can you advise on what to do next?

[mnot]

Will triage as design. Thanks.

[mnot]

@martinthomson ?

[martinthomson]

Yes? The proposal is to close with no action on the basis of text already incorporated in #2688.

[mnot]

There wasn't a consensus call. Will do one next round.

[martinthomson]

Fixed by #2688.