Noritoshi-
> > The original specification of the timestamp option [5] may contain some
> > flaws. An update specification [B93] provides the necessary fixes.
Ideas in
> > this expired draft appear in all current implementations of [5].
.....
> Since Linux is used widely, is it better to replace
> the word "all" to something like "many" or "some" ?
You are very right here. In fact, after discussing with Alexey Kuznetsov
(Linux TCP/IP implementer) and Reiner the issue about this update became
more controversial. According to Alexey, older Linux versions implemented
the update, but the kernel was reverted back to rfc1323 in version 2.4. The
reason is vulnerability to spoofing attacks since this update allows
changing TCP state by out-of-window segments. Also, we concluded with Reiner
that the 'failure case' for Eifel caused by echoing of old timestamps is in
fact a good thing. Hence, I'm more thinking in favor of the original rfc1323
at the moment. Because of that I suggest some neutral text that replaces the
quote above.
--- The original definition of the timestamp option [5] specifies that duplicate segments below cumulative ACK do not update the cached timestamp value at the receiver. This may lead to overestimating of RTT for retransmitted segments. A possible solution [B93] allows the receiver to use a more recent timestamp from a duplicate segment. However, this suggestion allows for spoofing attacks at the TCP receiver. Therefore, careful consideration is needed in implementing this solution. ---rgds, Andrei
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:28 EST