Improving TCP's Robustness to Blind In-Window Attacks
Note: This ballot was opened for revision 13 and is now closed.
(Lars Eggert) (was Discuss, Yes) Yes
(Ron Bonica) No Objection
Comment (2009-10-06 for -** No value found for 'p.get_dochistory.rev' **)
I don't think that UPDATES is required because an implementer can produce a perfectly compliant implementation without ever reading this document.
(Ross Callon) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
Comment (2009-10-07 for -** No value found for 'p.get_dochistory.rev' **)
This document is well written and clearly explains, without needing to flip back to RFC 793 and other docs, the attacks and the mitigations. Whether or not this document updates RFC 793 depends, in my mind, on the meaning of SHOULD in text like this snippet from section 4.2: Instead, the handling of the SYN in the synchronized state SHOULD be performed as follows: 1) If the SYN bit is set, irrespective of the sequence number, TCP MUST send an ACK (also referred to as challenge ACK) to the remote peer: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> After sending the acknowledgment, TCP MUST drop the unacceptable segment and stop processing further. Does the SHOULD imply a change in TCP as defined by RFC 793 or does it apply in the sense of "if the stack implemements the mitigations described in this document, the handling of SYN ..." I infer from this text in the "Applicability Statement" (section 1.1), that RFC 2119 text is all conditional on "if the stack implements these mitigations": The mitigations suggested in this draft SHOULD be implemented in devices that regularly need to maintain TCP connections of the kind most vulnerable to the attacks described in this document. While this may seem like an editorial nit, I think the doc would be clarified and the issue of updating RFC 793 resolved with an explicit statement about the RFC 2119 text in the Terminology section. --- In section 5.1, what is the "ACK value of [a] data segment"? --- This text at the beginning of section 5.2 doesn't seem to appear anywhere in sections 3 or 4: 5.2. Mitigation All TCP stacks MAY implement the following mitigation. Is there something different about the mitigation in section 5 that is different from the other mitigations? I see section 6 clarifies the issue I was getting at: 6. Suggested Mitigation strengths As described in the above sections, recommendation levels for RST, SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively. At the risk of fussiness over an editorial nit, I suggest a clear sentence at the beginning of sections 3.2 and 4.2 like the one in section 5.2 explicitly describing the recommendation levels for those mitigations.