Hi Valery, Yes, the suggested text looks good to me.
Thanks, Rifaat On Thu, Aug 4, 2022 at 10:00 AM Valery Smyslov <s...@elvis.ru> wrote: > 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. > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
