Hi Rifaat, thank you for your review. > Reviewer: Rifaat Shekh-Yusef > Review result: Ready > > 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 one comment > > The security considerations section describes two potential recovery mechanisms > to an injection attack. The first option is to close the TCP connection and let > the originator recreate it. The second option is a re-sync mechanism. The way I > read the document, it seems that the first option is the recommended one, but > it is not clear to me when should the second option be used, if at all. It > would be great if some text be added to clarify this. Yes, the first option is preferred, since it is simple and provides deterministic result. The drawback of the first option is that the performance will degrade (current TCP connection should be closed, then the TCP originator will detect it and create a new TCP connection, that will slow start etc.) The second option is an alternative approach that implementations may try to use to avoid performance degradation. However, this approach is unreliable, especially in situation when attacker injects garbage and the TCP responder will waste resources trying to find the next valid packet which doesn't exist. For this reason this option is MAY. We can change the beginning of this this para as follows: To avoid performance degradation caused by closing and re-creating TCP connection, implementations MAY alternatively try to re-sync after they receive unknown SPIs by searching the TCP stream for a 64-bit binary vector ... Is it OK? Regards, Valery. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
