What if the packet number of a retry packet is not zero?

[huitema]

The draft-12 spec says:

   The Packet Number field of a Retry packet MUST be set to 0.  This
   value is subsequently protected as normal.  [[Editor's Note: This
   isn't ideal, because it creates a "cheat" where the client assumes a
   value.  That's a problem, so I'm tempted to suggest that this include
   any value less than 2^30 so that normal processing works - and can be
   properly exercised.]]

I understand the requirement on the sender side, but what about receivers? Does it mean that the number is ignored by receivers, or that packets with non-zero numbers are just dropped on the floor, or that this is treated like a protocol error and a connection close is sent? Oh, wait, this is a retry packet, the sender side connection is already closed!

Of course, if the receivers do not somehow enforce the requirement, broken senders will have no incentive to fix their code. But then, if receivers do enforce the requirement by dropping the packet, they will end up repeating the Client Hello 4 times, receive an incorrect retry each time, ignore it, and finally release the connection after the last timer elapsed. Not ideal either.

My proposal would be to add text. "Clients who receive an otherwise valid Retry packet with a non-zero PN value should treat this as a protocol error and immediately terminate the connection."

[mikkelfj]

Since the sender can’t be trusted it is better to drop the packet. The non-zero value is theoretical and therefore most likely abuse.

[martinthomson]

This should go away with #1498 - Retry won't have a packet number.