Folks, Some last call comments: * The document never mentions the fact that this document is IPR-encumbered. As far as I recall, much of the dicussion within tcpm with respect to the level of requirements of this document (MAY/SHOULD/MUST, etc.) had to do with this fact. I believe the document should include a warning mentioning that there's an IPR on the document, so that implementers can consider this point in their decision of whether to implement the described mechanisms or not. * The document discusses blind attacks, and to some extent assesses the difficulty in guessing the four-tuple that identifies a TCP connection. However, it does not even mention port randomization, which is probably the most simple and straightforward approach for mitigating blind attacks against TCP. This was raised by me and other quite a few times in the tcpm wg list, pre and post wglc, but this comment was never addressed. It's particularly curious that port randomization is not mentioned when tsvwg is working on it (draft-ietf-tsvwg-port-randomization). * Among the factors that determine how easy these attacks be exploited is the window size. This document should provide, at the very least, pointers with advice on what to do with the tcp window. While quickly skimming through RFC 4953, it seems it has some advice on the TCP window. We do offer a lengthy discussion of this and other issues in draft-gont-tcp-security and http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf * Yet another factor is TCP ISN randomization. At the very least, this document could/should a pointer to RFC 1948. We do offer a lengthy discussion of this and other issues in draft-gont-tcp-security and http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf * Just of the top of my head: Hadn't the BGP spec been updated so that a well-known port was not required as the *source* port? * The counter-measure of for the SYN-based reset attack may have missed a common heuristics for the handling of SYN segments. See pages 86 and 87 of the UK CPNI paper on TCP security. FWIW, we argue that the processing of SYN segments proposed in [Ramaiah et al, 2008] should apply only for connections in any of the synchronized states other than the TIME-WAIT state. * When it comes to TCP-based blind-connection reset attacks, there's a much more trivial -- yet not discussed before? -- alternative. See Section 11.1.3 and Section 11.1.4 in draft-gont-tcp-security and the CPNI paper (http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf). These variants should, at the very least, be mentioned and a pointer provided to them as, at least in theory, are much easier to exploit. * When it comes to the data injection attack, Michael Zalewski sketched another attack vector which may be easier to exploit. We discuss it in Section 16.2 of draft-gont-tcp-security and the CPNI doc, along with advice. IMO, this vector should be mentioned, too. Needless to say, I'm in favor of improving the robustness of TCP and, IPRs-aside, I'm happy with the implementation of the counter-measures described in the tcpsecure I-D (all three). I'm also glad that this doc is getting close to publication. Five years working on a document is quite a lot of time! (yes, it could have been worse, some might argue). Thanks! Kind regards, Fernando Gont The IESG wrote: > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > > - 'Improving TCP's Robustness to Blind In-Window Attacks ' > <draft-ietf-tcpm-tcpsecure-11.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2009-04-16. Exceptionally, > comments may be sent to iesg@xxxxxxxx instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11735&rfc_flag=0 > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/421/ > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce > -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf