Before moving to the cloud, it is important to carefully define your db needs, plan for the migration & understand prod. environment. This wp explains how to define what you need from a cloud provider, plan for the migration & what putting a cloud solution into practice entails.
COURSE of the MONTH
11 days, 22 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 3 days 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 3 days 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 3 days 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 3 days 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 3 days 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 3 days 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 3 days 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 3 days 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 3 days 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
Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Getting to know the threat landscape in which DDoS has evolved, and making the right choice to get ourselves geared up to defend against DDoS attacks effectively. Get the necessary preparation works done and focus on Doing the First Things Right.
Phishing is at the top of most security top 10 efforts you should be pursuing in 2016 and beyond. If you don't have phishing incorporated into your Security Awareness Program yet, now is the time. Phishers, and the scams they use, are only going to …
Learn how to get help with Linux/Unix bash shell commands.
Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail. The methods are covered in more detail in o…
Suggested Courses
Course of the Month11 days, 22 hours left to enroll
752 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.