Last Call Review of draft-ietf-quic-recovery-32
review-ietf-quic-recovery-32-secdir-lc-piper-2020-11-02-00
Request | Review of | draft-ietf-quic-recovery |
---|---|---|
Requested revision | No specific revision (document currently at 34) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2020-11-16 | |
Requested | 2020-10-21 | |
Authors | Jana Iyengar , Ian Swett | |
I-D last updated | 2020-11-02 | |
Completed reviews |
Genart Last Call review of -32
by Vijay K. Gurbani
(diff)
Secdir Last Call review of -32 by Derrell Piper (diff) |
|
Assignment | Reviewer | Derrell Piper |
State | Completed | |
Request | Last Call review on draft-ietf-quic-recovery by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/RqyG2o24GbkCTXx09optaCq3Lyk | |
Reviewed revision | 32 (document currently at 34) | |
Result | Ready | |
Completed | 2020-11-02 |
review-ietf-quic-recovery-32-secdir-lc-piper-2020-11-02-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Ready, with an optional nit. This document is QUIC's Loss Detection and Congestion Control and is part of QUIC Last Call. Pp. 7, "after the epoch starts is acknowledged" should maybe be singular, unless the intent is literal and I'm missing what a "starts" is. There's no explicit security going on here, other than in the larger picture of QUIC itself, namely that in QUIC-TLS and QUIC-TRANSPORT; this is only its congestion control. However, Security Considerations correctly highlights some of the major traffic analysis concerns with QUIC and congestion control in general, and there are some, but these are not unique to QUIC, nor would they likely be addressed inside of congestion control, so this is okay. It seems well written and based on a practical understanding of existing TCP congestion control along with current academic research on this topic. Derrell