Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-timestamp-negotiation-02.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 1 Jun 2011 12:33:27 +0100

Hi Joe,

> 
> > If the receiver determines that a sender compliant to this draft is
> > negotiating, the<SYN,ACK>  TSecr is set to (<SYN>  TSval) XOR
> (receiver
> > TS capabilities).
> 
> How do you know whether it's a sender compliant to the draft
> negotiating, vs. a noncompliant RFC1323 host?

There are three aspects to this:

a) The receiver may think a higher version sender is trying to
negotiate.
Assuming a non-compliant RFC1323 sender has the <SYN> TSecr bits set in
a random way, the chances for this are EXO=1 (50%) * VER=[1..3] (75%),
so ~37.5%. 

The receiver may only run the PAWS check on TSval during the session
(perhaps using a partial TSval, as MASK also contains random bits).

If SACK is negotiated too, the sender may be coaxed into too aggressive
RTTM / RTO calculation. However, the effect of this would be a reduced
throughput (and reduced goodput) for that session, due to the frequence
congestion control reaction after a spurious RTO by the sender.

b) The receiver may coaxed into enabling local algorithms exceeding PAWS
(ie. OWD variance). This is more problematic, as the receiver (or
passive sender) may use TSval as input signal into congestion control or
loss recovery. 

To reduce the chances of this happening, the RES bits field MUST be set
to zero by a compliant sender.

The likelihood that a misbehaving sender sends these fields to
EXO=1, VER=00b, RES=00000000b, by random chance is about 2^-11...

Bob pointed out, that the behavior of such misbehaving hosts would need
to be investigated. My understanding is, that the misbehavior was due to
not initializing the TS.recent value in tcpcb correctly, so a random
memory content, likely to be word-aligned, used to be visible.

Perhaps Fernando Gont has a pointer to the source of that section in his
tcp security draft, which stacks exhibited the issue... (I believe it
was with rather old stacks).

What I found is this hint
http://kerneltrap.org/mailarchive/linux-netdev/2009/4/10/5446374 - as a
TSval of a previous session is reused, that should come close enough to
random scambled bits...

c) Some older versions of Windows (95?) will not reflect TSval sent to
them in a <SYN> in the TSecr of the <SYN,ACK>. It is unclear however, if
TSecr is also not cleared (and contains some random content). If a
compliant sender sends TS capabilities (and TSval) in the initial <SYN>,
there is also the chance (again 2^-11), that the value of TSecr in the
<SYN,ACK> decodes by chance to a valid VER=00b capability. However, if
TSecr from such a receiver is known to be zero (in case of windows
xp..2003), an appropriate TS.offset can be selected by the sender, that
decoding would result in one of the 9 bits (EXO, RES) to be set invalid
for TS capability negotiation.

(I will include that scenario in the next revision of the draft. Just
learned about this from
http://www.itsec.gov.cn/webportal/download/2003-Ambiguity%20Resolution%2
0via%20Passive%20OS%20Fingerprinting.pdf, and
http://www.eggheadcafe.com/microsoft/Windows-Server-Networking/30891786/
windows-tcp-timestamp-not-compliant-to-rfc-1323-.aspx
while searching for the TSecr on <SYN> issue...

> 
> If the only example you have for using these bits is something you
> discourage, perhaps it's worth omitting it. ;-)

Yes; I only wanted to mention here on-list, that the scheme is still
compatible with RTT sampling during 3WHS, and only very minimal state
has to be kept to decode retransmitted SYNs...

Best regards,
   Richard

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Jun 2011 09:20:43 -0700

Hi, Richard,

On 6/1/2011 4:33 AM, Scheffenegger, Richard wrote:
> Assuming a non-compliant RFC1323 sender has the<SYN>  TSecr bits set in

I find this kind of analysis unconvincing; these aren't bits generated 
by a PRNG. A given host will either set some of these bits with 100% 
probability on a given date (or what it thinks is that date) or not. 
They're definitely *not* independent or random. Sure, the above would 
happen for sure 1/23/2055 at 10:02pm GMT or so for hosts using 
reasonably valid clocks - or before, for those that (correctly or not) 
pick times near this as their timestamp.

IMO, the overall analysis needs to take that into account.

> EXO=1, VER=00b, RES=00000000b, by random chance is about 2^-11...

Again, random chance isn't the problem. This particular problem *will* 
occur on 1/19/2038 at 3:14am GMT, for hosts using reasonably valid clocks.

Sure, these dates are far into the future. But we have NO idea:
	a) how long these changes will be in use
	b) whether someone will decide to 'randomize' the dates
	for some (false) sense of security (no, please - don't!)

I.e., you're playing with a space that has no requirements. There is no 
absolute that "TCP must use date stamps that are reasonably accurate to 
the current date/time". Any such assumption is asking for trouble, IMO.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 1 Jun 2011 21:02:07 +0100

Hi Joe,

I am sorry, but you lost me...

I fully agree, the PRNG assumption may not hold. But I don't quite
follow where you set a fixed date (or was your choice of the signed unix
epoch rollover random?)...

As I mentioned, the (known to me) instance where an active sender would
not set TSecr in a <SYN> to zero was an older, broken stack. IIRC, the
reason was, that TS.recent was not initialized properly, thus whatever
data was there before that section of memory got allocated to the tcpcb
is sent. It may have been a previously used tcpcb, thus some (random,
see below) TSval of a prior session may still reside there... Or zero,
if the host was recently rebooted. Or any other arbitrary number from
calculations completely unrelated to TCP...

Second, it is already known that a random TS.offset per TCP session
should be used, to avoid leaking interesting information such as system
uptime. 

Third, a passive host with a broken implementation of RFC1323 (such as
Windows XP, 2000, 2003), that set TSecr explicitly to zero in <SYN,ACK>
can be addressed by an appropriate selection of a TSoffset, such that no
valid combination of the mentioned fields can result on the decoding
operation (so 0x00 XOR <SYN> TSval should result in EXO=0, or any RES
bit = 1).

Fourth, the timestamp clock could be running at any conceivable rate (1
Hz, 60 Hz, 100Hz, 1 kHz, CPU cycles,...) thus a roll-over of the 32-bit
value will probably not occur at the same time the unix (signed) epoch
rolls over. Of course, using 1Hz granularity is just as good as anything
else. Still, I don't quite follow why a rollover (or setting of the MSB
bit) would pose a problem within the protocol described in the draft.

As broken stacks are just that (broken, not malicious), they will cause
only harm to their own sessions (e.g. higher spurious retransmissions),
IF the other end is made believe a valid capability negotiation took
place. Obviously, a protocol like this, which enables new uses, could
also be exploited (and timestamp based time measurements can be
exploited, for example is CUBIC in unpatched 2.6.16..2.6.22 vulnerable
to this). The solution in Linux (don't trust timestamps at all, and keep
per-segment state for time-tracking purposes) appears to be a bit of
overkill to me. Making sure a malicious receiver cannot modify TSval
undetected, when it reflects it, should suffice (and the protocol
provides this capability)...

Regarding the last statement, this is very true for RFC1323. As long as
monotonic increasing values are maintained, a sender is free to choose
any arbitrary clock source, including sources of variable speed (and
even simple packet or window counting is valid).

This draft makes it explicit, that if a pair of hosts want to engage
potentially improved, time-based heuristics (such as CUBIC, LEDBAT,
Chirp,...), a reasonable clock source of known tick interval length
should be chosen. In addition, a few bits may be used to add some kind
of entropy the receiver should not care about may also be present in the
TSval field. If a host does not want to contribute to any time-based
heuristics in TCP, it is free to signal that it's Timestamp clock is not
ticking at a constant interval (DUR=0), even if that host wants the
modified timestamp processing semantics (e.g. for improvements in loss
recovery timeliness). If a host doesn't wish to participate at all, it
is free to use (correctly implemented) RFC1323 semantics...

Again, the 3 points I mentioned in the earlier email are all (partial)
mitigations about *broken* RFC1323 implementations. Their prevalence
appears to be low though, but I will try to sift through a larger and
broader volume of internet traffic than I have done so far...

I doubt that there can be a perfect solution to this, with a lightweight
capability signaling as described in the draft.

Richard Scheffenegger

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Mittwoch, 01. Juni 2011 18:21
> To: Scheffenegger, Richard
> Cc: [email-masked]
> Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-
> timestamp-negotiation-02.txt
> 
> Hi, Richard,
> 
> > passive sender) may use TSval as input signal into congestion
control
> or

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Jun 2011 13:53:44 -0700

> epoch rollover random?)...

I picked dates that had the bits set as you indicated ;-)

> calculations completely unrelated to TCP...

OK, so this issue is limited to what happens in a <SYN>, but it's still 
worth explaining what happens in that case - even if a poor 
implementation dumps the current timestamp value in the <SYN> (even if 
oddly set). AFAICT, RFC1323 doesn't care about that situation - does it??

> Windows XP, 2000, 2003), that set TSecr explicitly to zero in<SYN,ACK>
> operation (so 0x00 XOR<SYN>  TSval should result in EXO=0, or any RES
> bit = 1).
>

My overall suggestion is to ensure that if RFC1323 is robust to a badly 
set <SYN>, you should explain whether your new mechanism is similarly 
robust or not

> should be chosen.

Are you defining "reasonable" as having the desired bits clear? If so, 
that's useful to state, as is what happens when this is not the case.

(I hope "reasonable" doesn't mean "reasonably close to current time" - I 
want to preserve TS-independence as per RFC1323).

> In addition, a few bits may be used to add some kind

Agreed; it's useful to be clear to whether your mechanism introduces 
some sort of susceptibility to such errors that isn't there for 
RFC1323-hosts.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 1 Jun 2011 22:16:51 +0100

Hello Joe, 

thanks for the quick feedback!

The semantics of the Timestamp option during the session will not
change; so the hosts have complete freedom to choose whatever clock
source and offset they like.

The issue we are discussion only happens during the initial <SYN> /
<SYN,ACK> exchange, where this draft changes the semantics what is
encoded in the - so far unused - TSecr field.

RFC1323 states, that 
"When TSecr is not valid, its value must be zero." 

As the initial <SYN> cannot have a valid timestamp to reflect, this must
mean that a compliant RFC1323 stack should zero out TSecr in <SYN>. And
all current stacks comply here.

When a stack does not, there really is no telling what kind of data is
contained therein (therefore, there is also no direct dependency on
absolute time in any way).

Those stacks that explicitly clear TSecr on <SYN,ACK> are a little bit
harder to dismiss as misbehaving. However, a <SYN,ACK> is usually the
result of a <SYN>, and the timestamp option must only be sent when the
<SYN> already contained one; therefore, the <SYN,ACK> TSecr should
reflect the <SYN> TSval. But if it doesn't, it's not strictly a
violation of protocol.

Fortunately, this is a special case, and can be handled by the active
sender.

You are correct, RFC1323 doesn't really care about what happens during
the <SYN> and <SYN,ACK>, as RTTM (should) be started only with the first
normal <ACK> segment. [RFC3390] section 6 "Interaction with the
Retransmission Timer" recommends not to sample the RTT during the
three-way handshake... And many versions of linux mistakenly assume a
TSecr value of 0 is always invalid (turning the RFC1323 statement on
it's head).

Regarding robustness: Yes, proper implementations should be; however, I
have a strong suspicion, that whenever TSecr is non-zero, stacks will
use that as a valid RTTM sample (regardless of the SYN flag), possibly
arriving at strange RTO values.

As long as the only purpose of timestamps is to provide RTT measurements
and PAWS, broken implementations in this respect have limited exposure
(a few initial spurious retransmits may be caused). However, if
timestamps should be empowered to provide a higher quality input signal
for more core algorithms than RTO calculation, the exposure is
definitely larger.

Best regards, 

Richard Scheffenegger

> Sent: Mittwoch, 01. Juni 2011 22:54
> > can be addressed by an appropriate selection of a TSoffset, such
that
> no
> >>> Assuming a non-compliant RFC1323 sender has the<SYN>   TSecr bits
> set
> >> in
> >>> b) The receiver may coaxed into enabling local algorithms
exceeding
> >> PAWS
> >>> To reduce the chances of this happening, the RES bits field MUST
be
> >> set
> >> I.e., you're playing with a space that has no requirements. There
is
> > no
> >> absolute that "TCP must use date stamps that are reasonably
accurate
> > to

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Jun 2011 14:21:53 -0700

Thanks - I'm hoping some of this will be included in the update as 
clarification of "backward compat" (even busted) issues...

Joe

On 6/1/2011 2:16 PM, Scheffenegger, Richard wrote:
> The issue we are discussion only happens during the initial<SYN>  /
> As the initial<SYN>  cannot have a valid timestamp to reflect, this must
> mean that a compliant RFC1323 stack should zero out TSecr in<SYN>. And
> Those stacks that explicitly clear TSecr on<SYN,ACK>  are a little bit
> harder to dismiss as misbehaving. However, a<SYN,ACK>  is usually the
> result of a<SYN>, and the timestamp option must only be sent when the
> <SYN>  already contained one; therefore, the<SYN,ACK>  TSecr should
> reflect the<SYN>  TSval. But if it doesn't, it's not strictly a
> violation of protocol.
>
> the<SYN>  and<SYN,ACK>, as RTTM (should) be started only with the first
> normal<ACK>  segment. [RFC3390] section 6 "Interaction with the
>>> not set TSecr in a<SYN>   to zero was an older, broken stack. IIRC,
>> the
>> OK, so this issue is limited to what happens in a<SYN>, but it's
> still
>> implementation dumps the current timestamp value in the<SYN>  (even if
>> set<SYN>, you should explain whether your new mechanism is similarly
>> robust or not
>>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm