Re: [quicwg/base-drafts] Adds text about server padding handshake to PMTU (#1013)

[Christian Huitema <[e-mail]>]

huitema commented on this pull request.

The current text on the "minimum enforced MTU" is contorted and spread over several paragraphs. I think the paragraph explaining that "QUIC depends on the network path supporting a MTU of at least 1280 octets" should be moved up, just after the introduction of path MTU, and before making statements such as "In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets larger than 1280 octets."

Once this is said, we can have the additional text on server handshake messages. But we need to work some more on that text. 

>  
 Servers MUST ignore an initial plaintext packet from a client if its total size
 is less than 1200 octets.
 
+Similarly, servers MUST ensure that the first handshake packet they send to
+clients, and any retransmissions of those octets, has a QUIC packet size that is
+the same as the received initial client packet, unless the server knows the PMTU
+to the client to be smaller. Sending a packet of this size ensures that the

The client side "at least 1200 byte" is justified by a security concern, but that concern does not apply to server responses. I think we need some better text, and that the justification for the padding should come after the requirement of minimum 1280 MTU. Setting a minimum size for the first handshake packet ensures that the handshake will fail if the network does not support the recommended MTU, and is only justified if we want enforce the "minimum 1280" requirement.

But if we do that, maybe we should develop the idea in a full paragraph. For example, is it OK to meet the requirement in IPv4 by setting the DF bit to "fragmentation authorized"?

>  
 Servers MUST ignore an initial plaintext packet from a client if its total size
 is less than 1200 octets.
 
+Similarly, servers MUST ensure that the first handshake packet they send to
+clients, and any retransmissions of those octets, has a QUIC packet size that is
+the same as the received initial client packet, unless the server knows the PMTU
+to the client to be smaller. Sending a packet of this size ensures that the

I am a bit skeptical about the requirement for "any retransmissions of those octets". It will be yet another special case in the handling of re-transmission. The net effect will be that servers pad all handshake message re-transmissions to 1200 bytes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1013#pullrequestreview-85431920