> 7.5.4. Handling Sequence-Invalid Packets > > o A sequence-invalid DCCP-Reset packet MUST elicit a DCCP-Sync > packet in response (subject to a possible rate limit). This > response packet MUST use a new Sequence Number, and thus will > increase GSS; GSR will not change, however, since the received > packet was sequence-invalid. The response packet's > Acknowledgement Number MUST equal GSR. > > But reponse to a sequence-invalid DCCP-Reset with acknowledgement > number equal to GSR will help to attack for sequence number. The > attack method as the following: > > Endpoint A Endpoint B > (OPEN) > Dccp-Request ----------------> > (SEQ=X) > <---------------- SYNC > (SEQ=GSS+1, ACK=X) > Dccp-Reset ----------------> > (SEQ=X+1, ACK=GSS+1) > <---------------- SYNC > (SEQ=GSS+2, ACK=GSR) > > X = invalid sequence number > GSS = sequence number of endpoint B > GSR = sequence number of endpoint A > The requiremement of using GSR here is related to fixing another bug which leads to a flood of Sync/Reset packets. A description of that bug is on http://www.mail-archive.com/dccp@xxxxxxxxxxxxxxx/msg01594.html -- To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
