Amplification limit in recovery #1862
Conversation
Follow up for Issue #1764
draft-ietf-quic-recovery.md
Outdated
| CRYPTO data if possible. | ||
|
|
||
| Until the server has confirmed the path, it must not send more than 3 | ||
| times the number of received bytes, as specified in the {{QUIC-TRANSPORT}}. |
There was a problem hiding this comment.
Is this MUST NOT? You might avoid duplicating the requirement by saying that the server is limited in the amount of data it can send, as specified in {{QUIC-TRANSPORT}}.
draft-ietf-quic-recovery.md
Outdated
|
|
||
| On each consecutive expiration of the crypto timer without receiving an | ||
| acknowledgement for a new packet, the sender SHOULD double the crypto | ||
| handshake timeout and set a timer for this period. |
There was a problem hiding this comment.
The timeouts are still inconsistently named. We have "crypto handshake timeout" here, but "crypto timeout" on 321/322. I think that "crypto retransmission timeout " is most correct. You should fix the section title as well.
|
|
||
| The TLP and RTO timers are armed when there are no unacknowledged crypto | ||
| packets. The TLP timer is set until the max number of TLP packets have been | ||
| sent, and then the RTO timer is set. |
There was a problem hiding this comment.
Did you mean to delete all of this?
There was a problem hiding this comment.
Yes, I believe it's duplicative of the more detailed text above.
There was a problem hiding this comment.
OK. It seemed entirely unrelated, but I see we have text on both elsewhere.
MikeBishop
added
design
draft-ietf-quic-recovery.md
Outdated
| CRYPTO data if possible. | ||
|
|
||
| Until the server has validated the client's address on the path, the number of | ||
| bytes it can send is limited, as specified in the {{QUIC-TRANSPORT}}. |
draft-ietf-quic-recovery.md
Outdated
| Until the server has validated the client's address on the path, the number of | ||
| bytes it can send is limited, as specified in the {{QUIC-TRANSPORT}}. | ||
| If not all unacknowledged CRYPTO data can be sent, then all CRYPTO data in | ||
| Initial encryption should be retransmitted. If no bytes may be sent, |
There was a problem hiding this comment.
Should this be "in the Initial encryption level" or "in Initial packets"?
There was a problem hiding this comment.
Hmm, probably Initial packets.
draft-ietf-quic-recovery.md
Outdated
|
|
||
| Until the server has validated the client's address on the path, the number of | ||
| bytes it can send is limited, as specified in {{QUIC-TRANSPORT}}. | ||
| If not all unacknowledged CRYPTO data can be sent, then all CRYPTO data sent |
There was a problem hiding this comment.
"then all unacknowledged CRYPTO data sent"
Co-Authored-By: ianswett <ianswett@google.com>
| @@ -318,12 +318,27 @@ is available, or if the network changes, the initial RTT SHOULD be set to 100ms. | |||
| When an acknowledgement is received, a new RTT is computed and the timer | |||
| SHOULD be set for twice the newly computed smoothed RTT. | |||
|
|
|||
| When crypto packets are sent, the sender SHOULD set a timer for the crypto | |||
| When crypto packets are sent, the sender MUST set a timer for the crypto | |||
| timeout period. Upon timeout, the sender MUST retransmit all unacknowledged | |||
There was a problem hiding this comment.
| timeout period. Upon timeout, the sender MUST retransmit all unacknowledged | |
| retransmission interval. Upon timeout, the sender MUST retransmit all unacknowledged |
There was a problem hiding this comment.
This doc uses timeout and timeout period fairly consistently, so I'd like to keep it as is.
|
|
||
| Until the server has validated the client's address on the path, the number of | ||
| bytes it can send is limited, as specified in {{QUIC-TRANSPORT}}. | ||
| If not all unacknowledged CRYPTO data can be sent, then all unacknowledged |
There was a problem hiding this comment.
I think that you mean to say instead
If all CRYPTO data is acknowledged, and there is nothing for the client to send, then it sends another Initial packet.
What that packet contains clearly doesn't matter (though an ACK would be perfectly OK, as would repeating information that the server already has), so I don't think we need to stipulate that explicitly. Otherwise, this is a little ambiguous - and maybe in conflict with what we did in #1843 and the next paragraph.
There was a problem hiding this comment.
This paragraph talks about the server's behavior, not the client's?
|
|
||
| The TLP and RTO timers are armed when there are no unacknowledged crypto | ||
| packets. The TLP timer is set until the max number of TLP packets have been | ||
| sent, and then the RTO timer is set. |
There was a problem hiding this comment.
OK. It seemed entirely unrelated, but I see we have text on both elsewhere.
|
With these MUST retransmit, has it been considered what a Slowloris attack could do to the handshake? I know that there is a general mention in some section. |
Co-Authored-By: ianswett <ianswett@google.com>
Co-Authored-By: ianswett <ianswett@google.com>
|
@mikkelfj The slowloris attack is against a server, but the peer that must retransmit is the client in this case, so I don't think this particular text is relevant to slowloris? |
|
I got the same thought after writing it, but I suspected the logic could be similar server side - I'm not sufficiently into that handshake details atm. |
Follow up for Issue #1764
Also fixes some remaining inconsistencies from #1859