draft-ietf-bmwg-firewall-05.txt   draft-ietf-bmwg-firewall-06.txt 
Benchmarking Working Group Brooks Hickman Benchmarking Working Group Brooks Hickman
Internet-Draft Spirent Communications Internet-Draft Spirent Communications
Expiration Date: December 2002 David Newman Expiration Date: March 2003 David Newman
Network Test Network Test
Saldju Tadjudin Saldju Tadjudin
Spirent Communications Spirent Communications
Terry Martin Terry Martin
GVNW Consulting Inc GVNW Consulting Inc
June 2002 September 2002
Benchmarking Methodology for Firewall Performance Benchmarking Methodology for Firewall Performance
<draft-ietf-bmwg-firewall-05.txt> <draft-ietf-bmwg-firewall-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document discusses and defines a number of tests that may be This document discusses and defines a number of tests that may be
used to describe the performance characteristics of firewalls. In used to describe the performance characteristics of firewalls. In
addition to defining the tests this document also describes specific addition to defining the tests, this document also describes
formats for reporting the results of the tests. specific formats for reporting the results of the tests.
This document is a product of the Benchmarking Methodology Working This document is a product of the Benchmarking Methodology Working
Group (BMWG) of the Internet Engineering Task Force (IETF). Group (BMWG) of the Internet Engineering Task Force (IETF).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Test Considerations . . . . . . . . . . . . . . . . . . 4 4.1 Test Considerations . . . . . . . . . . . . . . . . . . 4
4.2 Virtual Client/Servers . . . . . . . . . . . . . . . . . 4 4.2 Virtual Client/Servers . . . . . . . . . . . . . . . . . 4
4.3 Test Traffic Requirements . . . . . . . . . . . . . . . . 4 4.3 Test Traffic Requirements . . . . . . . . . . . . . . . . 4
4.4 DUT/SUT Traffic Flows . . . . . . . . . . . . . . . . . . 5 4.4 DUT/SUT Traffic Flows . . . . . . . . . . . . . . . . . . 4
4.5 Multiple Client/Server Testing . . . . . . . . . . . . . 5 4.5 Multiple Client/Server Testing . . . . . . . . . . . . . 5
4.6 NAT(Network Address Translation) . . . . . . . . . . . . 5 4.6 NAT(Network Address Translation) . . . . . . . . . . . . 5
4.7 Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . 6 4.7 Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . 5
4.8 Web Caching . . . . . . . . . . . . . . . . . . . . . . . 6 4.8 Web Caching . . . . . . . . . . . . . . . . . . . . . . . 6
4.9 Authentication . . . . . . . . . . . . . . . . . . . . . 6 4.9 Authentication . . . . . . . . . . . . . . . . . . . . . 6
4.10 TCP Stack Considerations . . . . . . . . . . . . . . . . 6
5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 6 5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 6
5.1 IP throughput . . . . . . . . . . . . . . . . . . . . . . 6 5.1 IP throughput . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Concurrent TCP Connection Capacity . . . . . . . . . . . 8 5.2 Concurrent TCP Connection Capacity . . . . . . . . . . . 8
5.3 Maximum TCP Connection Establishment Rate . . . . . . . . 10 5.3 Maximum TCP Connection Establishment Rate . . . . . . . . 10
5.4 Maximum TCP Connection Tear Down Rate . . . . . . . . . . 12 5.4 Maximum TCP Connection Tear Down Rate . . . . . . . . . . 12
5.5 Denial Of Service Handling . . . . . . . . . . . . . . . 14 5.5 Denial Of Service Handling . . . . . . . . . . . . . . . 14
5.6 HTTP Transfer Rate . . . . . . . . . . . . . . . . . . . 15 5.6 HTTP Transfer Rate . . . . . . . . . . . . . . . . . . . 15
5.7 HTTP Concurrent Transaction Capacity . . . . . . . . . . 17 5.7 Maximum HTTP Transaction Rate . . . . . . . . . . . . . . 18
5.8 HTTP Transaction Rate . . . . . . . . . . . . . . . . . . 18 5.8 Illegal Traffic Handling . . . . . . . . . . . . . . . . 20
5.9 Illegal Traffic Handling . . . . . . . . . . . . . . . . 20 5.9 IP Fragmentation Handling . . . . . . . . . . . . . . . . 21
5.10 IP Fragmentation Handling . . . . . . . . . . . . . . . 21 5.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . 22
5.11 Latency . . . . . . . . . . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Consideration . . . . . . . . . . . . . . . . . . . 26 7. Security Consideration . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
Appendix A - HyperText Transfer Protocol(HTTP) . . . . . . . . 27 Appendix A - HyperText Transfer Protocol(HTTP) . . . . . . . . 27
Appendix B - Connection Establishment Time Measurements . . . . 27 Appendix B - Connection Establishment Time Measurements . . . . 27
Appendix C - Connection Tear Down Time Measurements . . . . . . 28 Appendix C - Connection Tear Down Time Measurements . . . . . . 28
Full Copy Statement . . . . . . . . . . . . . . . . . . . . . . 28 Full Copy Statement . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document provides methodologies for the performance This document provides methodologies for the performance
benchmarking of firewalls. It provides methodologies in four areas: benchmarking of firewalls. It provides methodologies in four areas:
forwarding, connection, latency and filtering. In addition to forwarding, connection, latency and filtering. In addition to
defining the tests, this document also describes specific formats defining the tests, this document also describes specific formats
for reporting the results of the tests. for reporting the results of the tests.
A previous document, "Benchmarking Terminology for Firewall A previous document, "Benchmarking Terminology for Firewall
skipping to change at page 2, line 55 skipping to change at page 2, line 54
attempting to make use of this document. attempting to make use of this document.
2. Requirements 2. Requirements
In this document, the words that are used to define the significance In this document, the words that are used to define the significance
of each particular requirement are capitalized. These words are: of each particular requirement are capitalized. These words are:
* "MUST" This word, or the words "REQUIRED" and "SHALL" mean that * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that
the item is an absolute requirement of the specification. the item is an absolute requirement of the specification.
* "SHOULD" This word or the adjective "RECOMMENDED" means that there * "SHOULD" This word or the adjective "RECOMMENDED" means that
may exist valid reasons in particular circumstances to ignore this there may exist valid reasons in particular circumstances to
item, but the full implications should be understood and the case ignore this item, but the full implications should be understood
carefully weighed before choosing a different course. and the case carefully weighed before choosing a different course.
* "MAY" This word or the adjective "OPTIONAL" means that this item * "MAY" This word or the adjective "OPTIONAL" means that this item
is truly optional. One vendor may choose to include the item is truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the enhances the product, for example; another vendor may omit the
same item. same item.
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST requirements for the protocols it implements. An of the MUST requirements. An implementation that satisfies all the
implementation that satisfies all the MUST and all the SHOULD MUST and all the SHOULD requirements is said to be "unconditionally
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all compliant"; one that satisfies all the MUST requirements but not all
the SHOULD requirements for its protocols is said to be the SHOULD requirements is said to be "conditionally compliant".
"conditionally compliant".
3. Scope 3. Scope
Firewalls can provide a single point of defense between networks. Firewalls can provide a single point of defense between networks.
Usually, a firewall protects private networks from the public or Usually, a firewall protects private networks from the public or
shared networks to which it is connected. A firewall can be as shared networks to which it is connected. A firewall can be as
simple as a device that filters different packets or as complex simple as a device that filters different packets or as complex
as a group of devices that combine packet filtering and as a group of devices that combine packet filtering and
application-level proxy or network translation services. This RFC application-level proxy or network translation services. This RFC
will focus on developing benchmark testing of DUT/SUTs, wherever will focus on developing benchmark testing of DUT/SUTs, wherever
possible, independent of their implementation. possible, independent of their implementation.
4. Test Setup 4. Test Setup
Test configurations defined in this document will be confined to Test configurations defined in this document will be confined to
dual-homed and tri-homed as shown in figure 1 and figure 2 dual-homed and tri-homed as shown in figure 1 and figure 2
respectively. respectively.
Firewalls employing dual-homed configurations connect two networks. Firewalls employing dual-homed configurations connect two networks.
One interface of the firewall is attached to the unprotected One interface of the firewall is attached to the unprotected
network, typically the public network(Internet). The other interface network[1], typically the public network(Internet). The other
is connected to the protected network, typically the internal LAN. interface is connected to the protected network[1], typically the
internal LAN.
In the case of dual-homed configurations, servers which are made In the case of dual-homed configurations, servers which are made
accessible to the public(Unprotected) network are attached to the accessible to the public(Unprotected) network are attached to the
private(Protected) network. private(Protected) network.
+----------+ +----------+ +----------+ +----------+
| | | +----------+ | | | | | | +----------+ | | |
| Servers/ |----| | | |------| Servers/ | | Servers/ |----| | | |------| Servers/ |
| Clients | | | | | | Clients | | Clients | | | | | | Clients |
| | |-------| DUT/SUT |--------| | | | | |-------| DUT/SUT |--------| | |
skipping to change at page 4, line 42 skipping to change at page 4, line 37
4.1 Test Considerations 4.1 Test Considerations
4.2 Virtual Clients/Servers 4.2 Virtual Clients/Servers
Since firewall testing may involve data sources which emulate Since firewall testing may involve data sources which emulate
multiple users or hosts, the methodology uses the terms virtual multiple users or hosts, the methodology uses the terms virtual
clients/servers. For these firewall tests, virtual clients/servers clients/servers. For these firewall tests, virtual clients/servers
specify application layer entities which may not be associated with specify application layer entities which may not be associated with
a unique physical interface. For example, four virtual clients may a unique physical interface. For example, four virtual clients may
originate from the same data source[1]. The test report SHOULD originate from the same data source[1]. The test report MUST
indicate the number of virtual clients and virtual servers indicate the number of virtual clients and virtual servers
participating in the test. participating in the test.
Testers MUST synchronize all data sources participating in a test.
4.3 Test Traffic Requirements 4.3 Test Traffic Requirements
While the function of a firewall is to enforce access control While the function of a firewall is to enforce access control
policies, the criteria by which those policies are defined vary policies, the criteria by which those policies are defined vary
depending on the implementation. Firewalls may use network layer, depending on the implementation. Firewalls may use network layer,
transport layer or, in many cases, application-layer criteria to transport layer or, in many cases, application-layer criteria to
make access-control decisions. make access-control decisions.
For the purposes of benchmarking firewall performance this document For the purposes of benchmarking firewall performance, this document
references HTTP 1.1 or higher as the application layer entity, references HTTP 1.1 or higher as the application layer entity. The
although the methodologies may be used as a template for methodologies MAY be used as a template for benchmarking with other
benchmarking with other applications. Since testing may involve applications. Since testing may involve proxy based DUT/SUTs, HTTP
proxy based DUT/SUTs, HTTP version considerations are discussed in version considerations are discussed in appendix A.
appendix A.
4.4 DUT/SUT Traffic Flows 4.4 DUT/SUT Traffic Flows
Since the number of interfaces are not fixed, the traffic flows will Since the number of interfaces are not fixed, the traffic flows will
be dependent upon the configuration used in benchmarking the be dependent upon the configuration used in benchmarking the
DUT/SUT. Note that the term "traffic flows" is associated with DUT/SUT. Note that the term "traffic flows" is associated with
client-to-server requests. client-to-server requests.
For Dual-Homed configurations, there are two unique traffic flows: For Dual-Homed configurations, there are two unique traffic flows:
skipping to change at page 5, line 52 skipping to change at page 5, line 40
Client Target Server(In order of request) Client Target Server(In order of request)
#1 1 2 3 1... #1 1 2 3 1...
#2 2 3 1 2... #2 2 3 1 2...
#3 3 1 2 3... #3 3 1 2 3...
#4 1 2 3 1... #4 1 2 3 1...
#5 2 3 1 2... #5 2 3 1 2...
#6 3 1 2 3... #6 3 1 2 3...
4.6 Network Address Translation(NAT) 4.6 Network Address Translation(NAT)
Many firewalls implement network address translation(NAT), a Many firewalls implement network address translation(NAT)[1], a
function which translates internal host IP addresses attached to function which translates internal host IP addresses attached to
the protected network to a virtual IP address for communicating the protected network to a virtual IP address for communicating
across the unprotected network(Internet). This involves additional across the unprotected network(Internet). This involves additional
processing on the part of the DUT/SUT and may impact performance. processing on the part of the DUT/SUT and may impact performance.
Therefore, tests SHOULD be ran with NAT disabled and NAT enabled Therefore, tests SHOULD be ran with NAT disabled and NAT enabled
to determine the performance differentials. The test report MUST to determine the performance differentials. The test report MUST
indicate whether NAT was enabled or disabled. indicate whether NAT was enabled or disabled.
4.7 Rule Sets 4.7 Rule Sets
skipping to change at page 6, line 27 skipping to change at page 6, line 16
client). In addition, testing SHOULD be performed using different client). In addition, testing SHOULD be performed using different
size rule sets to determine its impact on the performance of the size rule sets to determine its impact on the performance of the
DUT/SUT. Rule sets MUST be configured in a manner, such that, rules DUT/SUT. Rule sets MUST be configured in a manner, such that, rules
associated with actual test traffic are configured at the end of the associated with actual test traffic are configured at the end of the
rule set and not the beginning. rule set and not the beginning.
The DUT/SUT SHOULD be configured to deny access to all traffic The DUT/SUT SHOULD be configured to deny access to all traffic
which was not previously defined in the rule set. The test report which was not previously defined in the rule set. The test report
SHOULD include the DUT/SUT configured rule set(s). SHOULD include the DUT/SUT configured rule set(s).
4.7 Web Caching 4.8 Web Caching
Some firewalls include caching agents to reduce network load. When Some firewalls include caching agents to reduce network load. When
making a request through a caching agent, the caching agent attempts making a request through a caching agent, the caching agent attempts
to service the response from its internal memory. The cache itself to service the response from its internal memory. The cache itself
saves responses it receives, such as responses for HTTP GET saves responses it receives, such as responses for HTTP GET
requests. Testing SHOULD be performed with any caching agents on the requests. Testing SHOULD be performed with any caching agents on the
DUT/SUT disabled. DUT/SUT disabled.
4.8 Authentication 4.9 Authentication
Access control may involve authentication processes such as user, Access control may involve authentication processes such as user,
client or session authentication. Authentication is usually client or session authentication. Authentication is usually
performed by devices external to the firewall itself, such as an performed by devices external to the firewall itself, such as an
authentication server(s) and may add to the latency of the system. authentication server(s) and may add to the latency of the system.
Any authentication processes MUST be included as part of connection Any authentication processes MUST be included as part of connection
setup process. setup process.
4.10 TCP Stack Considerations
Some test instruments allow configuration of one or more TCP stack
parameters, thereby influencing the traffic flows which will be
offered and impacting performance measurements. While this document
does not attempt to specify which TCP parameters should be
configurable, any such TCP parameter(s) MUST be noted in the test
report. In addition, when comparing multiple DUT/SUTs, the same TCP
parameters MUST be used.
5. Benchmarking Tests 5. Benchmarking Tests
5.1 IP Throughput 5.1 IP Throughput
5.1.1 Objective 5.1.1 Objective
To determine the throughput of network-layer data transversing To determine the throughput of network-layer data transversing
the DUT/SUT, as defined in RFC1242[1]. Note that while RFC1242 the DUT/SUT, as defined in RFC1242[1]. Note that while RFC1242
uses the term frames, which is associated with the link layer, the uses the term frames, which is associated with the link layer, the
procedure uses the term packets, since it is referencing the procedure uses the term packets, since it is referencing the
network layer. This test is intended to baseline the ability of network layer.
the DUT/SUT to forward packets at the network layer.
5.1.2 Setup Parameters 5.1.2 Setup Parameters
The following parameters MUST be defined: The following parameters MUST be defined:
Packet size - Number of bytes in the IP packet, exclusive of any Packet size - Number of bytes in the IP packet, exclusive of any
link layer header or checksums. link layer header or checksums.
Test Duration - Duration of the test, expressed in seconds. Test Duration - Duration of the test, expressed in seconds.
skipping to change at page 7, line 29 skipping to change at page 7, line 29
unidirectional traffic, with the client offering a unicast stream of unidirectional traffic, with the client offering a unicast stream of
packets to the server for the latter. packets to the server for the latter.
The test MAY employ an iterative search algorithm. Each iteration The test MAY employ an iterative search algorithm. Each iteration
will involve the tester varying the intended load until the maximum will involve the tester varying the intended load until the maximum
rate, at which no packet loss occurs, is found. Since backpressure rate, at which no packet loss occurs, is found. Since backpressure
mechanisms may be employed, resulting in the intended load and mechanisms may be employed, resulting in the intended load and
offered load being different, the test SHOULD be performed in either offered load being different, the test SHOULD be performed in either
a packet based or time based manner as described in RFC2889[7]. As a packet based or time based manner as described in RFC2889[7]. As
with RFC1242, the term packet is used in place of frame. The with RFC1242, the term packet is used in place of frame. The
duration of the test portion of each trial MUST be at least 30 duration of the test portion of each trial MUST be at least 30 seconds.
seconds.
When comparing DUT/SUTs with different MTUs, it is RECOMMENDED to It is RECOMMENDED to perform the throughput measurements with
limit the maximum IP size tested to the maximum MTU supported by all different packet sizes. When testing with different packet sizes the
of the DUT/SUTs. DUT/SUT configuration MUST remain the same.
5.1.4 Measurement 5.1.4 Measurement
5.1.4.1 Network Layer 5.1.4.1 Network Layer
Throughput - Maximum offered load, expressed in either bits per Throughput - Maximum offered load, expressed in either bits per
second or packets per second, at which no packet loss is detected. second or packets per second, at which no packet loss is detected.
Forwarding Rate - Forwarding rate, expressed in either bits per Forwarding Rate - Forwarding rate, expressed in either bits per
second or packets per second, the device is observed to second or packets per second, the device is observed to
skipping to change at page 8, line 7 skipping to change at page 8, line 5
throughput and forwarding rate. If the test involved offering throughput and forwarding rate. If the test involved offering
packets which target more than one segment(Protected, Unprotected packets which target more than one segment(Protected, Unprotected
or DMZ), the report MUST identify the results as an aggregate or DMZ), the report MUST identify the results as an aggregate
throughput measurement. throughput measurement.
The throughput results SHOULD be reported in the format of a table The throughput results SHOULD be reported in the format of a table
with a row for each of the tested packet sizes. There SHOULD be with a row for each of the tested packet sizes. There SHOULD be
columns for the packet size, the intended load, the offered load, columns for the packet size, the intended load, the offered load,
resultant throughput and forwarding rate for each test. resultant throughput and forwarding rate for each test.
A log file MAY be generated which includes the packet size, test The intermediate results of the search algorithm MAY be saved in
duration and for each iteration: log file which includes the packet size, test duration and for
each iteration:
- Step Iteration - Step Iteration
- Pass/Fail Status - Pass/Fail Status
- Total packets offered - Total packets offered
- Total packets forwarded - Total packets forwarded
- Intended load - Intended load
- Offered load(If applicable) - Offered load(If applicable)
- Forwarding rate - Forwarding rate
5.2 Concurrent TCP Connection Capacity 5.2 Concurrent TCP Connection Capacity
5.2.1 Objective 5.2.1 Objective
To determine the maximum number of concurrent TCP connections To determine the maximum number of concurrent TCP connections
supported through or with the DUT/SUT, as defined in RFC2647[1]. supported through or with the DUT/SUT, as defined in RFC2647[1].
This test is indented to find the maximum number of entries
the DUT/SUT can store in its connection table.
5.2.2 Setup Parameters 5.2.2 Setup Parameters
The following parameters MUST be defined for all tests: The following parameters MUST be defined for all tests:
5.2.2.1 Transport-Layer Setup Parameters 5.2.2.1 Transport-Layer Setup Parameters
Connection Attempt Rate - The aggregate rate, expressed in Connection Attempt Rate - The aggregate rate, expressed in
connections per second, at which new TCP connection requests are connections per second, at which TCP connection requests are
attempted. The rate SHOULD be set at or lower than the maximum attempted. The rate SHOULD be set at or lower than the maximum
rate at which the DUT/SUT can accept connection requests. rate at which the DUT/SUT can accept connection requests.
Age Time - The time, expressed in seconds, the DUT/SUT will keep a Aging Time - The time, expressed in seconds, the DUT/SUT will keep a
connection in its connection table after receiving a TCP FIN or RST connection in its connection table after receiving a TCP FIN or RST
packet. packet.
5.2.2.2 Application-Layer Setup Parameters 5.2.2.2 Application-Layer Setup Parameters
Validation Method - HTTP 1.1 or higher MUST be used for this test. Validation Method - HTTP 1.1 or higher MUST be used for this test.
Object Size - Defines the number of bytes, excluding any bytes Object Size - Defines the number of bytes, excluding any bytes
associated with the HTTP header, to be transferred in response to an associated with the HTTP header, to be transferred in response to an
HTTP 1.1 or higher GET request. HTTP 1.1 or higher GET request.
skipping to change at page 9, line 14 skipping to change at page 9, line 13
proxy. The aggregate rate will be defined by connection attempt proxy. The aggregate rate will be defined by connection attempt
rate, and will be attempted in a round-robin fashion(See 4.5). rate, and will be attempted in a round-robin fashion(See 4.5).
To validate all connections, the virtual client(s) MUST request an To validate all connections, the virtual client(s) MUST request an
object using an HTTP 1.1 or higher GET request. The requests MUST be object using an HTTP 1.1 or higher GET request. The requests MUST be
initiated on each connection after all of the TCP connections have initiated on each connection after all of the TCP connections have
been established. been established.
When testing proxy-based DUT/SUTs, the virtual client(s) MUST When testing proxy-based DUT/SUTs, the virtual client(s) MUST
request two objects using HTTP 1.1 or higher GET requests. The first request two objects using HTTP 1.1 or higher GET requests. The first
GET request is required for connection time establishment GET request is required for connection time establishment[1]
measurements as specified in appendix B. The second request is used measurements as specified in appendix B. The second request is used
for validation as previously mentioned. When comparing proxy and for validation as previously mentioned. When comparing proxy and
non-proxy based DUT/SUTs, the test MUST be performed in the same non-proxy based DUT/SUTs, the test MUST be performed in the same
manner. manner.
Between each iteration, it is RECOMMENDED that the tester issue a Between each iteration, it is RECOMMENDED that the tester issue a
TCP RST referencing all connections attempted for the previous TCP RST referencing each connection attempted for the previous
iteration, regardless of whether or not the connection attempt was iteration, regardless of whether or not the connection attempt was
successful. The tester will wait for age time before continuing to successful. The tester will wait for aging time before continuing to
the next iteration. the next iteration.
5.2.4 Measurements 5.2.4 Measurements
5.2.4.1 Application-Layer measurements 5.2.4.1 Application-Layer measurements
Number of objects requested Number of objects requested
Number of objects returned Number of objects returned
5.2.4.2 Transport-Layer measurements 5.2.4.2 Transport-Layer measurements
Maximum concurrent connections - Total number of TCP connections Maximum concurrent connections - Total number of TCP connections
open for the last successful iteration performed in the search open for the last successful iteration performed in the search
algorithm. algorithm.
The following measurements SHOULD be performed on a per iteration
basis:
Minimum connection establishment time - Lowest TCP connection Minimum connection establishment time - Lowest TCP connection
establishment time measured as defined in appendix B. establishment time measured as defined in appendix B.
Maximum connection establishment time - Highest TCP connection Maximum connection establishment time - Highest TCP connection
establishment time measured as defined in appendix B. establishment time measured as defined in appendix B.
Average connection establishment time - The mean of all measurements Average connection establishment time - The mean of all measurements
of connection establishment times. of connection establishment times.
Aggregate connection establishment time - The total of all Aggregate connection establishment time - The total of all
measurements of connection establishment times. measurements of connection establishment times.
5.2.5 Reporting Format 5.2.5 Reporting Format
5.2.5.1 Application-Layer Reporting: 5.2.5.1 Application-Layer Reporting:
The test report MUST note the object size, number of completed The test report MUST note the object size, number of completed
requests and number of completed responses. requests and number of completed responses.
The intermediate results of the search algorithm MAY be reported The intermediate results of the search algorithm MAY be reported
in a table format with a column for each iteration. There SHOULD be in a tabular format with a column for each iteration. There SHOULD
rows for the number of requests attempted, number of requests be rows for the number of requests attempted, number and percentage
completed, number of responses attempted and number of responses requests completed, number of responses attempted, number and
completed. The table MAY be combined with the transport-layer percentage of responses completed. The table MAY be combined with
reporting, provided that the table identify this as an application the transport-layer reporting, provided that the table identify this
layer measurement. as an application layer measurement.
Version information: Version information:
The test report MUST note the version of HTTP client(s) and The test report MUST note the version of HTTP client(s) and
server(s). server(s).
5.2.5.2 Transport-Layer Reporting: 5.2.5.2 Transport-Layer Reporting:
The test report MUST note the connection attempt rate, age time and The test report MUST note the connection attempt rate, aging time,
maximum concurrent connections measured. minimum TCP connection establishment time, maximum TCP connection
establishment time, average connection establishment time, aggregate
connection establishment time and maximum concurrent connections
measured.
The intermediate results of the search algorithm MAY be reported The intermediate results of the search algorithm MAY be reported
in the format of a table with a column for each iteration. There in the format of a table with a column for each iteration. There
SHOULD be rows for the total number of TCP connections attempted, SHOULD be rows for the total number of TCP connections attempted,
total number of TCP connections completed, minimum TCP connection number and percentage of TCP connections completed, minimum TCP
establishment time, maximum TCP connection establishment time, connection establishment time, maximum TCP connection establishment
average connection establishment time and the aggregate connection time, average connection establishment time and the aggregate
establishment time. connection establishment time.
5.3 Maximum TCP Connection Establishment Rate 5.3 Maximum TCP Connection Establishment Rate
5.3.1 Objective 5.3.1 Objective
To determine the maximum TCP connection establishment rate through To determine the maximum TCP connection establishment rate through
or with the DUT/SUT, as defined by RFC2647[1]. or with the DUT/SUT, as defined by RFC2647[1]. This test is indented
to find the maximum rate the DUT/SUT can update its connection
table.
5.3.2 Setup Parameters 5.3.2 Setup Parameters
The following parameters MUST be defined for all tests: The following parameters MUST be defined for all tests:
5.3.2.1 Transport-Layer Setup Parameters 5.3.2.1 Transport-Layer Setup Parameters
Number of Connections - Defines the aggregate number of TCP Number of Connections - Defines the aggregate number of TCP
connections that must be established. connections that must be established.
Age Time - The time, expressed in seconds, the DUT/SUT will keep a Aging Time - The time, expressed in seconds, the DUT/SUT will keep a
connection in it's state table after receiving a TCP FIN or RST connection in it's state table after receiving a TCP FIN or RST
packet. packet.
5.3.2.2 Application-Layer Setup Parameters 5.3.2.2 Application-Layer Setup Parameters
Validation Method - HTTP 1.1 or higher MUST be used for this test. Validation Method - HTTP 1.1 or higher MUST be used for this test.
Object Size - Defines the number of bytes, excluding any bytes Object Size - Defines the number of bytes, excluding any bytes
associated with the HTTP header, to be transferred in response to an associated with the HTTP header, to be transferred in response to an
HTTP 1.1 or higher GET request. HTTP 1.1 or higher GET request.
skipping to change at page 11, line 29 skipping to change at page 11, line 25
requests are attempted by the virtual client(s) will be varied. The requests are attempted by the virtual client(s) will be varied. The
destination address will be that of the server or that of the NAT destination address will be that of the server or that of the NAT
proxy. The aggregate number of connections, defined by number of proxy. The aggregate number of connections, defined by number of
connections, will be attempted in a round-robin fashion(See 4.5). connections, will be attempted in a round-robin fashion(See 4.5).
The same application-layer object transfers required for validation The same application-layer object transfers required for validation
and establishment time measurements as described in the concurrent and establishment time measurements as described in the concurrent
TCP connection capacity test MUST be performed. TCP connection capacity test MUST be performed.
Between each iteration, it is RECOMMENDED that the tester issue a Between each iteration, it is RECOMMENDED that the tester issue a
TCP RST referencing all connections attempted for the previous TCP RST referencing each connection attempted for the previous
iteration, regardless of whether or not the connection attempt was iteration, regardless of whether or not the connection attempt was
successful. The tester will wait for age time before continuing to successful. The tester will wait for aging time before continuing to
the next iteration. the next iteration.
5.3.4 Measurements 5.3.4 Measurements
5.3.4.1 Application-Layer measurements 5.3.4.1 Application-Layer measurements
Number of objects requested Number of objects requested
Number of objects returned Number of objects returned
5.3.4.2 Transport-Layer measurements 5.3.4.2 Transport-Layer measurements
Highest connection rate - Highest rate, in connections per second, Highest connection rate - Highest rate, in connections per second,
for which for the search algorithm passed. for which all connections successfully opened in the search
algorithm.
The following measurements SHOULD performed on a per iteration
basis:
Minimum connection establishment time - Lowest TCP connection Minimum connection establishment time - Lowest TCP connection
establishment time measured as defined in appendix B. establishment time measured as defined in appendix B.
Maximum connection establishment time - Highest TCP connection Maximum connection establishment time - Highest TCP connection
establishment time measured as defined in appendix B. establishment time measured as defined in appendix B.
Average connection establishment time - The mean of all measurements Average connection establishment time - The mean of all measurements
of connection establishment times. of connection establishment times.
skipping to change at page 12, line 16 skipping to change at page 12, line 13
measurements of connection establishment times. measurements of connection establishment times.
5.3.5 Reporting Format 5.3.5 Reporting Format
5.3.5.1 Application-Layer Reporting: 5.3.5.1 Application-Layer Reporting:
The test report MUST note object size(s), number of completed The test report MUST note object size(s), number of completed
requests and number of completed responses. requests and number of completed responses.
The intermediate results of the search algorithm MAY be reported The intermediate results of the search algorithm MAY be reported
in a table format with a column for each iteration. There SHOULD be in a tabular format with a column for each iteration. There SHOULD
rows for the number of requests and responses completed. The table be rows for the number of requests attempted, number and percentage
MAY be combined with the transport-layer reporting, provided that requests completed, number of responses attempted, number and
the table identify this as an application layer measurement. percentage of responses completed. The table MAY be combined with
the transport-layer reporting, provided that the table identify this
as an application layer measurement.
Version information: Version information:
The test report MUST note the version of HTTP client(s) and server(s). The test report MUST note the version of HTTP client(s) and
server(s).
5.3.5.2 Transport-Layer Reporting: 5.3.5.2 Transport-Layer Reporting:
The test report MUST note the number of connections, age time and The test report MUST note the number of connections, aging time,
highest connection rate measured. minimum TCP connection establishment time, maximum TCP connection
establishment time, average connection establishment time, aggregate
connection establishment time and highest connection rate measured.
The intermediate results of the search algorithm MAY be reported The intermediate results of the search algorithm MAY be reported
in the format of a table with a column for each iteration. There in the format of a table with a column for each iteration. There
SHOULD be rows for the connection attempt rate, total number of SHOULD be rows for the connection attempt rate, total number of
TCP connections attempted, total number of TCP connections TCP connections attempted, total number of TCP connections
completed, minimum TCP connection establishment time, maximum TCP completed, minimum TCP connection establishment time, maximum TCP
connection establishment time, average connection establishment time connection establishment time, average connection establishment time
and the aggregate connection establishment time. and the aggregate connection establishment time.
5.4 Maximum TCP Connection Tear Down Rate 5.4 Maximum TCP Connection Tear Down Rate
5.4.1 Objective 5.4.1 Objective
To determine the maximum TCP connection tear down rate through or To determine the maximum TCP connection tear down rate through or
skipping to change at page 12, line 49 skipping to change at page 12, line 50
5.4 Maximum TCP Connection Tear Down Rate 5.4 Maximum TCP Connection Tear Down Rate
5.4.1 Objective 5.4.1 Objective
To determine the maximum TCP connection tear down rate through or To determine the maximum TCP connection tear down rate through or
with the DUT/SUT, as defined by RFC2647[1]. with the DUT/SUT, as defined by RFC2647[1].
5.4.2 Setup Parameters 5.4.2 Setup Parameters
Number of Connections - Defines the number of TCP connections that Number of Connections - Defines the number of TCP connections that
the tester will attempt to tear down. will be attempted to be torn down.
Age Time - The time, expressed in seconds, the DUT/SUT will keep a Aging Time - The time, expressed in seconds, the DUT/SUT will keep a
connection in it's state table after receiving a TCP FIN or RST connection in it's state table after receiving a TCP FIN or RST
packet. packet.
5.4.3 Procedure Close Method - Defines method for closing TCP connections. The 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.
An iterative search algorithm MAY be used to determine the maximum In a three-way handshake, one side sends a combined FIN/ACK message
TCP connection tear down rate. The test iterates through different upon receipt of a FIN.
Close Direction - Defines whether closing of connections are to be
initiated from the client or from the server.
5.4.3 Procedure 5.4.3 Procedure
An iterative search algorithm MAY be used to determine the maximum An iterative search algorithm MAY be used to determine the maximum
TCP connection tear down rate. The test iterates through different TCP connection tear down rate. The test iterates through different
TCP connection tear down rates with a fixed number of TCP TCP connection tear down rates with a fixed number of TCP
connections. connections.
The virtual client(s) will initialize the test by establishing TCP
connections defined by number of connections. The virtual client(s)
will then attempt to tear down all of TCP connections, at a rate
defined by tear down attempt rate. For benchmarking purposes, the
tester MUST use a TCP FIN when initiating the connection tear down.
In the case of proxy based DUT/SUTs, the DUT/SUT will itself receive In the case of proxy based DUT/SUTs, the DUT/SUT will itself receive
the final ACK in the three-way handshake when a connection is being the ACK in response to issuing a FIN packet to close its side of the
torn down. For validation purposes, the virtual client(s) MAY TCP connection. For validation purposes, the virtual client or
verify that the DUT/SUT received the final ACK in the connection tear server, whichever is applicable, MAY verify that the DUT/SUT
down exchange for all connections by transmitting a TCP datagram received the final ACK by re-transmitting the final ACK. A TCP RST
referencing the previously town down connection. A TCP RST should be should be received in response to the retransmitted ACK.
received in response to the TCP datagram.
Between each iteration, it is RECOMMENDED that the virtual client(s)
or server(s), whichever is applicable, issue a TCP RST referencing
each connection which was attempted to be torn down, regardless of
whether or not the connection tear down attempt was successful. The
test will wait for aging time before continuing to the next
iteration.
5.4.4 Measurements 5.4.4 Measurements
Highest connection tear down rate - Highest rate, in connections per Highest connection tear down rate - Highest rate, in connections per
second, for which all TCP connections were successfully torn down. second, for which all TCP connections were successfully torn down in
the search algorithm.
The following measurements SHOULD performed on a per iteration The following tear down time[1] measurements MUST only include
basis. The tester MUST only include such measurements for which both connections for which both sides of the connection were successfully
sides of the connection were successfully torn down. For example, torn down. For example, tear down times for connections which are
tear down times for connections which are left in a FINWAIT-2[8] left in a FINWAIT-2[8] state should not be included:
state should not be included:
Minimum connection tear down time - Lowest TCP connection tear down Minimum connection tear down time - Lowest TCP connection tear down
time measured as defined in appendix C. time measured as defined in appendix C.
Maximum connection tear down time - Highest TCP connection tear down Maximum connection tear down time - Highest TCP connection tear down
time measured as defined in appendix C. time measured as defined in appendix C.
Average connection tear down time - The mean of all measurements of Average connection tear down time - The mean of all measurements of
connection tear down times. connection tear down times.
Aggregate connection tear down time - The total of all measurements Aggregate connection tear down time - The total of all measurements
of connection tear down times. of connection tear down times.
5.4.5 Reporting Format 5.4.5 Reporting Format
The test report MUST note the number of connections, age time and The test report MUST note the number of connections, aging time,
close method, close direction, minimum TCP connection tear down
time, maximum TCP connection tear down time, average TCP connection
tear down time and the aggregate TCP connection tear down time and
highest connection tear down rate measured. highest connection tear down rate measured.
The intermediate results of the search algorithm SHOULD be reported The intermediate results of the search algorithm MAY be reported
in the format of a table with a column for each iteration. There in the format of a table with a column for each iteration. There
SHOULD be rows for the number of TCP tear downs attempted, number SHOULD be rows for the number of TCP tear downs attempted, number
of TCP connection tear downs completed, minimum TCP connection tear and percentage of TCP connection tear downs completed, minimum
down time, maximum TCP connection tear down time, average TCP TCP connection tear down time, maximum TCP connection tear down
connection tear down time and the aggregate TCP connection tear down time, average TCP connection tear down time, aggregate TCP
time. connection tear down time and validation failures, if required.
5.5 Denial Of Service Handling 5.5 Denial Of Service Handling
5.5.1 Objective 5.5.1 Objective
To determine the effect of a denial of service attack on a DUT/SUT To determine the effect of a denial of service attack on a DUT/SUT
TCP connection establishment and/or HTTP transfer rates. The denial TCP connection establishment and/or HTTP transfer rates. The denial
of service handling test MUST be run after obtaining baseline of service handling test MUST be run after obtaining baseline
measurements from sections 5.3 and/or 5.6. measurements from sections 5.3 and/or 5.6.
skipping to change at page 14, line 54 skipping to change at page 14, line 57
server(s) IP address or NAT proxy address at a rate defined by SYN server(s) IP address or NAT proxy address at a rate defined by SYN
attack rate. attack rate.
The tester originating the TCP SYN attack MUST be attached to the The tester originating the TCP SYN attack MUST be attached to the
unprotected network. In addition, the tester MUST not respond to the unprotected network. In addition, the tester MUST not respond to the
SYN/ACK packets sent by target server or NAT proxy in response to SYN/ACK packets sent by target server or NAT proxy in response to
the SYN packet. the SYN packet.
Some firewalls employ mechanisms to guard against SYN attacks. If Some firewalls employ mechanisms to guard against SYN attacks. If
such mechanisms exist on the DUT/SUT, tests SHOULD be run with these such mechanisms exist on the DUT/SUT, tests SHOULD be run with these
mechanisms enabled to determine how well the DUT/SUT can maintain, mechanisms enabled and disabled to determine how well the DUT/SUT
under such attacks, the baseline connection establishment rates and can maintain, under such attacks, the baseline connection
HTTP transfer rates determined in section 5.3 and section 5.6, establishment rates and HTTP transfer rates determined in section
respectively. 5.3 and section 5.6, respectively.
5.5.4 Measurements 5.5.4 Measurements
Perform the same measurements as defined in section 5.3.4 or 5.6.4, Perform the same measurements as defined in section 5.3.4 or 5.6.4,
depending on whether testing against the baseline TCP connection depending on whether testing against the baseline TCP connection
establishment rate test or HTTP transfer rate, respectfully. establishment rate test or HTTP transfer rate, respectfully.
In addition, the tester SHOULD track TCP SYN packets associated with In addition, the tester SHOULD track TCP SYN packets associated with
the SYN attack which the DUT/SUT forwards on the protected or DMZ the SYN attack which the DUT/SUT forwards on the protected or DMZ
interface(s). interface(s).
skipping to change at page 15, line 43 skipping to change at page 15, line 46
the DUT/SUT. the DUT/SUT.
5.6.2 Setup Parameters 5.6.2 Setup Parameters
The following parameters MUST be defined for all tests: The following parameters MUST be defined for all tests:
5.6.2.1 Transport-Layer Setup Parameters 5.6.2.1 Transport-Layer Setup Parameters
Number of connections - Defines the aggregate number of connections Number of connections - Defines the aggregate number of connections
attempted. The number SHOULD be a multiple of the number of virtual attempted. The number SHOULD be a multiple of the number of virtual
clients participating in the test clients participating in the test.
Close Method - Defines method for closing TCP connections. The 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.
Close Direction - Defines whether closing of connections are to be
initiated from the client or from the server.
5.6.2.2 Application-Layer Setup Parameters 5.6.2.2 Application-Layer Setup Parameters
Session type - The virtual clients/servers MUST use HTTP 1.1 or Session Type - The virtual clients/servers MUST use HTTP 1.1 or
higher. higher.
GET requests per connection - Defines the number of HTTP 1.1 or GET requests per connection - Defines the number of HTTP 1.1 or
higher GET requests attempted per connection. higher GET requests attempted per connection.
Object Size - Defines the number of bytes, excluding any bytes Object Size - Defines the number of bytes, excluding any bytes
associated with the HTTP header, to be transferred in response to an associated with the HTTP header, to be transferred in response to an
HTTP 1.1 or higher GET request. HTTP 1.1 or higher GET request.
5.6.3 Procedure 5.6.3 Procedure
Each HTTP 1.1 or higher client will request one or more objects from Each HTTP 1.1 or higher virtual client will request one or more
an HTTP 1.1 or higher server using one or more HTTP GET requests. objects from an HTTP 1.1 or higher server using one or more HTTP
The aggregate number of connections attempted, defined by number of GET requests over each connection. The aggregate number of
connections, MUST be evenly divided among all of the participating connections attempted, defined by number of connections, MUST be
virtual clients. evenly divided among all of the participating virtual clients.
If the virtual client(s) make multiple HTTP GET requests per If the virtual client(s) make multiple HTTP GET requests per
connection, it MUST request the same object size for each GET connection, it MUST request the same object size for each GET
request. Multiple iterations of this test SHOULD be ran using request. Multiple iterations of this test may be run with objects
different object sizes. of different sizes.
5.6.4 Measurements 5.6.4 Measurements
5.6.4.1 Application-Layer measurements 5.6.4.1 Application-Layer measurements
Average Transfer Rate - The average transfer rate of the DUT/SUT Average Transfer Rate - The average transfer rate of the DUT/SUT
MUST be measured and shall be referenced to the requested object(s). MUST be measured and shall be referenced to the requested object(s).
The measurement will start on transmission of the first bit of the The measurement will start on transmission of the first bit of the
first requested object and end on transmission of the last bit of first requested object and end on transmission of the last bit of
the last requested object. The average transfer rate, in bits per the last requested object. The average transfer rate, in bits per
skipping to change at page 16, line 43 skipping to change at page 16, line 55
OBJECTS - Total number of objects successfully transferred across OBJECTS - Total number of objects successfully transferred across
all connections. all connections.
OBJECTSIZE - Object size in bytes OBJECTSIZE - Object size in bytes
DURATION - Aggregate transfer time based on aforementioned time DURATION - Aggregate transfer time based on aforementioned time
references. references.
5.6.4.2 Measurements at or below the Transport-Layer 5.6.4.2 Measurements at or below the Transport-Layer
The tester SHOULD make goodput[1] measurements for connection- The following measurements SHOULD be performed for each connection-
oriented protocols at or below the transport layer. Goodput oriented protocol:
measurements MUST only reference the protocols payload, excluding
any of the protocols header. In addition, the tester MUST exclude Goodput[1] - Goodput as defined in section 3.17 of RFC2647.
any bits associated with the connection establishment, connection
tear down, security associations or connection maintenance.
Measurements MUST only reference the protocol payload, excluding
any of the protocol header. In addition, the tester MUST exclude
any bits associated with the connection establishment, connection
tear down, security associations[1] or connection maintenance[1].
Since connection-oriented protocols require that data be Since connection-oriented protocols require that data be
acknowledged, the offered load[6] will vary over the duration of the acknowledged, the offered load[6] will be varying. Therefore, the
test. When performing forwarding rate measurements, the tester tester should measure the average forwarding rate over the
should measure the average forwarding rate over the duration of the duration of the test. Measurement should start on transmission of
test. the first bit of the payload of the first datagram and end on
transmission of the last bit of the payload of the last datagram.
Number of bytes transferred - Total payload bytes transferred.
Number of Timeouts - Total number of timeout events.
Retransmitted bytes - Total number of retransmitted bytes.
5.6.5 Reporting Format 5.6.5 Reporting Format
5.6.5.1 Application-Layer reporting 5.6.5.1 Application-Layer reporting
The test report MUST note number of GET requests per connection and The test report MUST note number of GET requests per connection and
object size. object size(s).
The transfer rate results SHOULD be reported in tabular form with a The transfer rate results SHOULD be reported in tabular form with a
row for each of the object sizes. There SHOULD be a column for the column for each of the object sizes tested. There SHOULD be a row
object size, the number of completed requests, the number of for the object size, number and percentage of completed requests,
completed responses, and the transfer rate results for each test. number and percentage of completed responses, and the resultant
transfer rate for each iteration of the test.
Failure analysis: Failure analysis:
The test report SHOULD indicate the number and percentage of HTTP The test report SHOULD indicate the number and percentage of HTTP
GET request or responses that failed to complete. GET request and responses that failed to complete.
Version information: Version information:
The test report MUST note the version of HTTP client(s) and The test report MUST note the version of HTTP client(s) and
server(s). server(s).
5.6.5.2 Transport-Layer and below reporting 5.6.5.2 Transport-Layer and below reporting
The test report MUST note the aggregate number of connections. In The test report MUST note the number of connections, close method,
addition, the report MUST identify the protocol for which the close direction and the protocol for which the measurement was
measurement was made. made.
The results SHOULD be in tabular form with a column for each The results SHOULD be reported in tabular form for each of the HTTP
iteration of the test. There should be columns for transmitted bits, object sizes tested. There SHOULD be a row for the HTTP object size,
retransmitted bits and the measured goodput. resultant goodput, total timeouts, total retransmitted bytes and
total bytes transferred. Note that total bytes refers to total
datagram payload bytes transferred. The table MAY be combined with
the application layer reporting, provided the table clearly identify
the protocol for which the measurement was made.
Failure analysis: Failure analysis:
The test report SHOULD indicate the number and percentage of The test report SHOULD indicate the number and percentage of
connections that failed to complete. connection establishment failures as well as number and percentage
of TCP tear down failures.
5.7 HTTP Concurrent Transaction Capacity It is RECOMMENDED that the report include a graph to plot the
distribution of both connection establishment failures and
connection tear down failures. The x coordinate SHOULD be the
elapsed test time, the y coordinate SHOULD be the number of failures
for a given sampling period. There SHOULD be two lines on the graph,
one for connection failures and one for tear down failures. The
graph MUST note the sampling period.
5.7 Maximum HTTP Transaction Rate
5.7.1 Objective 5.7.1 Objective
Determine the maximum number of concurrent or simultaneous HTTP Determine the maximum transaction rate the DUT/SUT can sustain.
transactions the DUT/SUT can support. This test is intended to This test is intended to find the maximum rate at which users can
find the maximum number of users that can simultaneously access access objects.
web objects.
5.7.2 Setup Parameters 5.7.2 Setup Parameters
GET request rate - The aggregate rate, expressed in request per 5.7.2.1 Transport-Layer Setup Parameters
second, at which HTTP 1.1 or higher GET requests are offered by the
virtual client(s).
Session type - The virtual clients/servers MUST use HTTP 1.1 or
higher.
5.7.3 Procedure
An iterative search algorithm MAY be used to determine the maximum
HTTP concurrent transaction capacity.
For each iteration, the virtual client(s) will vary the number of
concurrent or simultaneous HTTP transactions - that is, on-going
GET requests. The HTTP 1.1 or higher virtual client(s) will request
one object, across each connection, from an HTTP 1.1 or higher
server using one HTTP GET request. The aggregate rate at which the
virtual client(s) will offer the requests will be defined by GET
request rate.
The object size requested MUST be large enough, such that, the
transaction - that is, the request/response cycle -- will exist for
the duration of the test. At the end of each iteration, the tester
MUST validate that all transactions are still active. After all of
the transactions are checked, the transactions MAY be aborted.
5.7.4 Measurements
Maximum concurrent transactions - Total number of concurrent HTTP
transactions active for the last successful iteration performed in
the search algorithm.
5.7.5 Reporting Format
5.7.5.1 Application-Layer reporting
The test report MUST note the GET request rate and the maximum
concurrent transactions measured.
The intermediate results of the search algorithm MAY be reported
in a table format with a column for each iteration. There SHOULD be
rows for the number of concurrent transactions attempted, GET
request rate, number of aborted transactions and number of
transactions active at the end of the test iteration.
Version information:
The test report MUST note the version of HTTP client(s) and
server(s).
5.8 Maximum HTTP Transaction Rate
5.8.1 Objective Close Method - Defines method for closing TCP connections. The 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.
Determine the maximum HTTP transaction rate that a DUT/SUT can Close Direction - Defines whether closing of connections are to be
sustain. initiated from the client or from the server.
5.8.2 Setup Parameters 5.7.2.2 Application-Layer Setup Parameters
Session Type - HTTP 1.1 or higher MUST be used for this test. Session Type - HTTP 1.1 or higher MUST be used for this test.
Test Duration - Time, expressed in seconds, for which the Test Duration - Time, expressed in seconds, for which the
virtual client(s) will sustain the attempted GET request rate. virtual client(s) will sustain the attempted GET request rate.
It is RECOMMENDED that the duration be at least 30 seconds. It is RECOMMENDED that the duration be at least 30 seconds.
Requests per connection - Number of object requests per connection. Requests per connection - Number of object requests per connection.
Object Size - Defines the number of bytes, excluding any bytes Object Size - Defines the number of bytes, excluding any bytes
associated with the HTTP header, to be transferred in response to an associated with the HTTP header, to be transferred in response to an
HTTP 1.1 or higher GET request. HTTP 1.1 or higher GET request.
5.8.3 Procedure 5.7.3 Procedure
An iterative search algorithm MAY be used to determine the maximum An iterative search algorithm MAY be used to determine the maximum
transaction rate that the DUT/SUT can sustain. transaction rate that the DUT/SUT can sustain.
For each iteration, HTTP 1.1 or higher virtual client(s) will For each iteration, HTTP 1.1 or higher virtual client(s) will
vary the aggregate GET request rate offered to HTTP 1.1 or higher vary the aggregate GET request rate offered to HTTP 1.1 or higher
server(s). The virtual client(s) will maintain the offered request server(s). The virtual client(s) will maintain the offered request
rate for the defined test duration. rate for the defined test duration.
If the tester makes multiple HTTP GET requests per connection, it If the virtual client(s) make multiple HTTP GET requests per
MUST request the same object size for each GET request rate. connection, it MUST request the same object size for each GET
Multiple iterations of this test MAY be performed with objects of request. Multiple tests MAY be performed with different object
different sizes. sizes.
5.8.4 Measurements 5.7.4 Measurements
Maximum Transaction Rate - The maximum rate at which all Maximum Transaction Rate - The maximum rate at which all
transactions -- that is all requests/responses cycles -- are transactions -- that is all requests/responses cycles -- are
completed. completed.
Transaction Time - The tester SHOULD measure minimum, maximum and Transaction Time - The tester SHOULD measure minimum, maximum and
average transaction times. The transaction time will start when the average transaction times. The transaction time will start when the
virtual client issues the GET request and end when the requesting virtual client issues the GET request and end when the requesting
virtual client receives the last bit of the requested object. virtual client receives the last bit of the requested object.
5.8.5 Reporting Format 5.7.5 Reporting Format
5.7.5.1 Application-Layer reporting
The test report MUST note the test duration, object size, requests The test report MUST note the test duration, object size, requests
per connection and the measured minimum, maximum and average per connection and the measured minimum, maximum and average
transaction rate. transaction rate.
The intermediate results of the search algorithm MAY be reported The intermediate results of the search algorithm MAY be reported
in a table format with a column for each iteration. There SHOULD be in a table format with a column for each iteration. There SHOULD be
rows for the GET request attempt rate, number of requests attempted, rows for the GET request attempt rate, number of requests attempted,
number and percentage of requests completed, number of responses number and percentage of requests completed, number of responses
attempted, number and percentage of responses completed, minimum attempted, number and percentage of responses completed, minimum
transaction time, average transaction time and maximum transaction transaction time, average transaction time and maximum transaction
time. time.
Version information: Version information:
The test report MUST note the version of HTTP client(s) and The test report MUST note the version of HTTP client(s) and
server(s). server(s).
5.9 Illegal Traffic Handling 5.7.5.2 Transport-Layer
5.9.1 Objective The test report MUST note the close method, close direction, number
of connections established and number of connections torn down.
To determine the behavior of the DUT/SUT when presented with a The intermediate results of the search algorithm MAY be reported
combination of both legal and Illegal traffic. Note that Illegal in a table format with a column for each iteration. There SHOULD be
rows for the number of connections attempted, number and percentage
of connections completed, number and percentage of connection tear
downs completed. The table MAY be combined with the application
layer reporting, provided the table identify this as transport layer
measurement.
5.8 Illegal Traffic Handling
5.8.1 Objective
To character the behavior of the DUT/SUT when presented with a
combination of both legal and Illegal[1] traffic. Note that Illegal
traffic does not refer to an attack, but traffic which has been traffic does not refer to an attack, but traffic which has been
explicitly defined by a rule(s) to drop. explicitly defined by a rule(s) to drop.
5.9.2 Setup Parameters 5.8.2 Setup Parameters
Setup parameters will use the same parameters as specified in the Setup parameters will use the same parameters as specified in the
HTTP transfer rate test(Section 5.6.2). In addition, the following HTTP transfer rate test(Section 5.6.2). In addition, the following
setup parameters MUST be defined: setup parameters MUST be defined:
Illegal traffic percentage - Percentage of HTTP 1.1 or higher Illegal traffic percentage - Percentage of HTTP 1.1 or higher
connections which have been explicitly defined in a rule(s) to drop. connections which have been explicitly defined in a rule(s) to drop.
5.9.3 Procedure 5.8.3 Procedure
Each HTTP 1.1 or higher client will request one or more objects from Each HTTP 1.1 or higher client will request one or more objects from
an HTTP 1.1 or higher server using one or more HTTP GET requests. an HTTP 1.1 or higher server using one or more HTTP GET requests
The aggregate number of connections attempted, defined by number of over each connection. The aggregate number of connections attempted,
connections, MUST be evenly divided among all of the participating defined by number of connections, MUST be evenly divided among all
virtual clients. of the participating virtual clients.
The virtual client(s) MUST offer the connection requests, both legal The virtual client(s) MUST offer the connection requests, both legal
and illegal, in an evenly distributed manner. Many firewalls have and illegal, in an evenly distributed manner. Many firewalls have
the capability to filter on different traffic criteria( IP the capability to filter on different traffic criteria( IP
addresses, Port numbers, etc). Testers may run multiple addresses, Port numbers, etc). Multiple iterations of this test MAY
iterations of this test with the DUT/SUT configured to filter be run with the DUT/SUT configured to filter on different traffic
on different traffic criteria. criteria.
5.9.4 Measurements 5.8.4 Measurements
Tester SHOULD perform the same measurements as defined in HTTP The same measurements as defined in HTTP transfer rate test(Section
transfer rate test(Section 5.6.4). Unlike the HTTP transfer rate 5.6.4) SHOULD be performed. Any forwarding rate measurements MUST
test, the tester MUST not include any bits which are associated only include bits which are associated with legal traffic.
with illegal traffic in its forwarding rate measurements.
5.9.5 Reporting Format 5.8.5 Reporting Format
Test report SHOULD be the same as specified in the HTTP Test reporting format SHOULD be the same as specified in the HTTP
test(Section 5.6.5). transfer rate test(Section 5.6.5).
In addition, the report MUST note the percentage of illegal HTTP In addition, the report MUST note the percentage of illegal HTTP
connections. connections.
Failure analysis: Failure analysis:
Test report MUST note the number and percentage of illegal Test report MUST note the number and percentage of illegal
connections that were allowed by the DUT/SUT. connections that were allowed by the DUT/SUT.
5.10 IP Fragmentation Handling 5.9 IP Fragmentation Handling
5.10.1 Objective 5.9.1 Objective
To determine the performance impact when the DUT/SUT is presented To determine the performance impact when the DUT/SUT is presented
with IP fragmented[5] traffic. IP packets which have been with IP fragmented[5] traffic. IP packets which have been
fragmented, due to crossing a network that supports a smaller fragmented, due to crossing a network that supports a smaller
MTU(Maximum Transmission Unit) than the actual IP packet, may MTU(Maximum Transmission Unit) than the actual IP packet, may
require the firewall to perform re-assembly prior to the rule set require the firewall to perform re-assembly prior to the rule set
being applied. being applied.
While IP fragmentation is a common form of attack, either on the While IP fragmentation is a common form of attack, either on the
firewall itself or on internal hosts, this test will focus on firewall itself or on internal hosts, this test will focus on
determining how the additional processing associated with the determining how the additional processing associated with the
re-assembly of the packets have on the forwarding rate of the re-assembly of the packets have on the forwarding rate of the
DUT/SUT. RFC 1858 addresses some fragmentation attacks that DUT/SUT. RFC 1858 addresses some fragmentation attacks that
get around IP filtering processes used in routers and hosts. get around IP filtering processes used in routers and hosts.
5.10.2 Setup Parameters 5.9.2 Setup Parameters
The following parameters MUST be defined. The following parameters MUST be defined.
5.10.2.1 Non-Fragmented Traffic Parameters 5.9.2.1 Non-Fragmented Traffic Parameters
Setup parameters will be the same as defined in the HTTP transfer Setup parameters will be the same as defined in the HTTP transfer
rate test(Sections 5.6.2.1 and 5.6.2.2). rate test(Sections 5.6.2.1 and 5.6.2.2).
5.10.2.2 Fragmented Traffic Parameters 5.9.2.2 Fragmented Traffic Parameters
Packet size - Number of bytes in the IP/UDP packet, exclusive of Packet size - Number of bytes in the IP/UDP packet, exclusive of
link-layer headers and checksums, prior to fragmentation. link-layer headers and checksums, prior to fragmentation.
MTU - Maximum transmission unit, expressed in bytes. For testing MTU - Maximum transmission unit, expressed in bytes. For testing
purposes, this MAY be configured to values smaller than the MTU purposes, this MAY be configured to values smaller than the MTU
supported by the link layer. supported by the link layer.
Intended Load - Intended load, expressed as percentage of media Intended Load - Intended load, expressed as percentage of media
utilization. utilization.
5.10.3 Procedure 5.9.3 Procedure
Each HTTP 1.1 or higher client will request one or more objects from Each HTTP 1.1 or higher client will request one or more objects from
an HTTP 1.1 or higher server using one or more HTTP GET requests. an HTTP 1.1 or higher server using one or more HTTP GET requests
The aggregate number of connections attempted, defined by number of over each connection. The aggregate number of connections attempted,
connections, MUST be evenly divided among all of the participating defined by number of connections, MUST be evenly divided among all
virtual clients. If the virtual client(s) make multiple HTTP GET of the participating virtual clients. If the virtual client(s) make
requests per connection, it MUST request the same object size for multiple HTTP GET requests per connection, it MUST request the same
each GET request. object size for each GET request.
A tester attached to the unprotected side of the network, will offer A tester attached to the unprotected side of the network, will offer
a unidirectional stream of unicast fragmented IP/UDP traffic, a unidirectional stream of unicast fragmented IP/UDP traffic,
targeting a server attached to either the protected or DMZ segment. targeting a server attached to either the protected or DMZ segment.
The tester MUST offer the unidirectional stream over the duration of The tester MUST offer the unidirectional stream over the duration of
the test -- that is, duration over which the HTTP traffic is being the test -- that is, duration over which the HTTP traffic is being
offered. offered.
Baseline measurements SHOULD be performed with IP filtering deny Baseline measurements SHOULD be performed with IP filtering deny
rule(s) to filter fragmented traffic. If the DUT/SUT has logging rule(s) to filter fragmented traffic. If the DUT/SUT has logging
skipping to change at page 22, line 26 skipping to change at page 22, line 20
The test SHOULD be repeated with the DUT/SUT rule set changed to The test SHOULD be repeated with the DUT/SUT rule set changed to
allow the fragmented traffic through. When running multiple allow the fragmented traffic through. When running multiple
iterations of the test, it is RECOMMENDED to vary the MTU while iterations of the test, it is RECOMMENDED to vary the MTU while
keeping all other parameters constant. keeping all other parameters constant.
Then setup the DUT/SUT to the policy or rule set the manufacturer Then setup the DUT/SUT to the policy or rule set the manufacturer
required to be defined to protect against fragmentation attacks and required to be defined to protect against fragmentation attacks and
repeat the measurements outlined in the baseline procedures. repeat the measurements outlined in the baseline procedures.
5.10.4 Measurements 5.9.4 Measurements
Tester SHOULD perform the same measurements as defined in HTTP Tester SHOULD perform the same measurements as defined in HTTP
test(Section 5.6.4). test(Section 5.6.4).
Transmitted UDP/IP Packets - Number of UDP packets transmitted by Transmitted UDP/IP Packets - Number of UDP packets transmitted by
client. client.
Received UDP/IP Packets - Number of UDP/IP Packets received by Received UDP/IP Packets - Number of UDP/IP Packets received by
server. server.
5.10.5 Reporting Format 5.9.5 Reporting Format
5.10.1 Non-Fragmented Traffic 5.10.1 Non-Fragmented Traffic
The test report SHOULD be the same as described in section 5.6.5. The test report SHOULD be the same as described in section 5.6.5.
Note that any forwarding rate measurements for the HTTP traffic Note that any forwarding rate measurements for the HTTP traffic
excludes any bits associated with the fragmented traffic which excludes any bits associated with the fragmented traffic which
may be forward by the DUT/SUT. may be forward by the DUT/SUT.
5.10.2 Fragmented Traffic 5.9.2 Fragmented Traffic
The test report MUST note the packet size, MTU size, intended load, The test report MUST note the packet size, MTU size, intended load,
number of UDP/IP packets transmitted and number of UDP/IP packets number of UDP/IP packets transmitted and number of UDP/IP packets
forwarded. The test report SHOULD also note whether or not the forwarded. The test report SHOULD also note whether or not the
DUT/SUT forwarded the offered UDP/IP traffic fragmented. DUT/SUT forwarded the offered UDP/IP traffic fragmented.
5.11 Latency 5.10 Latency
5.11.1 Objective 5.10.1 Objective
To determine the latency of network-layer or application-layer data To determine the latency of network-layer or application-layer data
traversing the DUT/SUT. RFC 1242 [3] defines latency. traversing the DUT/SUT. RFC 1242 [3] defines latency.
5.11.2 Setup Parameters 5.10.2 Setup Parameters
The following parameters MUST be defined: The following parameters MUST be defined:
5.11.2.1 Network-layer Measurements 5.10.2.1 Network-layer Measurements
Packet size, expressed as the number of bytes in the IP packet, Packet size, expressed as the number of bytes in the IP packet,
exclusive of link-layer headers and checksums. exclusive of link-layer headers and checksums.
Intended load, expressed as percentage of media utilization. Intended load, expressed as percentage of media utilization.
Test duration, expressed in seconds. Test duration, expressed in seconds.
Test instruments MUST generate packets with unique timestamp Test instruments MUST generate packets with unique timestamp
signatures. signatures.
5.11.2.2 Application-layer Measurements 5.10.2.2 Application-layer Measurements
Object Size - Defines the number of bytes, excluding any bytes Object Size - Defines the number of bytes, excluding any bytes
associated with the HTTP header, to be transferred in response to associated with the HTTP header, to be transferred in response to
an HTTP 1.1 or higher GET request. Testers SHOULD use the minimum an HTTP 1.1 or higher GET request. Testers SHOULD use the minimum
object size supported by the media, but MAY use other object object size supported by the media, but MAY use other object
sizes as well. sizes as well.
Connection type. The tester MUST use one HTTP 1.1 or higher Connection type. The tester MUST use one HTTP 1.1 or higher
connection for latency measurements. connection for latency measurements.
Number of objects requested. Number of objects requested.
Number of objects transferred. Number of objects transferred.
Test duration, expressed in seconds. Test duration, expressed in seconds.
Test instruments MUST generate packets with unique timestamp Test instruments MUST generate packets with unique timestamp
signatures. signatures.
5.11.3 Network-layer procedure 5.10.3 Network-layer procedure
A client will offer a unidirectional stream of unicast packets to a A client will offer a unidirectional stream of unicast packets to a
server. The packets MUST use a connectionless protocol like IP or server. The packets MUST use a connectionless protocol like IP or
UDP/IP. UDP/IP.
The tester MUST offer packets in a steady state. As noted in the The tester MUST offer packets in a steady state. As noted in the
latency discussion in RFC 2544 [4], latency measurements MUST be latency discussion in RFC 2544 [4], latency measurements MUST be
taken at the throughput level -- that is, at the highest offered taken at the throughput level -- that is, at the highest offered
load with zero packet loss. Measurements taken at the throughput load with zero packet loss. Measurements taken at the throughput
level are the only ones that can legitimately be termed latency. level are the only ones that can legitimately be termed latency.
It is RECOMMENDED that implementers use offered loads not only at It is RECOMMENDED that implementers use offered loads not only at
the throughput level, but also at load levels that are less than the throughput level, but also at load levels that are less than
or greater than the throughput level. To avoid confusion with or greater than the throughput level. To avoid confusion with
existing terminology, measurements from such tests MUST be labeled existing terminology, measurements from such tests MUST be labeled
as delay rather than latency. as delay rather than latency.
It is RECOMMENDED to perform the latency measurements with different
packet sizes. When testing with different packet sizes the DUT/SUT
configuration MUST remain the same.
If desired, the tester MAY use a step test in which offered loads If desired, the tester MAY use a step test in which offered loads
increment or decrement through a range of load levels. increment or decrement through a range of load levels.
The duration of the test portion of each trial MUST be at least 30 The duration of the test portion of each trial MUST be at least 30
seconds. seconds.
5.11.4 Application layer procedure 5.10.4 Application layer procedure
An HTTP 1.1 or higher client will request one or more objects from An HTTP 1.1 or higher client will request one or more objects from
an HTTP or higher 1.1 server using one or more HTTP GET requests. If an HTTP or higher 1.1 server using one or more HTTP GET requests. If
the tester makes multiple HTTP GET requests, it MUST request the the tester makes multiple HTTP GET requests, it MUST request the
same-sized object each time. Testers may run multiple iterations of same-sized object each time. Testers may run multiple iterations of
this test with objects of different sizes. this test with objects of different sizes.
Implementers MAY configure the tester to run for a fixed duration. Implementers MAY configure the tester to run for a fixed duration.
In this case, the tester MUST report the number of objects requested In this case, the tester MUST report the number of objects requested
and returned for the duration of the test. For fixed-duration tests and returned for the duration of the test. For fixed-duration tests
it is RECOMMENDED that the duration be at least 30 seconds. it is RECOMMENDED that the duration be at least 30 seconds.
5.11.5 Measurements 5.10.5 Measurements
Minimum delay - The smallest delay incurred by data traversing the Minimum delay - The smallest delay incurred by data traversing the
DUT/SUT at the network layer or application layer, as appropriate. DUT/SUT at the network layer or application layer, as appropriate.
Maximum delay - The largest delay incurred by data traversing the Maximum delay - The largest delay incurred by data traversing the
DUT/SUT at the network layer or application layer, as appropriate. DUT/SUT at the network layer or application layer, as appropriate.
Average delay - The mean of all measurements of delay incurred by Average delay - The mean of all measurements of delay incurred by
data traversing the DUT/SUT at the network layer or application data traversing the DUT/SUT at the network layer or application
layer, as appropriate. layer, as appropriate.
Delay distribution - A set of histograms of all delay measurements Delay distribution - A set of histograms of all delay measurements
observed for data traversing the DUT/SUT at the network layer or observed for data traversing the DUT/SUT at the network layer or
application layer, as appropriate. application layer, as appropriate.
5.11.6 Network-layer reporting format 5.10.6 Network-layer reporting format
The test report MUST note the packet size(s), offered load(s) and The test report MUST note the packet size(s), offered load(s) and
test duration used. test duration used.
The latency results SHOULD be reported in the format of a table with The latency results SHOULD be reported in the format of a table with
a row for each of the tested packet sizes. There SHOULD be columns a row for each of the tested packet sizes. There SHOULD be columns
for the packet size, the intended rate, the offered rate, and the for the packet size, the intended rate, the offered rate, and the
resultant latency or delay values for each test. resultant latency or delay values for each test.
5.11.7 Application-layer reporting format 5.10.7 Application-layer reporting format
The test report MUST note the object size(s) and number of requests The test report MUST note the object size(s) and number of requests
and responses completed. If applicable, the report MUST note the and responses completed. If applicable, the report MUST note the
test duration if a fixed duration was used. test duration if a fixed duration was used.
The latency results SHOULD be reported in the format of a table with The latency results SHOULD be reported in the format of a table with
a row for each of the object sizes. There SHOULD be columns for the a row for each of the object sizes. There SHOULD be columns for the
object size, the number of completed requests, the number of object size, the number of completed requests, the number of
completed responses, and the resultant latency or delay values for completed responses, and the resultant latency or delay values for
each test. each test.
skipping to change at page 28, line 18 skipping to change at page 28, line 18
t3: Proxy establishes separate connection with server. t3: Proxy establishes separate connection with server.
t4: Client sends TCP datagram to server. t4: Client sends TCP datagram to server.
*t5: Proxy sends ACK of the datagram to client. *t5: Proxy sends ACK of the datagram to client.
* While t5 is not considered part of the TCP connection * While t5 is not considered part of the TCP connection
establishment, acknowledgement of t4 must be received for the establishment, acknowledgement of t4 must be received for the
connection to be considered successful. connection to be considered successful.
APPENDIX C: Connection Tear Time Measurements APPENDIX C: Connection Tear Time Measurements
While TCP connections are full duplex, tearing down of such connections While TCP connections are full duplex, tearing down of such
are performed in a simplex fashion -- that is, FIN segments are sent by connections are performed in a simplex fashion -- that is - FIN
each host/device terminating each side of the TCP connection. segments are sent by each host/device terminating each side of
the TCP connection.
When making connection tear down times measurements, such measurements When making connection tear down times measurements, such
will be made from the perspective of the client and will be performed measurements will be made from the perspective of the entity - that
in the same manner, independent of whether or not the DUT/SUT is is -- virtual client/server initiating the connection tear down
proxy-based. The connection tear down will be considered the interval request. In addition, the measurement will be performed in the same
between the transmission of the first bit of the first TCP FIN packet manner, independent of whether or not the DUT/SUT is proxy-based.
transmitted by the tester requesting a connection tear down to receipt The connection tear down will be considered the interval between the
of the last bit of the corresponding ACK packet on the same tester transmission of the first bit of the first TCP FIN packet transmitted
interface. by the virtual client or server, whichever is applicable, requesting
a connection tear down to receipt of the last bit of the
corresponding ACK packet on the same virtual client/server interface.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/