[e2e] Stupid Question: Why are missing ACKs not considered as indicator for congestion?
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:
>>>> 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
Sr. Network Engineer, USAF TSAT Space Segment
-------------- next part --------------
A non-text attachment was scrubbed...
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