[e2e] Stupid Question: Why are missing ACKs not considered as indicator for congestion?

Joe Touch touch at ISI.EDU
Thu Feb 1 09:53:14 PST 2007



Lloyd Wood wrote:
> At Thursday 01/02/2007 06:05 -0800, Joe Touch wrote:
> 
>> Lloyd Wood wrote:
>>> At Wednesday 31/01/2007 16:02 -0500, Sushant Rewaskar wrote:
>>>> Hi,
>>>> I agree with Lachlan. In TCP there is no way to know when an ack is lost as
>>>> it carries no "sequence number" of its own. 
>>> It can - timestamps are used for disambiguation, and they
>>> disambiguate the acks. They can act as unique sequence numbers.
>> How so? RFC 1323, Sec 4.2.2:
>>
>> "Based upon these considerations, we choose a timestamp clock
>>         frequency in the range 1 ms to 1 sec per tick.  "
>>
>> That suggests that timestamps need not be unique by themselves.
> 
> Any implementer would be stupid to actually follow RFC1323 and send
> actual timestamp values in the packet - that's a massive DoS hole just
> waiting to be exploited.
>
> Instead (as I mentioned previously in this thread), the sender would
> have a table of timestamps and associated unique keys for each packet
> sent out. You'd send the key in a packet, and on receiving the same key
> reflected back you'd do a match and lookup. This closes the DoS hole -
> matching a specific key value exactly is much harder than just faking a
> timestamp value to lead to spurious RTT estimates, and not giving away
> internal timestamp values also prevents the kind of
> how-long-as-this-box-been-up profiling done by e.g. Netcraft.

Time is NOT a key.

If I can spoof ACKs, there are a lot of other DoS holes around. This one
is esoteric at best.

>> The timestamps don't have to be unique. The keys to the timestamp
>> values do.

Only if you spec them that way - as keys.

>> This code is probably more straightforward to implement than, oh,
>> SACK scoreboarding.

Can we please stop trying to use everything except authentication for
authentication?

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070201/940f7187/signature-0001.bin


More information about the end2end-interest mailing list