On Wed, Aug 01, 2007 at 11:01:21AM +0200, Michael Tuexen wrote: > Hi Wei, > > see my comments in-line. > > Best regards > Michael > ><snip > > >(*1) At this point ctsn_ack_point=0,next_tsn=2, ctsn=1, SACK is > >accept. > >After accept SACK, ctsn_ack_point=1. > >(*2) At this point ctsn_ack_point=1,next_tsn=6, ctsn=5,TSN_lt(ctsn, > >ctsn_ack_point) is ture, so accept SACK, and then ctsn_ack_point=5 > >(*3) At this point SACK is a dup SACK, ctsn_ack_point=5,next_tsn=6, > >ctsn=1000,TSN_lt(ctsn, ctsn_ack_point) is ture, so accept SACK, and > >then > >ctsn_ack_point=1000 > I would not consider it a duplicate SACK. RFC 4460, section 2.37.2 says > that an implementation SHOULD abort the association when receiving a > SACK acknowledging unsent data. So I would suggest to send an ABORT > chunk.
+1. I didn't notice the ctsn value before. We can't safely accept that a peer pre-acks data we haven't sent. Too many security holes. Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
