• No results found

CAS_014 Determine HTTP transfer rate of the firewall performance per RFC3511 Section 5

Abstract

This test determines the transfer rate of HTTP requested objects traversing the firewall. It defines the aggregate number of connections attempted. The number should be a multiple of the number of virtual clients participating in the test. It also defines the method of closing TCP connections. This test must be performed with either a three-way or four-way handshake. In a four-way handshake, each side sends separate FIN and ACK messages. In a three-way handshake, one side sends a combined FIN/ACK message upon receipt of a FIN. Finally, it defines whether closing of connections is to be initiated from the client or from the server.

With the test, the user can determine the peak HTTP rate of the DUT.

Description

Each HTTP 1.1 or higher virtual client requests one or more objects from an HTTP 1.1 or higher server using one or more HTTP GET requests over each connection. The aggregate number of connections attempted, defined by number of connections, must be evenly divided among all the participating virtual clients.

If the virtual clients make multiple HTTP GET requests per connection, it must request the same object size for each GET request. Multiple iterations of this test may be run with objects of different sizes.

Target Users

Product verification, Engineering

Target Device Under Test (DUT)

Firewall

Reference

RFC 3511

Relevance

For the networks that a firewall secures, often the value of the data and systems that they must help protect cost many times that of the firewall and the testing. Deploying a security

infrastructure without understanding its performance and security runs the risk of doing little to protect the network, especially if it also introduces apathy from a false sense of security. Among

49

Firewall behavior at load and at failure: Firewalls often exhibit different behaviors as they encounter increasing loads. Eventually, with enough traffic, the firewall will fail, providing valuable insights. First, the conditions and behavior leading up to failure are now known, giving the security administrator things to look for in production and providing a useful pre-failure warning. Second, the failure state of the firewall is known—firewalls that fail closed will stop all traffic from passing (essentially a successful denial of service, or DoS, attack), and firewalls that fail open permit all traffic, which is a security failure.

Pre-deployment capacity planning: Deployment of a security infrastructure will most likely affect overall network performance. Testing the effect on network performance ensures that the increased security does not decrease performance beyond the levels acceptable for the business.

Version

1.0

Test Category

Testing Firewalls and VPN

PASS

[X] Performance [X] Availability [X] Security [X] Scale

Required Tester Capabilities

Generate performance test for connections per second. Load profiles for different step iterations and test duration. Server transactions profile support for different object sizes.

Real-time and summary reports on highest connections tear down rate, minimum connection tear down time, maximum connection tear down time, average connection tear down time, aggregate connection tear down time.

Topology Diagram

Test Procedure

1. Reserve two test ports.

2. Connect cabling to the DUT. Cable tester port 1 as the client side to the configured firewall- capable DUT. Connect port 2 as the server side to the other side of DUT. Establish the link. 3. Begin Step 1 – Generate the HTTP 1.1 transactions per second performance test:

a. Enter the management IP address of the client port. b. Enter the management IP address of the server port.

c. Select the performance test for the specific equipment used in this test. d. Configure HTTP 1.1 for both client and server.

e. To maximize the performance of the tester, send 10 HTTP level 1 GET requests from each SimUser.

f. Each TCP connection accepts one HTTP transaction as maximum transaction, therefore each of the SimUsers generate 1 TCP connection sequentially.

4. Begin Step 2 – Test the effect of load, object size, and duration. a. Client side:

i. HTTP version 1.1.

ii. HTTP GET Per SimUser is 50.

51

iii. Connection Termination with FIN. iv. Object/Page size is 100Kb, 500Kb, 1Mb. 5. Load Reference.

a. Load (Transactions/second) 1150 with 100Kb object. b. Load (Transactions/second) 230 with 500Kb object. c. Load (Transactions/second) 110 with 1Mb object. 6. End test.

Control Variables & Relevance

Variable Relevance Default Value

Packet sizes – 100Kb, 500Kb, 1Mb

Determine the maximum throughput for the firewall DUT per fixed packet size.

980 Mbps throughput Test Duration At least 10 minutes. 10 minutes

Key Measured Metrics

Matric Relevance Metric Unit

Number of bytes transferred

Total payload bytes transferred

Number of Timeouts Total number of timeout events Retransmitted bytes Total number of retransmitted bytes

Desired Result

The transfer rate results are reported for each of the object sizes tested, including the number and percentage of completed requests, number and percentage of completed responses, and the resultant transfer rate for each iteration of the test. The transfer rate results also include the total bytes transferred, total timeouts, total retransmitted bytes and resultant goodput.

Analysis

There should be no packet loss. Metrics of interest include maximum TCP connections tear down rate, minimum connection tear down time, maximum connection tear down time, average connection tear down time, aggregate connection tear down time, number of connections, aging time, close method, and close direction. Different packet sizes should produce different

CAS_015 Measure HTTP transaction rate of the firewall performance