adverse Impact of disabling Tcp_timestamps in Xolaris

Planning to disable it for security reason but have heard F5 advise against it for F5 .


https://docs.oracle.com/cd/E19455-01/806-6779/6jfmsfr8a/index.html
Url above also has some indication

Q1:
What's "Commitment Level" unstable?


https://www.ietf.org/rfc/rfc1323.txt
Url above also indicates something:
...working with TCP's that do not implement the extensions.  The timestamps are used for 2 distinct mechanisms:
   RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences).

Q2:
Does any Web applications & Solaris 10 x86 VMs need/use RTTM & PAWS ?

Q3:
Can I safely say that disabling Tcp_timestamps is only a concern on congested networks
esp WAN but on Gigabit LAN, its performance impact is negligible?
sunhuxAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

gheistCommented:
1) RFC1323 is off by default on any solaris version
2) No, they use socket API, not low level protocols directly
3) the way you write -are you using Solaris or Linux? Solaris parameter is named  tcp_tstamp_always
btanExec ConsultantCommented:
TCP timestamp can be used for fingerprinting and determining server uptime, it is not entirely bad but can be bad for performance monitoring perspective (at least from F5 being the ADC to ensure speed and itself implement tcp-timestamp too). The security by default, is of course to close any mean for information gathering and scan is very likely to surface this as ill intented attempts. See this F5 post https://support.f5.com/kb/en-us/solutions/public/8000/000/sol8072.html
Note: The issue of using uptime information to select a subsequent attack should not to be confused with any attack against the timestamp mechanism directly.

Eliminating the use of TCP timestamps is not desirable because a performance penalty would occur without RTTM. More importantly, PAWS can protect against both the loss of data when TCP sequence numbers wrap, but also against denial-of-service attacks, which attempt to shut down an existing TCP connection. Without PAWS, the attacker needs only the IP addresses and port numbers of the connection endpoints to reset the connection.
q1. the level is to describe the state upon use of the setting of this tunable field. see its definition under "Tuning Format of Tunable Parameters Descriptions"
Identifies the stability of the interface. Many of the parameters in this manual are still evolving and are classified as unstable.
q2. Default disabled based on "tcp_tstamp_always" as you can see in the doc across Solaris platform. But I do see other forum say this RFC it stated enabled but good to verify and see this for the setting

q3. See the extract from F5, you need to balance perf vs the low probability for disabling tcp tmestamp. Note this from Solaris doc
If getting an accurate measurement of round-trip time (RTT) and TCP sequence number wraparound is a problem, enable this parameter.
sunhuxAuthor Commented:
I'm using Solaris x86, thanks Gheist for pointing out it's  tcp_tstamp_always.

So will that be
"echo 0 > /proc/sys/net/ipv4/tcp_tstamp_always"  
     OR
"echo 0 > /proc/sys/net/ipv4/tcp_timestamps"   ??
4 signs you’re cut out for a cybersecurity career

It’s one of the most in-demand fields in technology and in the job market as a whole. It’s crucial to our individual and national security. And it may be your path to a future filled with success and job satisfaction—if these four traits sound like you.

Is this you?
sunhuxAuthor Commented:
In the link given by BTan, it's
sudo ndd -set /dev/tcp tcp_tstamp_if_wscale 1

& this parameter tcp tcp_tstamp_if_wscale (or is it tcp_tstamp_always ?)
 is set at /etc/system
sunhuxAuthor Commented:
after doing "ndd -set ..." do we need to restart Oracle Web Server or Apache ?
btanExec ConsultantCommented:
these are touching the kernel parameter, any changes after will require system reboot
https://docs.oracle.com/cd/E19644-01/817-5051/pt_tuningos.html
ndd can query the setting if "-set" is not in the command
http://www.cns.nyu.edu/~fan/sun-docs/sol10-01-13/html/816-5166/ndd-1m.html#scrolltoc
gheistCommented:
solaris does not have sysctl or /proc filesystem
usually you find linux guide next to solaris guides, especially when you try glassfish or oracle rdbms documentation.

I find it wierd that F5 requests you to change some parameter, because it is negotiable TCP option which they could as well clear on their connections and no other onnecting party will ever even try to use that.
sunhuxAuthor Commented:
Our F5 support chaps has got reply from F5 that there will be adverse
performance impact when Tcp Timestamp is disabled on the LTM,
thus was recommended not to turn it off
sunhuxAuthor Commented:
Only managed to beg someone to login to a Solaris x86.

# ndd /dev/tcp \?  |grep -i stamp

gives tcp_tstamp_if_wscale (it's 0) & tcp_tstamp_always (already 1)
so it must be the former

There's /proc but no /proc/sys  fs

Yes, no /etc/sysctl.conf  only /etc/system
btanExec ConsultantCommented:
As stated in (http://www.sean.de/Solaris/soltune.html)
A value of 1 for timestamp always tries to negotiate the TCP timestamp option for the configured host or network. However, a value of zero for timestamp may still negotiate the timestamp option, depending on the settings of tcp_tstamp_always and tcp_tstamp_if_wscale.
So since there is a "1" based on setting it is already enabled per se. The recommendation from doc stated also
for tcp_wscale_always-
If you want the window scale option in a high-speed network configuration, enable it.
for tcp_tstamp_always -
if an accurate measurement of round trip time (RTT) and TCP sequence number wraparound is a problem, enable it
And coupled with F5 recommendation to have it enabled (with their black and white and also stated in their public posting shared in my last post), I do not see the risk exposure as high though. They are largely performance oriented though their will be information surfaced useful for attacker and commonly flagged by scanner on the "holes" for further exploitation.

But we are not saying the other hardening at the server and systems end is lacking. Hence there is need to check and balance from operational angle of the gain vs the expected repercussion leading to unnecessary outage.
sunhuxAuthor Commented:
Last question:

how do I verify/check that my web servers are affected by:
"when accurate measurement of round-trip time (RTT) and TCP sequence number wrap-around is needed"
sunhuxAuthor Commented:
Hi BTan, can provide the link again where you found statement below:
"if getting an accurate measurement of round-trip time (RTT) and TCP
  sequence number wraparound is a problem, enable this parameter."
btanExec ConsultantCommented:
Kindly see https://docs.oracle.com/cd/E19683-01/806-7009/6jftnqske/ for the two parameters. Also to refer to RFC1323 https://www.ietf.org/rfc/rfc1323.txt
A good RTT estimator with a conservative retransmission timeout
      calculation can tolerate aliasing when the sampling frequency is
      "close" to the data frequency.   For example, with a window of 8
      packets, the sample rate is 1/8 the data frequency -- less than an
      order of magnitude different.  However, when the window is tens or
      hundreds of packets, the RTT estimator may be seriously in error,
      resulting in spurious retransmissions.

      If there are dropped packets, the problem becomes worse.
As for the PAWS, the RFC also included description to look out for. May not be easily understood but the whole gist is that these TCP extensions are to
provide efficient operation over large-bandwidth*delay-product paths and reliable operation over very high-speed paths.  These extensions are designed to provide compatible interworking with TCP's that do not implement the extensions.
sunhuxAuthor Commented:
how do I verify/check that my web servers are affected by:
"when accurate measurement of round-trip time (RTT) and TCP sequence number wrap-around is needed" :

So to verify for retransmission errors, do I issue "netstat -i" ("netstat -es" in
Windows) in the Solaris servers & check if the  Retransmission errors count
increase over period of time when there's traffic load?
sunhuxAuthor Commented:
Or would repeated "ifconfig NIC_interface"  give better outputs?
Which specific parameter/counter should I look out for?
Tcp_Retrans_Seg?  In Windows, there's this "Segments Retransmitted"

Numerous counters were given in
https://dansysadm.com/solaris-netstat-tcp-protocol-statistics-explained.html

 $ nestat -s -P tcp
 TCP
    tcpRtoAlgorithm     =     4     tcpRtoMin           =   400
    tcpRtoMax           = 60000     tcpMaxConn          =    -1
    tcpActiveOpens      =7624114    tcpPassiveOpens     =7084624
    tcpAttemptFails     =1896763    tcpEstabResets      =193326
    tcpCurrEstab        =    74     tcpOutSegs          =21843389688
    tcpOutDataSegs      =3328351751 tcpOutDataBytes     =3235412917
    tcpRetransSegs      =41967918   tcpRetransBytes     =2212890976
    tcpOutAck           =853704065  tcpOutAckDelayed    =247961090
    tcpOutUrg           =     1     tcpOutWinUpdate     =477772
    tcpOutWinProbe      = 12412     tcpOutControl       =33045410
    tcpOutRsts          =5285917    tcpOutFastRetrans   =  8210
    tcpInSegs           =11491393189
    tcpInAckSegs        =1158661729 tcpInAckBytes       =1102332654
    tcpInDupAck         =142544351  tcpInAckUnsent      =     0
    tcpInInorderSegs    =1884725886 tcpInInorderBytes   =1286627563
    tcpInUnorderSegs    =1912668    tcpInUnorderBytes   =2409325298
    tcpInDupSegs        =34780066   tcpInDupBytes       =1415828491
    tcpInPartDupSegs    =  3626     tcpInPartDupBytes   =1693311
    tcpInPastWinSegs    =2269167    tcpInPastWinBytes   =126796354
    tcpInWinProbe       =  1057     tcpInWinUpdate      = 11758
    tcpInClosed         =3426232    tcpRttNoUpdate      =445365299
    tcpRttUpdate        =706469685  tcpTimRetrans       =1305409
    tcpTimRetransDrop   =  2328     tcpTimKeepalive     = 75510
    tcpTimKeepaliveProbe= 28677     tcpTimKeepaliveDrop =   193
    tcpListenDrop       =    11     tcpListenDropQ0     =     0
    tcpHalfOpenDrop     =     0     tcpOutSackRetrans   =40485027
btanExec ConsultantCommented:
You may want to check out this instead for network potential errors e.g. netstat -i and the use of netstat -s (as you shared also) to see more in depth field such as tcpRttUpdate, tcpTimRetransDrop, tcpOutAckDelayed, tcpRttNoUpdate etc which rightfully should not be high though else it means there are many RTT and retransmit attempt esp for slow n/w bw. There are probably more to look out for but those pertaining to error and drop of packet should not be significantly high. Best to check it in your env to set baseline e.g. peak and off peak period to see the no changes if any

https://docs.oracle.com/cd/E23824_01/html/821-1454/netmonitor-2.html#netmonitor-10

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
gheistCommented: 
Our F5 support chaps has got reply from F5 that there will be adverse
performance impact when Tcp Timestamp is disabled on the LTM,
thus was recommended not to turn it off

Open in new window


It is off by default. to avoid adverse performance impact you actually have to enable tcp timestamps.
Ask them in your language and skip translations.
sunhuxAuthor Commented:
> It is off by default
For some historical reason, it was enabled in all our F5: don't know when
& who enabled it.

So Gheist, you felt it should be safe to disable on F5 as it was off by default?
gheistCommented:
Why should you care?
If solaris has TCP extension disabled F5 will never have a chance to use it.

Your text says that DISABLING timestamps has performance impact. since it was never enabled impact is in full force.
Do some network measurements - if it saturates wire - no need to change.
btanExec ConsultantCommented:
default is implicitly what provider recommends unless they are ignorance. eventually they are also running an OS themselves and you concern should be in the server rather than the intermediary. F5 serves as LB and ADC nothing else.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Security

From novice to tech pro — start learning today.