Watch and learn to see how ATEN provided an easy and effective way for three jointly-owned pubs to control the 60 televisions located across their three venues utilizing the ATEN Control System, Modular Matrix Switch and HDBaseT extenders.
Course Of The Month
7 days, 11 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
adverse Impact of disabling Tcp_timestamps in Xolaris
Posted on 2014-11-14
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?
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?
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
10
6
4
20 Comments
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
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
Active today
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
q3. See the extract from F5, you need to balance perf vs the low probability for disabling tcp tmestamp. Note this from Solaris doc
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.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"
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.
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.
Active 1 day ago
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_tst
OR
"echo 0 > /proc/sys/net/ipv4/tcp_tim
So will that be
"echo 0 > /proc/sys/net/ipv4/tcp_tst
OR
"echo 0 > /proc/sys/net/ipv4/tcp_tim
Active 1 day ago
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
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
Active today
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
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
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.
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.
Active 1 day ago
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
performance impact when Tcp Timestamp is disabled on the LTM,
thus was recommended not to turn it off
Active 1 day ago
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
# 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
Active today
As stated in (http://www.sean.de/Solaris/soltune.html)
for tcp_wscale_always-
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.
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 itAnd 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.
Active 1 day ago
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"
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"
Active 1 day ago
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."
"if getting an accurate measurement of round-trip time (RTT) and TCP
sequence number wraparound is a problem, enable this parameter."
Active today
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 timeoutAs 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
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.
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.
Active 1 day ago
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?
"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?
Active 1 day ago
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
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
Active today
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
https://docs.oracle.com/cd/E23824_01/html/821-1454/netmonitor-2.html#netmonitor-10
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
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.
Active 1 day ago
> 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?
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?
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.
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.
Featured Post
Watch and learn how ATEN provided a total control system solution including seamless switching matrix switch, HDBaseT extenders, PDU, lighting control to build an interactive eFuture classroom.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Getting hacked is no longer a matter or "if you get hacked" — the 2016 cyber threat landscape is now titled "when you get hacked." When it happens — will you be proactive, or reactive?
Examines three attack vectors, specifically, the different types of malware used in malicious attacks, web application attacks, and finally, network based attacks. Concludes by examining the means of securing and protecting critical systems and inf…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Suggested Courses
Course of the Month7 days, 11 hours left to enroll
728 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.