Benchmarking Methodology for Network Interconnect Devices
RFC 2544
| Document | Type |
RFC
- Informational
(March 1999)
Errata
Obsoletes RFC 1944
|
|
|---|---|---|---|
| Authors | |||
| Last updated | 2020-01-21 | ||
| RFC stream | Legacy stream | ||
| Formats | |||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 2544
Internet Engineering Task Force N. Elkins
Internet-Draft Inside Products, Inc.
Intended status: Standards Track M. Ackermann
Expires: 28 August 2024 BCBS Michigan
A. Deshpande
NITK Surathkal/Google
T. Pecorella
University of Florence
A. Rashid
Politecnico di Bari
25 February 2024
IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination
Option
draft-ietf-ippm-encrypted-pdmv2-06
Abstract
RFC8250 describes an optional Destination Option (DO) header embedded
in each packet to provide sequence numbers and timing information as
a basis for measurements. As this data is sent in clear-text, this
may create an opportunity for malicious actors to get information for
subsequent attacks. This document defines PDMv2 which has a
lightweight handshake (registration procedure) and encryption to
secure this data. Additional performance metrics which may be of use
are also defined.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://ameyand.github.io/PDMv2/draft-elkins-ippm-encrypted-
pdmv2.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/.
Discussion of this document takes place on the IP Performance
Measurement Working Group mailing list (mailto:ippm@ietf.org), which
is archived at https://mailarchive.ietf.org/arch/browse/ippm/.
Subscribe at https://www.ietf.org/mailman/listinfo/ippm/.
Source for this draft and an issue tracker can be found at
https://github.com/ameyand/PDMv2.
Elkins, et al. Expires 28 August 2024 [Page 1]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Client - Server Negotiation . . . . . . . . . . . . . . . 5
4.2. Implementation Guidelines . . . . . . . . . . . . . . . . 6
4.2.1. Use Case 1: Server does not understand PDM or
PDMv2 . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. Use Case 2: Server does not allow PDM or PDMv2 . . . 6
5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Security Goals for Confidentiality . . . . . . . . . . . 7
5.2. Security Goals for Integrity . . . . . . . . . . . . . . 7
5.3. Security Goals for Authentication . . . . . . . . . . . . 8
5.4. Cryptographic Algorithm . . . . . . . . . . . . . . . . . 8
6. PDMv2 Destination Options . . . . . . . . . . . . . . . . . . 8
Elkins, et al. Expires 28 August 2024 [Page 2]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
6.1. Destinations Option Header . . . . . . . . . . . . . . . 8
6.2. Metrics information in PDMv2 . . . . . . . . . . . . . . 9
6.3. PDMv2 Layout . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Limited Threat Model . . . . . . . . . . . . . . . . . . 13
7.1.1. Passive attacks with unencrypted PDMv2 . . . . . . . 13
7.1.2. Passive attacks with encrypted PDMv2 . . . . . . . . 14
7.1.3. Active attacks with unencrypted PDMv2 . . . . . . . . 14
7.1.4. Active attacks with encrypted PDMv2 . . . . . . . . . 16
7.2. Topological considerations . . . . . . . . . . . . . . . 16
7.3. Further mitigations . . . . . . . . . . . . . . . . . . . 16
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Sample Implementation of Registration . . . . . . . 19
A.1. Overall summary . . . . . . . . . . . . . . . . . . . . . 19
A.2. High level flow . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The current PDM is an IPv6 Destination Options header which provides
information based on the metrics like Round-trip delay and Server
delay. This information helps to measure the Quality of Service
(QoS) and to assist in diagnostics. However, there are potential
risks involved transmitting PDM data during a diagnostics session.
PDM metrics can help an attacker understand about the type of machine
and its processing capabilities. Inferring from the PDM data, the
attack can launch a timing attack. For example, if a cryptographic
protocol is used, a timing attack may be launched against the keying
material to obtain the secret.
Along with this, PDM does not provide integrity. It is possible for
a Machine-In-The-Middle (MITM) node to modify PDM headers leading to
incorrect conclusions. For example, during the debugging process
using PDM header, it can mislead the person showing there are no
unusual server delays.
PDMv2 is an IPv6 Destination Options Extension Header which adds
confidentiality, integrity and authentication to PDM.
Elkins, et al. Expires 28 August 2024 [Page 3]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
The procedures specified in RFC8250 for header placement,
implementation, security considerations and so on continue to apply
for PDMv2.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
* Endpoint Node: Creates cryptographic keys in collaboration with a
partner.
* Client: An Endpoint Node which initiates a session with a
listening port on another Endpoint Node and sends PDM data.
* Server: An Endpoint Node which has a listening port and sends PDM
data to another Endpoint Node.
Note: a client may act as a server (have listening ports).
* Public and Private Keys: A pair of keys that is used in asymmetric
cryptography. If one is used for encryption, the other is used
for decryption. Private Keys are kept hidden by the source of the
key pair generator, but Public Key is known to everyone. pkX
(Public Key) and skX (Private Key). Where X can be, any client or
any server.
* Pre-shared Key (PSK): A symmetric key. Uniformly random
bitstring, shared between any Client or any Server or a key shared
between an entity that forms client-server relationship. This
could happen through an out-of band mechanism: e.g., a physical
meeting or use of another protocol.
* Session Key: A temporary key which acts as a symmetric key for the
whole session.
4. Protocol Flow
The protocol will proceed in 2 steps.
Step 1: Creation of cryptographic secrets between Server and Client.
This includes the creation of pkX and skX.
Elkins, et al. Expires 28 August 2024 [Page 4]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
Step 2: PDM data flow between Client and Server.
These steps MAY be in the same session or in separate sessions. That
is, the cryptographic secrets MAY be created beforehand and used in
the PDM data flow at the time of the "real" data session.
After-the-fact (or real-time) data analysis of PDM flow may occur by
network diagnosticians or network devices. The definition of how
this is done is out of scope for this document.
4.1. Client - Server Negotiation
The two entities exchange a set of data to ensure the respective
identities. This could be done via a TLS or other session. The
exact nature of the identity verification is out-of-scope for this
document.
They use Hybrid Public-Key Encryption scheme (HPKE) Key Encryption
Mechanism (KEM) to negotiate a "SharedSecret".
Each Client and Server derive a "SessionTemporaryKey" by using HPKE
Key Derivation Function (KDF), using the following inputs:
* The "SharedSecret".
* The 5-tuple (SrcIP, SrcPort, DstIP, DstPort, Protocol) of the
communication.
* An Epoch.
The Epoch SHOULD be initialized to zero. A change in the Epoch
indicates that the SessionTemporaryKey has been rotated.
When the Epoch rolls over, the SharedSecret SHOULD be re-negotiated.
The Epoch MUST be incremented when the Packet Sequence Number (PSN)
This Packet (PSNTP) is rolled over. It MAY be incremented earlier,
depending on the implementation and the security considerations.
The sender MUST NOT create two packets with identical PSNTP and
Epoch.
The SessionTemporaryKey using a KDF with the following inputs:
* SrcIP, SrcPort, DstIP, DstPort, Protocol, SharedSecret, Epoch.
Elkins, et al. Expires 28 August 2024 [Page 5]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
4.2. Implementation Guidelines
How should a network administrator decide whether a client should use
PDM, unencrypted PDMv2, or encrypted PDMv2? This decision is a
network policy issue. The administrator must be aware that PDM or
unencrypted PDMv2 might expose too much information to malicious
parties.
That said, if the network administrator decides that taking such a
risk within their network is acceptable, then they should make the
decision that is appropriate for their network.
Alternatively, the network administrator might choose to create a
policy that prohibits the use of PDM or unencrypted PDMv2 on their
network. The implementation SHOULD provide a way for the network
administrator to enforce such a policy.
The server and client implementations SHOULD support PDM, unencrypted
PDMv2, and encrypted PDMv2. If a client chooses a certain mechanism
(e.g., PDM), the server MAY respond with the same mechanism, unless
the network administrator has selected a policy that only allows
certain mechanisms on their network.
4.2.1. Use Case 1: Server does not understand PDM or PDMv2
If a client sends a packet with PDM or PDMv2 and the server does not
have code which understands the header, the packet is processed
according to the Option Type which is defined in RFC8250 and is in
accordance with RFC8200.
The Option Type identifiers is coded to skip over this option and
continue processing the header.
4.2.2. Use Case 2: Server does not allow PDM or PDMv2
If a client sends a packet with PDM and the network policy is to only
allow encrypted or unencrypted PDMv2, then the PDM / PDMv2 header
MUST be ignored and processing continue normally.
The server SHOULD log such occurrences but MUST apply rate limiting
to any such logs. The implementor should be aware that logging or
returning of error messages can be used in a Denial of Service
reflector attack. An attacker might send many packets with PDM /
PDMv2 and cause the receiver to experience resource exhaustion.
The routers involved may have implemented filtering as per [RFC9288]
on filtering of IPv6 extension headers which may impact the receipt
of PDM / PDMv2. The organization which manages the network within
Elkins, et al. Expires 28 August 2024 [Page 6]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
which PDM / PDMv2 is sent should take care that the filtering of
extension headers is done correctly so that the desired effect is
obtained.
5. Security Goals
As discussed in the introduction, PDM data can represent a serious
data leakage in presence of a malicious actor.
In particular, the sequence numbers included in the PDM header allows
correlating the traffic flows, and the timing data can highlight the
operational limits of a server to a malicious actor. Moreover,
forging PDM headers can lead to unnecessary, unwanted, or dangerous
operational choices, e.g., to restore an apparently degraded Quality
of Service (QoS).
Due to this, it is important that the confidentiality and integrity
of the PDM headers is maintained. PDM headers can be encrypted and
authenticated using the methods discussed in Section 5.4, thus
ensuring confidentiality and integrity. However, if PDM is used in a
scenario where the integrity and confidentiality is already ensured
by other means, they can be transmitted without encryption or
authentication. This includes, but is not limited to, the following
cases:
a) PDM is used over an already encrypted medium (For example VPN
tunnels).
b) PDM is used in a link-local scenario.
c) PDM is used in a corporate network where there are security
measures strong enough to consider the presence of a malicious
actor a negligible risk.
5.1. Security Goals for Confidentiality
PDM data MUST be kept confidential between the intended parties,
which includes (but is not limited to) the two entities exchanging
PDM data, and any legitimate party with the proper rights to access
such data.
5.2. Security Goals for Integrity
An implementation SHOULD attempt to detect if PDM data is forged or
modified by a malicious entity. In other terms, the implementation
should attempt to detect if a malicious entity has generated a valid
PDM header impersonating an endpoint or modified a valid PDM header.
RFC 2544 Benchmarking Methodology March 1999
+------------+
| |
+------------| tester |<-------------+
| | | |
| +------------+ |
| |
| +------------+ |
| | | |
+----------->| DUT |--------------+
| |
+------------+
Figure 1
+--------+ +------------+ +----------+
| | | | | |
| sender |-------->| DUT |--------->| receiver |
| | | | | |
+--------+ +------------+ +----------+
Figure 2
6.1 Test set up for multiple media types
Two different setups could be used to test a DUT which is used in
real-world networks to connect networks of differing media type,
local Ethernet to a backbone FDDI ring for example. The tester could
support both media types in which case the set up shown in Figure 1
would be used.
Two identical DUTs are used in the other test set up. (see Figure 3)
In many cases this set up may more accurately simulate the real
world. For example, connecting two LANs together with a WAN link or
high speed backbone. This set up would not be as good at simulating
a system where clients on a Ethernet LAN were interacting with a
server on an FDDI backbone.
+-----------+
| |
+---------------------| tester |<---------------------+
| | | |
| +-----------+ |
| |
| +----------+ +----------+ |
| | | | | |
+------->| DUT 1 |-------------->| DUT 2 |---------+
| | | |
+----------+ +----------+
Figure 3
Bradner & McQuaid Informational [Page 4]
RFC 2544 Benchmarking Methodology March 1999
7. DUT set up
Before starting to perform the tests, the DUT to be tested MUST be
configured following the instructions provided to the user.
Specifically, it is expected that all of the supported protocols will
be configured and enabled during this set up (See Appendix A). It is
expected that all of the tests will be run without changing the
configuration or setup of the DUT in any way other than that required
to do the specific test. For example, it is not acceptable to change
the size of frame handling buffers between tests of frame handling
rates or to disable all but one transport protocol when testing the
throughput of that protocol. It is necessary to modify the
configuration when starting a test to determine the effect of filters
on throughput, but the only change MUST be to enable the specific
filter. The DUT set up SHOULD include the normally recommended
routing update intervals and keep alive frequency. The specific
version of the software and the exact DUT configuration, including
what functions are disabled, used during the tests MUST be included
as part of the report of the results.
8. Frame formats
The formats of the test frames to use for TCP/IP over Ethernet are
shown in Appendix C: Test Frame Formats. These exact frame formats
SHOULD be used in the tests described in this document for this
protocol/media combination and that these frames will be used as a
template for testing other protocol/media combinations. The specific
formats that are used to define the test frames for a particular test
series MUST be included in the report of the results.
9. Frame sizes
All of the described tests SHOULD be performed at a number of frame
sizes. Specifically, the sizes SHOULD include the maximum and minimum
legitimate sizes for the protocol under test on the media under test
and enough sizes in between to be able to get a full characterization
of the DUT performance. Except where noted, at least five frame
sizes SHOULD be tested for each test condition.
Theoretically the minimum size UDP Echo request frame would consist
of an IP header (minimum length 20 octets), a UDP header (8 octets)
and whatever MAC level header is required by the media in use. The
theoretical maximum frame size is determined by the size of the
length field in the IP header. In almost all cases the actual
maximum and minimum sizes are determined by the limitations of the
media.
Bradner & McQuaid Informational [Page 5]
RFC 2544 Benchmarking Methodology March 1999
In theory it would be ideal to distribute the frame sizes in a way
that would evenly distribute the theoretical frame rates. These
recommendations incorporate this theory but specify frame sizes which
are easy to understand and remember. In addition, many of the same
frame sizes are specified on each of the media types to allow for
easy performance comparisons.
Note: The inclusion of an unrealistically small frame size on some of
the media types (i.e. with little or no space for data) is to help
characterize the per-frame processing overhead of the DUT.
9.1 Frame sizes to be used on Ethernet
64, 128, 256, 512, 1024, 1280, 1518
These sizes include the maximum and minimum frame sizes permitted by
the Ethernet standard and a selection of sizes between these extremes
with a finer granularity for the smaller frame sizes and higher frame
rates.
9.2 Frame sizes to be used on 4Mb and 16Mb token ring
54, 64, 128, 256, 1024, 1518, 2048, 4472
The frame size recommendations for token ring assume that there is no
RIF field in the frames of routed protocols. A RIF field would be
present in any direct source route bridge performance test. The
minimum size frame for UDP on token ring is 54 octets. The maximum
size of 4472 octets is recommended for 16Mb token ring instead of the
theoretical size of 17.9Kb because of the size limitations imposed by
many token ring interfaces. The reminder of the sizes are selected
to permit direct comparisons with other types of media. An IP (i.e.
not UDP) frame may be used in addition if a higher data rate is
desired, in which case the minimum frame size is 46 octets.
9.3 Frame sizes to be used on FDDI
54, 64, 128, 256, 1024, 1518, 2048, 4472
The minimum size frame for UDP on FDDI is 53 octets, the minimum size
of 54 is recommended to allow direct comparison to token ring
performance. The maximum size of 4472 is recommended instead of the
theoretical maximum size of 4500 octets to permit the same type of
comparison. An IP (i.e. not UDP) frame may be used in addition if a
higher data rate is desired, in which case the minimum frame size is
45 octets.
Bradner & McQuaid Informational [Page 6]
RFC 2544 Benchmarking Methodology March 1999
9.4 Frame sizes in the presence of disparate MTUs
When the interconnect DUT supports connecting links with disparate
MTUs, the frame sizes for the link with the *larger* MTU SHOULD be
used, up to the limit of the protocol being tested. If the
interconnect DUT does not support the fragmenting of frames in the
presence of MTU mismatch, the forwarding rate for that frame size
shall be reported as zero.
For example, the test of IP forwarding with a bridge or router that
joins FDDI and Ethernet should use the frame sizes of FDDI when going
from the FDDI to the Ethernet link. If the bridge does not support IP
fragmentation, the forwarding rate for those frames too large for
Ethernet should be reported as zero.
10. Verifying received frames
The test equipment SHOULD discard any frames received during a test
run that are not actual forwarded test frames. For example, keep-
alive and routing update frames SHOULD NOT be included in the count
of received frames. In any case, the test equipment SHOULD verify
the length of the received frames and check that they match the
expected length.
Preferably, the test equipment SHOULD include sequence numbers in the
transmitted frames and check for these numbers on the received
frames. If this is done, the reported results SHOULD include in
addition to the number of frames dropped, the number of frames that
were received out of order, the number of duplicate frames received
and the number of gaps in the received frame numbering sequence.
This functionality is required for some of the described tests.
11. Modifiers
It might be useful to know the DUT performance under a number of
conditions; some of these conditions are noted below. The reported
results SHOULD include as many of these conditions as the test
equipment is able to generate. The suite of tests SHOULD be first
run without any modifying conditions and then repeated under each of
the conditions separately. To preserve the ability to compare the
results of these tests any frames that are required to generate the
modifying conditions (management queries for example) will be
included in the same data stream as the normal test frames in place
of one of the test frames and not be supplied to the DUT on a
separate network port.
Bradner & McQuaid Informational [Page 7]
RFC 2544 Benchmarking Methodology March 1999
11.1 Broadcast frames
In most router designs special processing is required when frames
addressed to the hardware broadcast address are received. In bridges
(or in bridge mode on routers) these broadcast frames must be flooded
to a number of ports. The stream of test frames SHOULD be augmented
with 1% frames addressed to the hardware broadcast address. The
frames sent to the broadcast address should be of a type that the
router will not need to process. The aim of this test is to
determine if there is any effect on the forwarding rate of the other
data in the stream. The specific frames that should be used are
included in the test frame format document. The broadcast frames
SHOULD be evenly distributed throughout the data stream, for example,
every 100th frame.
The same test SHOULD be performed on bridge-like DUTs but in this
case the broadcast packets will be processed and flooded to all
outputs.
It is understood that a level of broadcast frames of 1% is much
higher than many networks experience but, as in drug toxicity
evaluations, the higher level is required to be able to gage the
effect which would otherwise often fall within the normal variability
of the system performance. Due to design factors some test equipment
will not be able to generate a level of alternate frames this low.
In these cases the percentage SHOULD be as small as the equipment can
provide and that the actual level be described in the report of the
test results.
11.2 Management frames
Most data networks now make use of management protocols such as SNMP.
In many environments there can be a number of management stations
sending queries to the same DUT at the same time.
The stream of test frames SHOULD be augmented with one management
query as the first frame sent each second during the duration of the
trial. The result of the query must fit into one response frame. The
response frame SHOULD be verified by the test equipment. One example
of the specific query frame that should be used is shown in Appendix
C.
11.3 Routing update frames
The processing of dynamic routing protocol updates could have a
significant impact on the ability of a router to forward data frames.
The stream of test frames SHOULD be augmented with one routing update
frame transmitted as the first frame transmitted during the trial.
Bradner & McQuaid Informational [Page 8]
RFC 2544 Benchmarking Methodology March 1999
Routing update frames SHOULD be sent at the rate specified in
Appendix C for the specific routing protocol being used in the test.
Two routing update frames are defined in Appendix C for the TCP/IP
over Ethernet example. The routing frames are designed to change the
routing to a number of networks that are not involved in the
forwarding of the test data. The first frame sets the routing table
state to "A", the second one changes the state to "B". The frames
MUST be alternated during the trial.
The test SHOULD verify that the routing update was processed by the
DUT.
11.4 Filters
Filters are added to routers and bridges to selectively inhibit the
forwarding of frames that would normally be forwarded. This is
usually done to implement security controls on the data that is
accepted between one area and another. Different products have
different capabilities to implement filters.
The DUT SHOULD be first configured to add one filter condition and
the tests performed. This filter SHOULD permit the forwarding of the
test data stream. In routers this filter SHOULD be of the form:
forward input_protocol_address to output_protocol_address
In bridges the filter SHOULD be of the form:
forward destination_hardware_address
The DUT SHOULD be then reconfigured to implement a total of 25
filters. The first 24 of these filters SHOULD be of the form:
block input_protocol_address to output_protocol_address
The 24 input and output protocol addresses SHOULD not be any that are
represented in the test data stream. The last filter SHOULD permit
the forwarding of the test data stream. By "first" and "last" we
mean to ensure that in the second case, 25 conditions must be checked
before the data frames will match the conditions that permit the
forwarding of the frame. Of course, if the DUT reorders the filters
or does not use a linear scan of the filter rules the effect of the
sequence in which the filters are input is properly lost.
The exact filters configuration command lines used SHOULD be included
with the report of the results.
Bradner & McQuaid Informational [Page 9]
RFC 2544 Benchmarking Methodology March 1999
11.4.1 Filter Addresses
Two sets of filter addresses are required, one for the single filter
case and one for the 25 filter case.
The single filter case should permit traffic from IP address
198.18.1.2 to IP address 198.19.65.2 and deny all other traffic.
The 25 filter case should follow the following sequence.
deny aa.ba.1.1 to aa.ba.100.1
deny aa.ba.2.2 to aa.ba.101.2
deny aa.ba.3.3 to aa.ba.103.3
...
deny aa.ba.12.12 to aa.ba.112.12
allow aa.bc.1.2 to aa.bc.65.1
deny aa.ba.13.13 to aa.ba.113.13
deny aa.ba.14.14 to aa.ba.114.14
...
deny aa.ba.24.24 to aa.ba.124.24
deny all else
All previous filter conditions should be cleared from the router
before this sequence is entered. The sequence is selected to test to
see if the router sorts the filter conditions or accepts them in the
order that they were entered. Both of these procedures will result
in a greater impact on performance than will some form of hash
coding.
12. Protocol addresses
It is easier to implement these tests using a single logical stream
of data, with one source protocol address and one destination
protocol address, and for some conditions like the filters described
above, a practical requirement. Networks in the real world are not
limited to single streams of data. The test suite SHOULD be first run
with a single protocol (or hardware for bridge tests) source and
destination address pair. The tests SHOULD then be repeated with
using a random destination address. While testing routers the
addresses SHOULD be random and uniformly distributed over a range of
256 networks and random and uniformly distributed over the full MAC
range for bridges. The specific address ranges to use for IP are
shown in Appendix C.
Bradner & McQuaid Informational [Page 10]
RFC 2544 Benchmarking Methodology March 1999
13. Route Set Up
It is not reasonable that all of the routing information necessary to
forward the test stream, especially in the multiple address case,
will be manually set up. At the start of each trial a routing update
MUST be sent to the DUT. This routing update MUST include all of the
network addresses that will be required for the trial. All of the
addresses SHOULD resolve to the same "next-hop". Normally this will
be the address of the receiving side of the test equipment. This
routing update will have to be repeated at the interval required by
the routing protocol being used. An example of the format and
repetition interval of the update frames is given in Appendix C.
14. Bidirectional traffic
Normal network activity is not all in a single direction. To test
the bidirectional performance of a DUT, the test series SHOULD be run
with the same data rate being offered from each direction. The sum of
the data rates should not exceed the theoretical limit for the media.
15. Single stream path
The full suite of tests SHOULD be run along with whatever modifier
conditions that are relevant using a single input and output network
port on the DUT. If the internal design of the DUT has multiple
distinct pathways, for example, multiple interface cards each with
multiple network ports, then all possible types of pathways SHOULD be
tested separately.
16. Multi-port
Many current router and bridge products provide many network ports in
the same module. In performing these tests first half of the ports
are designated as "input ports" and half are designated as "output
ports". These ports SHOULD be evenly distributed across the DUT
architecture. For example if a DUT has two interface cards each of
which has four ports, two ports on each interface card are designated
as input and two are designated as output. The specified tests are
run using the same data rate being offered to each of the input
ports. The addresses in the input data streams SHOULD be set so that
a frame will be directed to each of the output ports in sequence so
that all "output" ports will get an even distribution of packets from
this input. The same configuration MAY be used to perform a
bidirectional multi-stream test. In this case all of the ports are
considered both input and output ports and each data stream MUST
consist of frames addressed to all of the other ports.
Bradner & McQuaid Informational [Page 11]
RFC 2544 Benchmarking Methodology March 1999
Consider the following 6 port DUT:
--------------
---------| in A out X|--------
---------| in B out Y|--------
---------| in C out Z|--------
--------------
The addressing of the data streams for each of the inputs SHOULD be:
stream sent to input A:
packet to out X, packet to out Y, packet to out Z
stream sent to input B:
packet to out X, packet to out Y, packet to out Z
stream sent to input C
packet to out X, packet to out Y, packet to out Z
Note that these streams each follow the same sequence so that 3
packets will arrive at output X at the same time, then 3 packets at
Y, then 3 packets at Z. This procedure ensures that, as in the real
world, the DUT will have to deal with multiple packets addressed to
the same output at the same time.
17. Multiple protocols
This document does not address the issue of testing the effects of a
mixed protocol environment other than to suggest that if such tests
are wanted then frames SHOULD be distributed between all of the test
protocols. The distribution MAY approximate the conditions on the
network in which the DUT would be used.
18. Multiple frame sizes
This document does not address the issue of testing the effects of a
mixed frame size environment other than to suggest that if such tests
are wanted then frames SHOULD be distributed between all of the
listed sizes for the protocol under test. The distribution MAY
approximate the conditions on the network in which the DUT would be
used. The authors do not have any idea how the results of such a test
would be interpreted other than to directly compare multiple DUTs in
some very specific simulated network.
19. Testing performance beyond a single DUT.
In the performance testing of a single DUT, the paradigm can be
described as applying some input to a DUT and monitoring the output.
The results of which can be used to form a basis of characterization
of that device under those test conditions.
Bradner & McQuaid Informational [Page 12]
RFC 2544 Benchmarking Methodology March 1999
This model is useful when the test input and output are homogenous
(e.g., 64-byte IP, 802.3 frames into the DUT; 64 byte IP, 802.3
frames out), or the method of test can distinguish between dissimilar
input/output. (E.g., 1518 byte IP, 802.3 frames in; 576 byte,
fragmented IP, X.25 frames out.)
By extending the single DUT test model, reasonable benchmarks
regarding multiple DUTs or heterogeneous environments may be
collected. In this extension, the single DUT is replaced by a system
of interconnected network DUTs. This test methodology would support
the benchmarking of a variety of device/media/service/protocol
combinations. For example, a configuration for a LAN-to-WAN-to-LAN
test might be:
(1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3
Or a mixed LAN configuration might be:
(2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3
In both examples 1 and 2, end-to-end benchmarks of each system could
be empirically ascertained. Other behavior may be characterized
through the use of intermediate devices. In example 2, the
configuration may be used to give an indication of the FDDI to FDDI
capability exhibited by DUT 2.
Because multiple DUTs are treated as a single system, there are
limitations to this methodology. For instance, this methodology may
yield an aggregate benchmark for a tested system. That benchmark
alone, however, may not necessarily reflect asymmetries in behavior
between the DUTs, latencies introduce by other apparatus (e.g.,
CSUs/DSUs, switches), etc.
Further, care must be used when comparing benchmarks of different
systems by ensuring that the DUTs' features/configuration of the
tested systems have the appropriate common denominators to allow
comparison.
20. Maximum frame rate
The maximum frame rates that should be used when testing LAN
connections SHOULD be the listed theoretical maximum rate for the
frame size on the media.
Bradner & McQuaid Informational [Page 13]
RFC 2544 Benchmarking Methodology March 1999
The maximum frame rate that should be used when testing WAN
connections SHOULD be greater than the listed theoretical maximum
rate for the frame size on that speed connection. The higher rate
for WAN tests is to compensate for the fact that some vendors employ
various forms of header compression.
A list of maximum frame rates for LAN connections is included in
Appendix B.
21. Bursty traffic
It is convenient to measure the DUT performance under steady state
load but this is an unrealistic way to gauge the functioning of a DUT
since actual network traffic normally consists of bursts of frames.
Some of the tests described below SHOULD be performed with both
steady state traffic and with traffic consisting of repeated bursts
of frames. The frames within a burst are transmitted with the
minimum legitimate inter-frame gap.
The objective of the test is to determine the minimum interval
between bursts which the DUT can process with no frame loss. During
each test the number of frames in each burst is held constant and the
inter-burst interval varied. Tests SHOULD be run with burst sizes of
16, 64, 256 and 1024 frames.
22. Frames per token
Although it is possible to configure some token ring and FDDI
interfaces to transmit more than one frame each time that the token
is received, most of the network devices currently available transmit
only one frame per token. These tests SHOULD first be performed
while transmitting only one frame per token.
Some current high-performance workstation servers do transmit more
than one frame per token on FDDI to maximize throughput. Since this
may be a common feature in future workstations and servers,
interconnect devices with FDDI interfaces SHOULD be tested with 1, 4,
8, and 16 frames per token. The reported frame rate SHOULD be the
average rate of frame transmission over the total trial period.
23. Trial description
A particular test consists of multiple trials. Each trial returns
one piece of information, for example the loss rate at a particular
input frame rate. Each trial consists of a number of phases:
a) If the DUT is a router, send the routing update to the "input"
port and pause two seconds to be sure that the routing has settled.
Bradner & McQuaid Informational [Page 14]
RFC 2544 Benchmarking Methodology March 1999
b) Send the "learning frames" to the "output" port and wait 2
seconds to be sure that the learning has settled. Bridge learning
frames are frames with source addresses that are the same as the
destination addresses used by the test frames. Learning frames for
other protocols are used to prime the address resolution tables in
the DUT. The formats of the learning frame that should be used are
shown in the Test Frame Formats document.
c) Run the test trial.
d) Wait for two seconds for any residual frames to be received.
e) Wait for at least five seconds for the DUT to restabilize.
24. Trial duration
The aim of these tests is to determine the rate continuously
supportable by the DUT. The actual duration of the test trials must
be a compromise between this aim and the duration of the benchmarking
test suite. The duration of the test portion of each trial SHOULD be
at least 60 seconds. The tests that involve some form of "binary
search", for example the throughput test, to determine the exact
result MAY use a shorter trial duration to minimize the length of the
search procedure, but the final determination SHOULD be made with
full length trials.
25. Address resolution
The DUT SHOULD be able to respond to address resolution requests sent
by the DUT wherever the protocol requires such a process.
26. Benchmarking tests:
Note: The notation "type of data stream" refers to the above
modifications to a frame stream with a constant inter-frame gap, for
example, the addition of traffic filters to the configuration of the
DUT.
26.1 Throughput
Objective: To determine the DUT throughput as defined in RFC 1242.
Procedure: Send a specific number of frames at a specific rate
through the DUT and then count the frames that are transmitted by the
DUT. If the count of offered frames is equal to the count of received
frames, the fewer frames are received than were transmitted, the rate
of the offered stream is reduced and the test is rerun.
Bradner & McQuaid Informational [Page 15]
RFC 2544 Benchmarking Methodology March 1999
The throughput is the fastest rate at which the count of test frames
transmitted by the DUT is equal to the number of test frames sent to
it by the test equipment.
Reporting format: The results of the throughput test SHOULD be
reported in the form of a graph. If it is, the x coordinate SHOULD be
the frame size, the y coordinate SHOULD be the frame rate. There
SHOULD be at least two lines on the graph. There SHOULD be one line
showing the theoretical frame rate for the media at the various frame
sizes. The second line SHOULD be the plot of the test results.
Additional lines MAY be used on the graph to report the results for
each type of data stream tested. Text accompanying the graph SHOULD
indicate the protocol, data stream format, and type of media used in
the tests.
We assume that if a single value is desired for advertising purposes
the vendor will select the rate for the minimum frame size for the
media. If this is done then the figure MUST be expressed in frames
per second. The rate MAY also be expressed in bits (or bytes) per
second if the vendor so desires. The statement of performance MUST
include a/ the measured maximum frame rate, b/ the size of the frame
used, c/ the theoretical limit of the media for that frame size, and
d/ the type of protocol used in the test. Even if a single value is
used as part of the advertising copy, the full table of results
SHOULD be included in the product data sheet.
26.2 Latency
Objective: To determine the latency as defined in RFC 1242.
Procedure: First determine the throughput for DUT at each of the
listed frame sizes. Send a stream of frames at a particular frame
size through the DUT at the determined throughput rate to a specific
destination. The stream SHOULD be at least 120 seconds in duration.
An identifying tag SHOULD be included in one frame after 60 seconds
with the type of tag being implementation dependent. The time at
which this frame is fully transmitted is recorded (timestamp A). The
receiver logic in the test equipment MUST recognize the tag
information in the frame stream and record the time at which the
tagged frame was received (timestamp B).
The latency is timestamp B minus timestamp A as per the relevant
definition frm RFC 1242, namely latency as defined for store and
forward devices or latency as defined for bit forwarding devices.
The test MUST be repeated at least 20 times with the reported value
being the average of the recorded values.
Bradner & McQuaid Informational [Page 16]
RFC 2544 Benchmarking Methodology March 1999
This test SHOULD be performed with the test frame addressed to the
same destination as the rest of the data stream and also with each of
the test frames addressed to a new destination network.
Reporting format: The report MUST state which definition of latency
(from RFC 1242) was used for this test. The latency results SHOULD
be reported in the format of a table with a row for each of the
tested frame sizes. There SHOULD be columns for the frame size, the
rate at which the latency test was run for that frame size, for the
media types tested, and for the resultant latency values for each
type of data stream tested.
26.3 Frame loss rate
Objective: To determine the frame loss rate, as defined in RFC 1242,
of a DUT throughout the entire range of input data rates and frame
sizes.
Procedure: Send a specific number of frames at a specific rate
through the DUT to be tested and count the frames that are
transmitted by the DUT. The frame loss rate at each point is
calculated using the following equation:
( ( input_count - output_count ) * 100 ) / input_count
The first trial SHOULD be run for the frame rate that corresponds to
100% of the maximum rate for the frame size on the input media.
Repeat the procedure for the rate that corresponds to 90% of the
maximum rate used and then for 80% of this rate. This sequence
SHOULD be continued (at reducing 10% intervals) until there are two
successive trials in which no frames are lost. The maximum
granularity of the trials MUST be 10% of the maximum rate, a finer
granularity is encouraged.
Reporting format: The results of the frame loss rate test SHOULD be
plotted as a graph. If this is done then the X axis MUST be the
input frame rate as a percent of the theoretical rate for the media
at the specific frame size. The Y axis MUST be the percent loss at
the particular input rate. The left end of the X axis and the bottom
of the Y axis MUST be 0 percent; the right end of the X axis and the
top of the Y axis MUST be 100 percent. Multiple lines on the graph
MAY used to report the frame loss rate for different frame sizes,
protocols, and types of data streams.
Note: See section 18 for the maximum frame rates that SHOULD be used.
Bradner & McQuaid Informational [Page 17]
RFC 2544 Benchmarking Methodology March 1999
26.4 Back-to-back frames
Objective: To characterize the ability of a DUT to process back-to-
back frames as defined in RFC 1242.
Procedure: Send a burst of frames with minimum inter-frame gaps to
the DUT and count the number of frames forwarded by the DUT. If the
count of transmitted frames is equal to the number of frames
forwarded the length of the burst is increased and the test is rerun.
If the number of forwarded frames is less than the number
transmitted, the length of the burst is reduced and the test is
rerun.
The back-to-back value is the number of frames in the longest burst
that the DUT will handle without the loss of any frames. The trial
length MUST be at least 2 seconds and SHOULD be repeated at least 50
times with the average of the recorded values being reported.
Reporting format: The back-to-back results SHOULD be reported in the
format of a table with a row for each of the tested frame sizes.
There SHOULD be columns for the frame size and for the resultant
average frame count for each type of data stream tested. The
standard deviation for each measurement MAY also be reported.
26.5 System recovery
Objective: To characterize the speed at which a DUT recovers from an
overload condition.
Procedure: First determine the throughput for a DUT at each of the
listed frame sizes.
Send a stream of frames at a rate 110% of the recorded throughput
rate or the maximum rate for the media, whichever is lower, for at
least 60 seconds. At Timestamp A reduce the frame rate to 50% of the
above rate and record the time of the last frame lost (Timestamp B).
The system recovery time is determined by subtracting Timestamp B
from Timestamp A. The test SHOULD be repeated a number of times and
the average of the recorded values being reported.
Reporting format: The system recovery results SHOULD be reported in
the format of a table with a row for each of the tested frame sizes.
There SHOULD be columns for the frame size, the frame rate used as
the throughput rate for each type of data stream tested, and for the
measured recovery time for each type of data stream tested.
Bradner & McQuaid Informational [Page 18]
RFC 2544 Benchmarking Methodology March 1999
26.6 Reset
Objective: To characterize the speed at which a DUT recovers from a
device or software reset.
Procedure: First determine the throughput for the DUT for the
minimum frame size on the media used in the testing.
Send a continuous stream of frames at the determined throughput rate
for the minimum sized frames. Cause a reset in the DUT. Monitor the
output until frames begin to be forwarded and record the time that
the last frame (Timestamp A) of the initial stream and the first
frame of the new stream (Timestamp B) are received. A power
interruption reset test is performed as above except that the power
to the DUT should be interrupted for 10 seconds in place of causing a
reset.
This test SHOULD only be run using frames addressed to networks
directly connected to the DUT so that there is no requirement to
delay until a routing update is received.
The reset value is obtained by subtracting Timestamp A from Timestamp
B.
Hardware and software resets, as well as a power interruption SHOULD
be tested.
Reporting format: The reset value SHOULD be reported in a simple set
of statements, one for each reset type.
27. Security Considerations
Security issues are not addressed in this document.
Bradner & McQuaid Informational [Page 19]
RFC 2544 Benchmarking Methodology March 1999
28. Editors' Addresses
Scott Bradner
Harvard University
1350 Mass. Ave, room 813
Cambridge, MA 02138
Phone: +1 617 495-3864
Fax: +1 617 496-8500
EMail: sob@harvard.edu
Jim McQuaid
NetScout Systems
4 Westford Tech Park Drive
Westford, MA 01886
Phone: +1 978 614-4116
Fax: +1 978 614-4004
EMail: mcquaidj@netscout.com
Bradner & McQuaid Informational [Page 20]
RFC 2544 Benchmarking Methodology March 1999
Appendix A: Testing Considerations
A.1 Scope Of This Appendix
This appendix discusses certain issues in the benchmarking
methodology where experience or judgment may play a role in the tests
selected to be run or in the approach to constructing the test with a
particular DUT. As such, this appendix MUST not be read as an
amendment to the methodology described in the body of this document
but as a guide to testing practice.
1. Typical testing practice has been to enable all protocols to be
tested and conduct all testing with no further configuration of
protocols, even though a given set of trials may exercise only one
protocol at a time. This minimizes the opportunities to "tune" a
DUT for a single protocol.
2. The least common denominator of the available filter functions
should be used to ensure that there is a basis for comparison
between vendors. Because of product differences, those conducting
and evaluating tests must make a judgment about this issue.
3. Architectural considerations may need to be considered. For
example, first perform the tests with the stream going between
ports on the same interface card and the repeat the tests with the
stream going into a port on one interface card and out of a port
on a second interface card. There will almost always be a best
case and worst case configuration for a given DUT architecture.
4. Testing done using traffic streams consisting of mixed protocols
has not shown much difference between testing with individual
protocols. That is, if protocol A testing and protocol B testing
give two different performance results, mixed protocol testing
appears to give a result which is the average of the two.
5. Wide Area Network (WAN) performance may be tested by setting up
two identical devices connected by the appropriate short- haul
versions of the WAN modems. Performance is then measured between
a LAN interface on one DUT to a LAN interface on the other DUT.
The maximum frame rate to be used for LAN-WAN-LAN configurations is a
judgment that can be based on known characteristics of the overall
system including compression effects, fragmentation, and gross link
speeds. Practice suggests that the rate should be at least 110% of
the slowest link speed. Substantive issues of testing compression
itself are beyond the scope of this document.
Bradner & McQuaid Informational [Page 21]
RFC 2544 Benchmarking Methodology March 1999
Appendix B: Maximum frame rates reference
(Provided by Roger Beeman, Cisco Systems)
Size Ethernet 16Mb Token Ring FDDI
(bytes) (pps) (pps) (pps)
64 14880 24691 152439
128 8445 13793 85616
256 4528 7326 45620
512 2349 3780 23585
768 1586 2547 15903
1024 1197 1921 11996
1280 961 1542 9630
1518 812 1302 8138
Ethernet size
Preamble 64 bits
Frame 8 x N bits
Gap 96 bits
16Mb Token Ring size
SD 8 bits
AC 8 bits
FC 8 bits
DA 48 bits
SA 48 bits
RI 48 bits ( 06 30 00 12 00 30 )
SNAP
DSAP 8 bits
SSAP 8 bits
Control 8 bits
Vendor 24 bits
Type 16 bits
Data 8 x ( N - 18) bits
FCS 32 bits
ED 8 bits
FS 8 bits
Tokens or idles between packets are not included
FDDI size
Preamble 64 bits
SD 8 bits
FC 8 bits
DA 48 bits
SA 48 bits
SNAP
Bradner & McQuaid Informational [Page 22]
RFC 2544 Benchmarking Methodology March 1999
DSAP 8 bits
SSAP 8 bits
Control 8 bits
Vendor 24 bits
Type 16 bits
Data 8 x ( N - 18) bits
FCS 32 bits
ED 4 bits
FS 12 bits
Bradner & McQuaid Informational [Page 23]
RFC 2544 Benchmarking Methodology March 1999
Appendix C: Test Frame Formats
This appendix defines the frame formats that may be used with these
tests. It also includes protocol specific parameters for TCP/IP over
Ethernet to be used with the tests as an example.
C.1. Introduction
The general logic used in the selection of the parameters and the
design of the frame formats is explained for each case within the
TCP/IP section. The same logic has been used in the other sections.
Comments are used in these sections only if there is a protocol
specific feature to be explained. Parameters and frame formats for
additional protocols can be defined by the reader by using the same
logic.
C.2. TCP/IP Information
The following section deals with the TCP/IP protocol suite.
C.2.1 Frame Type.
An application level datagram echo request is used for the test data
frame in the protocols that support such a function. A datagram
protocol is used to minimize the chance that a router might expect a
specific session initialization sequence, as might be the case for a
reliable stream protocol. A specific defined protocol is used because
some routers verify the protocol field and refuse to forward unknown
protocols.
For TCP/IP a UDP Echo Request is used.
C.2.2 Protocol Addresses
Two sets of addresses must be defined: first the addresses assigned
to the router ports, and second the address that are to be used in
the frames themselves and in the routing updates.
The network addresses 192.18.0.0 through 198.19.255.255 are have been
assigned to the BMWG by the IANA for this purpose. This assignment
was made to minimize the chance of conflict in case a testing device
were to be accidentally connected to part of the Internet. The
specific use of the addresses is detailed below.
Bradner & McQuaid Informational [Page 24]
RFC 2544 Benchmarking Methodology March 1999
C.2.2.1 Router port protocol addresses
Half of the ports on a multi-port router are referred to as "input"
ports and the other half as "output" ports even though some of the
tests use all ports both as input and output. A contiguous series of
IP Class C network addresses from 198.18.1.0 to 198.18.64.0 have been
assigned for use on the "input" ports. A second series from
198.19.1.0 to 198.19.64.0 have been assigned for use on the "output"
ports. In all cases the router port is node 1 on the appropriate
network. For example, a two port DUT would have an IP address of
198.18.1.1 on one port and 198.19.1.1 on the other port.
Some of the tests described in the methodology memo make use of an
SNMP management connection to the DUT. The management access address
for the DUT is assumed to be the first of the "input" ports
(198.18.1.1).
C.2.2.2 Frame addresses
Some of the described tests assume adjacent network routing (the
reboot time test for example). The IP address used in the test frame
is that of node 2 on the appropriate Class C network. (198.19.1.2 for
example)
If the test involves non-adjacent network routing the phantom routers
are located at node 10 of each of the appropriate Class C networks.
A series of Class C network addresses from 198.18.65.0 to
198.18.254.0 has been assigned for use as the networks accessible
through the phantom routers on the "input" side of DUT. The series
of Class C networks from 198.19.65.0 to 198.19.254.0 have been
assigned to be used as the networks visible through the phantom
routers on the "output" side of the DUT.
C.2.3 Routing Update Frequency
The update interval for each routing protocol is may have to be
determined by the specifications of the individual protocol. For IP
RIP, Cisco IGRP and for OSPF a routing update frame or frames should
precede each stream of test frames by 5 seconds. This frequency is
sufficient for trial durations of up to 60 seconds. Routing updates
must be mixed with the stream of test frames if longer trial periods
are selected. The frequency of updates should be taken from the
following table.
IP-RIP 30 sec
IGRP 90 sec
OSPF 90 sec
Bradner & McQuaid Informational [Page 25]
RFC 2544 Benchmarking Methodology March 1999
C.2.4 Frame Formats - detailed discussion
C.2.4.1 Learning Frame
In most protocols a procedure is used to determine the mapping
between the protocol node address and the MAC address. The Address
Resolution Protocol (ARP) is used to perform this function in TCP/IP.
No such procedure is required in XNS or IPX because the MAC address
is used as the protocol node address.
In the ideal case the tester would be able to respond to ARP requests
from the DUT. In cases where this is not possible an ARP request
should be sent to the router's "output" port. This request should be
seen as coming from the immediate destination of the test frame
stream. (i.e. the phantom router (Figure 2) or the end node if
adjacent network routing is being used.) It is assumed that the
router will cache the MAC address of the requesting device. The ARP
request should be sent 5 seconds before the test frame stream starts
in each trial. Trial lengths of longer than 50 seconds may require
that the router be configured for an extended ARP timeout.
+--------+ +------------+
| | | phantom |------ P LAN
A
IN A------| DUT |------------| |------ P LAN
B
| | OUT A | router |------ P LAN
C
+--------+ +------------+
Figure 2
In the case where full routing is being used
C.2.4.2 Routing Update Frame
If the test does not involve adjacent net routing the tester must
supply proper routing information using a routing update. A single
routing update is used before each trial on each "destination" port
(see section C.24). This update includes the network addresses that
are reachable through a phantom router on the network attached to the
port. For a full mesh test, one destination network address is
present in the routing update for each of the "input" ports. The
test stream on each "input" port consists of a repeating sequence of
frames, one to each of the "output" ports.
Bradner & McQuaid Informational [Page 26]
RFC 2544 Benchmarking Methodology March 1999
C.2.4.3 Management Query Frame
The management overhead test uses SNMP to query a set of variables
that should be present in all DUTs that support SNMP. The variables
for a single interface only are read by an NMS at the appropriate
intervals. The list of variables to retrieve follow:
sysUpTime
ifInOctets
ifOutOctets
ifInUcastPkts
ifOutUcastPkts
C.2.4.4 Test Frames
The test frame is an UDP Echo Request with enough data to fill out
the required frame size. The data should not be all bits off or all
bits on since these patters can cause a "bit stuffing" process to be
used to maintain clock synchronization on WAN links. This process
will result in a longer frame than was intended.
C.2.4.5 Frame Formats - TCP/IP on Ethernet
Each of the frames below are described for the 1st pair of DUT ports,
i.e. "input" port #1 and "output" port #1. Addresses must be changed
if the frame is to be used for other ports.
C.2.6.1 Learning Frame
ARP Request on Ethernet
-- DATAGRAM HEADER
offset data (hex) description
00 FF FF FF FF FF FF dest MAC address send to
broadcast address
06 xx xx xx xx xx xx set to source MAC address
12 08 06 ARP type
14 00 01 hardware type Ethernet = 1
16 08 00 protocol type IP = 800
18 06 hardware address length 48 bits
on Ethernet
19 04 protocol address length 4 octets
for IP
20 00 01 opcode request = 1
22 xx xx xx xx xx xx source MAC address
28 xx xx xx xx source IP address
32 FF FF FF FF FF FF requesting DUT's MAC address
38 xx xx xx xx DUT's IP address
Bradner & McQuaid Informational [Page 27]
RFC 2544 Benchmarking Methodology March 1999
C.2.6.2 Routing Update Frame
-- DATAGRAM HEADER
offset data (hex) description
00 FF FF FF FF FF FF dest MAC address is broadcast
06 xx xx xx xx xx xx source hardware address
12 08 00 type
-- IP HEADER
14 45 IP version - 4, header length (4
byte units) - 5
15 00 service field
16 00 EE total length
18 00 00 ID
20 40 00 flags (3 bits) 4 (do not
fragment),
fragment offset-0
22 0A TTL
23 11 protocol - 17 (UDP)
24 C4 8D header checksum
26 xx xx xx xx source IP address
30 xx xx xx destination IP address
33 FF host part = FF for broadcast
-- UDP HEADER
34 02 08 source port 208 = RIP
36 02 08 destination port 208 = RIP
38 00 DA UDP message length
40 00 00 UDP checksum
-- RIP packet
42 02 command = response
43 01 version = 1
44 00 00 0
-- net 1
46 00 02 family = IP
48 00 00 0
50 xx xx xx net 1 IP address
53 00 net not node
54 00 00 00 00 0
58 00 00 00 00 0
62 00 00 00 07 metric 7
-- net 2
66 00 02 family = IP
68 00 00 0
70 xx xx xx net 2 IP address
Bradner & McQuaid Informational [Page 28]
RFC 2544 Benchmarking Methodology March 1999
73 00 net not node
74 00 00 00 00 0
78 00 00 00 00 0
82 00 00 00 07 metric 7
-- net 3
86 00 02 family = IP
88 00 00 0
90 xx xx xx net 3 IP address
93 00 net not node
94 00 00 00 00 0
98 00 00 00 00 0
102 00 00 00 07 metric 7
-- net 4
106 00 02 family = IP
108 00 00 0
110 xx xx xx net 4 IP address
113 00 net not node
114 00 00 00 00 0
118 00 00 00 00 0
122 00 00 00 07 metric 7
-- net 5
126 00 02 family = IP
128 00 00 0
130 00 net 5 IP address
133 00 net not node
134 00 00 00 00 0
138 00 00 00 00 0
142 00 00 00 07 metric 7
-- net 6
146 00 02 family = IP
148 00 00 0
150 xx xx xx net 6 IP address
153 00 net not node
154 00 00 00 00 0
158 00 00 00 00 0
162 00 00 00 07 metric 7
C.2.4.6 Management Query Frame
To be defined.
C.2.6.4 Test Frames
UDP echo request on Ethernet
Bradner & McQuaid Informational [Page 29]
RFC 2544 Benchmarking Methodology March 1999
-- DATAGRAM HEADER
offset data (hex) description
00 xx xx xx xx xx xx set to dest MAC address
06 xx xx xx xx xx xx set to source MAC address
12 08 00 type
-- IP HEADER
14 45 IP version - 4 header length 5 4
byte units
15 00 TOS
16 00 2E total length*
18 00 00 ID
20 00 00 flags (3 bits) - 0 fragment
offset-0
22 0A TTL
23 11 protocol - 17 (UDP)
24 C4 8D header checksum*
26 xx xx xx xx set to source IP address**
30 xx xx xx xx set to destination IP address**
-- UDP HEADER
34 C0 20 source port
36 00 07 destination port 07 = Echo
38 00 1A UDP message length*
40 00 00 UDP checksum
-- UDP DATA
42 00 01 02 03 04 05 06 07 some data***
50 08 09 0A 0B 0C 0D 0E 0F
* - change for different length frames
** - change for different logical streams
*** - fill remainder of frame with incrementing octets,
repeated if required by frame length
Values to be used in Total Length and UDP message length fields:
frame size total length UDP message length
64 00 2E 00 1A
128 00 6E 00 5A
256 00 EE 00 9A
512 01 EE 01 9A
768 02 EE 02 9A
1024 03 EE 03 9A
1280 04 EE 04 9A
1518 05 DC 05 C8
Bradner & McQuaid Informational [Page 30]Elkins, et al. Expires 28 August 2024 [Page 7]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
5.3. Security Goals for Authentication
An unauthorized party MUST NOT be able to send PDM data and MUST NOT
be able to authorize another entity to do so. Alternatively, if
authentication is done via any of the following, this requirement MAY
be considered to be met.
a) PDM is used over an already authenticated medium (For example,
TLS session).
b) PDM is used in a link-local scenario.
c) PDM is used in a corporate network where security measures are
strong enough to consider the presence of a malicious actor a
negligible risk.
5.4. Cryptographic Algorithm
Symmetric key cryptography has performance benefits over asymmetric
cryptography; asymmetric cryptography is better for key management.
Encryption schemes that unite both have been specified in [RFC1421],
and have been participating practically since the early days of
public-key cryptography. The basic mechanism is to encrypt the
symmetric key with the public key by joining both yields. Hybrid
public-key encryption schemes (HPKE) [RFC9180] used a different
approach that generates the symmetric key and its encapsulation with
the public key of the receiver.
It is RECOMMENDED to use the HPKE framework that incorporates key
encapsulation mechanism (KEM), key derivation function (KDF) and
authenticated encryption with associated data (AEAD). These multiple
schemes are more robust and significantly more efficient than other
schemes. While the schemes may be negotiated between communicating
parties, it is RECOMMENDED to use default encryption algorithm for
HPKE AEAD as AES-128-GCM.
6. PDMv2 Destination Options
6.1. Destinations Option Header
The IPv6 Destination Options extension header [RFC8200] is used to
carry optional information that needs to be examined only by a
packet's destination node(s). The Destination Options header is
identified by a Next Header value of 60 in the immediately preceding
header and is defined in RFC 8200 [RFC8200]. The IPv6 PDMv2
destination option is implemented as an IPv6 Option carried in the
Destination Options header.
Elkins, et al. Expires 28 August 2024 [Page 8]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
6.2. Metrics information in PDMv2
The IPv6 PDMv2 destination option contains the following base fields:
SCALEDTLR: Scale for Delta Time Last Received
SCALEDTLS: Scale for Delta Time Last Sent
GLOBALPTR: Global Pointer
PSNTP: Packet Sequence Number This Packet
PSNLR: Packet Sequence Number Last Received
DELTATLR: Delta Time Last Received
DELTATLS: Delta Time Last Sent
PDMv2 adds a new metric to the existing PDM [RFC8250] called the
Global Pointer. The existing PDM fields are identified with respect
to the identifying information called a "5-tuple".
The 5-tuple consists of:
SADDR: IP address of the sender
SPORT: Port for the sender
DADDR: IP address of the destination
DPORT: Port for the destination
PROTC: Upper-layer protocol (TCP, UDP, ICMP, etc.)
Unlike PDM fields, Global Pointer (GLOBALPTR) field in PDMv2 is
defined for the SADDR type. Following are the SADDR address types
considered:
a) Link-Local
b) Global Unicast
The Global Pointer is treated as a common entity over all the
5-tuples with the same SADDR type. It is initialised to the value 1
and increments for every packet sent. Global Pointer provides a
measure of the amount of IPv6 traffic sent by the PDMv2 node.
Elkins, et al. Expires 28 August 2024 [Page 9]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
When the SADDR type is Link-Local, the PDMv2 node sends Global
Pointer defined for Link-Local addresses, and when the SADDR type is
Global Unicast, it sends the one defined for Global Unicast
addresses.
6.3. PDMv2 Layout
PDMv2 has two different header formats corresponding to whether the
metric contents are encrypted or unencrypted. The difference between
the two types of headers is determined from the Options Length value.
Following is the representation of the unencrypted PDMv2 header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Vrsn | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN This Packet | Reserved Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ScaleDTLR | ScaleDTLS | PSN Last Received |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time Last Received | Delta Time Last Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Following is the representation of the encrypted PDMv2 header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Vrsn | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN This Packet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Encrypted PDM Data :
: (30 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
0x0F
8-bit unsigned integer. The Option Type is adopted from RFC 8250
[RFC8250].
Option Length
Elkins, et al. Expires 28 August 2024 [Page 10]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
0x12: Unencrypted PDM
0x22: Encrypted PDM
8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. The options
length is used for differentiating PDM [RFC8250], unencrypted
PDMv2 and encrypted PDMv2.
Version Number
0x2
4-bit unsigned number.
Epoch
12-bit unsigned number.
Epoch field is used to indicate the valid SessionTemporaryKey.
Packet Sequence Number This Packet (PSNTP)
16-bit unsigned number.
This field is initialized at a random number and is incremented
sequentially for each packet of the 5-tuple.
This field is also used in the Encrypted PDMv2 as the encryption
nonce. The nonce MUST NOT be reused in different sessions.
Reserved Bits
16-bits.
Reserved bits for future use. They MUST be set to zero on
transmission and ignored on receipt per [RFC3552].
Scale Delta Time Last Received (SCALEDTLR)
8-bit unsigned number.
This is the scaling value for the Delta Time Last Sent (DELTATLS)
field.
Scale Delta Time Last Sent (SCALEDTLS)
8-bit unsigned number.
Elkins, et al. Expires 28 August 2024 [Page 11]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
This is the scaling value for the Delta Time Last Sent (DELTATLS)
field.
Global Pointer
32-bit unsigned number.
Global Pointer is initialized to 1 for the different source
address types and incremented sequentially for each packet with
the corresponding source address type.
This field stores the Global Pointer type corresponding to the
SADDR type of the packet.
Packet Sequence Number Last Received (PSNLR)
16-bit unsigned number.
This field is the PSNTP of the last received packet on the
5-tuple.
Delta Time Last Received (DELTATLR)
16-bit unsigned integer.
The value is set according to the scale in SCALEDTLR.
Delta Time Last Received = (send time packet n - receive time
packet (n - 1))
Delta Time Last Sent (DELTATLS)
16-bit unsigned integer.
The value is set according to the scale in SCALEDTLS.
Delta Time Last Sent = (receive time packet n - send time packet
(n - 1))
7. Security Considerations
PDMv2 carries metadata, including information about network
characteristics and end-to-end response time. This metadata is used
to optimize communication. However, in the context of passive
attacks, the information contained within PDMv2 packets can be
intercepted by an attacker, and in the context of active attacks the
metadata can be modified by an attacker.
Elkins, et al. Expires 28 August 2024 [Page 12]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
In the following we will briefly outline the threat model and the
associated security risks, using RFC3552 terminology and
classification.
7.1. Limited Threat Model
We assume that the attacker does not control the endpoints, but it
does have a limited control of the network, i.e., it can either
monitor the communications (leading to passive attacks), or modify/
forge packets (active attacks).
7.1.1. Passive attacks with unencrypted PDMv2
Passive Attack Scenario: In a passive attack, the attacker seeks to
obtain information that the sender and receiver of the communication
would prefer to keep private. In this case, the attacker is not
altering the packets but is intercepting and analyzing them. Here's
how this can happen in the context of unencrypted PDMv2:
a. Being on the same LAN: The simplest way for an attacker to launch
a passive attack is to be on the same Local Area Network (LAN) as
the victim. Many LAN configurations, such as Ethernet, 802.3,
and FDDI, allow any machine on the network to read all traffic
destined for any other machine on the same LAN. This means that
if PDM packets are sent over the LAN, the attacker can capture
them.
b. Control of a Host in the Communication Path: If the attacker has
control over a host that lies in the communication path between
two victim machines, they can intercept PDM packets as they pass
through this compromised host. This allows the attacker to
collect metadata without being on the same LAN as the victim.
c. Compromising Routing Infrastructure: In some cases, attackers may
actively compromise the routing infrastructure to route traffic
through a compromised machine. This can facilitate a passive
attack on victim machines. By manipulating routing, the attacker
can ensure that PDMv2 packets pass through their controlled node.
d. Wireless Networks: Wireless communication channels, such as those
using 802.11 (Wi-Fi), are particularly vulnerable to passive
attacks. Since data is broadcast over well-known radio
frequencies, an attacker with the ability to receive those
transmissions can intercept PDMv2 packets. Weak or ineffective
cryptographic protection in wireless networks can make it easier
for attackers to capture this data.
Elkins, et al. Expires 28 August 2024 [Page 13]
Internet-Draft draft-ietf-ippm-encrypted-pdmv2 February 2024
RFC 2544 Benchmarking Methodology March 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bradner & McQuaid Informational [Page 31]