In today’s connected world, surfing the internet is more than just a pastime, it is now a place where critical functions are performed such as eCommerce, publishing, CRM and video-streaming, just to name a few.
The current need for securing cyber assets has taken precedence due to numerous data breaches and DDOS attacks. The exponential growth of these attacks has led to a greater affinity towards networking security products and services.
Encrypted traffic is being utilized by more and more application services with upwards of 75% or more being encrypted these days. Once the domain of commerce, encrypted traffic is now used for everyday apps such as searching on Google, Office 365 and Salesforce. When it comes to handling this type of traffic, Network Equipment Manufacturers, enterprises and Service Providers all look for answers to the following questions:
How much encrypted traffic can my network manage?
How fast can new encrypted sessions be setup and maintained?
Spirent has the answers to these questions! Spirent test solutions can be used for determining performance benchmarking of key vectors; however, the challenge lies in figuring out what network traffic attributes impact performance and enable encryption security using SSL/TLS protocols while testing network devices.
Encryption attributes impacting throughput performance
The following attributes can be tweaked to achieve better encryption throughput during a performance test to find baseline performance as well as theoretical maximums:
TLS Record Size
Object or File Size
TLS Record Size
When encryption is enabled, all application data is transported using the TLS record protocol. The size of the TLS Record ranges from 1460 bytes to 16KB. A larger TLS buffer will allow for sending and receiving larger chunks of encryption payload in one-go, compared to a smaller record size. It is seen that using a maximum record size of 16KB, over the default size of 1460 bytes, significantly improves encryption performance while testing a DUT’s encryption throughput.
Key size determines the security of an encrypted connection with higher key size providing more security. However, the larger public key size results in lower connections per second performance due to stronger keys being exchanged during the initial individual session handshake. The throughput performance, however, is impacted with symmetric encryption that uses a ‘shared secret key’ for encryption and decryption. For example, the throughput performance drop may be observed when using a 4K key vs a 2K key. Depending on the application or severity of needed security larger key sizes may be mandated and thus testing with different keys sizes will highlight these performance differences.
The size of the object or file that application clients request during a layer-7 transaction, such as a GET request for https transactions, impacts the encryption performance throughput as well as the sessions per second performance. The larger file sizes (or object sizes) result in higher performance throughput but in lower sessions per second performance. The reason for a higher throughput with larger file sizes is due to a lesser protocol overhead. On the other hand, the larger file sizes take longer for a session to come up, hence decreasing the sessions or connections per second performance. As a rule of thumb, in a network test, always try using larger file sizes in the range of 65KB and above and optimize it with number of sessions required. For higher number of session/sec performance, use lower file sizes in the range of 1 byte to 1Kbyte.
Sessions resumption only requires one round-trip between a client and a server. Session resumption helps in not having to go through a full SSL/TLS handshake and hence provides low CPU overhead. It uses previously stored session information by tracking session IDs and session tickets and reusing them next time. This boosts the sessions or connections per second performance. Though using this configuration option increases sessions per second performance, we do recommend turning this feature off to measure the real cps performance of a DUT without the help of stored session information.
NetSecOPEN testing standard developed through the collaboration of teams from leading industry test equipment vendors, NEMS, test labs, enterprises and service providers, brings to the table a traffic mix that is 70% encrypted HTTPS flows for 80+ real-world applications with up-to-date ciphers, differing object sizes and key sizes. This traffic mix is based off of real-world application mixes seen in the production networks with over 10,000 unique URLS, 1000 unique FQDNs and 400 Unique Certificates. It is highly recommended to test your infrastructure using NetSecOPEN traffic mix. For testing with NetSecOPEN standard traffic mix, please contact Spirent as NetSecOPEN tests are built into Spirent CyberFlood. For more information on NetSecOPEN, please go to www.netsecopen.org.
If you are interested in learning more about TLS 1.3, read our blog or visit the CyberFlood Page. If you would like this level of security expertise for your company and want to speak to our security experts directly, contact us or view our Cybersecurity on-demand webinars.
Follow Spirent Security on Twitter (@spirentsecurity) for the latest security news.