draft-ietf-ippm-owdp-00.txt   draft-ietf-ippm-owdp-01.txt 
Network Working Group S. Shalunov Network Working Group S. Shalunov
Expiration Date: May 2001 B. Teitelbaum Expiration Date: June 2001 B. Teitelbaum
Advanced Network & Services and Internet2 Advanced Network & Services and Internet2
M. Zekauskas M. Zekauskas
Advanced Network & Services Advanced Network & Services
November 2000 December 2000
A One-way Delay Measurement Protocol A One-way Delay Measurement Protocol
<draft-ietf-ippm-owdp-00.txt> <draft-ietf-ippm-owdp-01.txt>
1. Status of this Memo 1. 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 45 skipping to change at page 1, line 45
This memo provides information for the Internet community. This memo This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of does not specify an Internet standard of any kind. Distribution of
this memo is unlimited. this memo is unlimited.
2. Motivation and Goals 2. Motivation and Goals
The IETF IP Performance Metrics (IPPM) working group has proposed The IETF IP Performance Metrics (IPPM) working group has proposed
draft standard metrics for one-way packet delay [RFC2679] and loss draft standard metrics for one-way packet delay [RFC2679] and loss
[RFC 2680] across Internet paths. Although there are now several [RFC 2680] across Internet paths. Although there are now several
measurement platforms that implement collection of these metrics measurement platforms that implement collection of these metrics
[SURVEYOR], [RIPE], there is to date no standard that would permit [SURVEYOR], [RIPE], there is not currently a standard that would
initiation of test streams or exchange of packets to collect permit initiation of test streams or exchange of packets to collect
singleton metrics in an interoperable manner. singleton metrics in an interoperable manner.
With the increasingly wide availability of affordable global With the increasingly wide availability of affordable global
positioning system (GPS) and CDMA based time sources, hosts positioning system (GPS) and CDMA based time sources, hosts
increasingly have available to them very accurate time increasingly have available to them very accurate time
sources--either directly or through their proximity to NTP primary sources--either directly or through their proximity to NTP primary
(stratum 1) time servers. By standardizing a technique for (stratum 1) time servers. By standardizing a technique for
collecting IPPM one-way delay measurements, we hope to create an collecting IPPM one-way delay measurements, we hope to create an
environment where IPPM metrics may be collected across a far broader environment where IPPM metrics may be collected across a far broader
mesh of Internet paths than is currently possible. One particularly mesh of Internet paths than is currently possible. One particularly
skipping to change at page 2, line 37 skipping to change at page 2, line 37
of OWDP test activity by Internet service providers very difficult. of OWDP test activity by Internet service providers very difficult.
Security features include optional authentication and/or encryption Security features include optional authentication and/or encryption
of control and test messages. These features may be useful to of control and test messages. These features may be useful to
prevent unauthorized access to results or man-in-the-middle attackers prevent unauthorized access to results or man-in-the-middle attackers
who attempt to provide special treatment to OWDP test streams or who who attempt to provide special treatment to OWDP test streams or who
attempt to modify sender-generated timestamps to falsify test attempt to modify sender-generated timestamps to falsify test
results. results.
OWDP actually consists of two inter-related protocols: OWDP-Control OWDP actually consists of two inter-related protocols: OWDP-Control
and OWDP-Test with several roles logically separated to allow for and OWDP-Test. OWDP-Control is used to initiate, start, stop and
broad flexibility in use. Specifically, the following roles are retrieve test sessions, while OWDP-Test is the actual one-way delay
logically separate: Control-Client, Retrieve-Client, Server, Session- test protocol that exchanges singleton test packets between two
Source, and Session-Receiver. The relationships between these are measurement nodes.
shown below.
Several roles are logically separated to allow for broad flexibility
in use. Specifically, we define:
Session-Sender the sending endpoint of an OWDP-Test session;
Session-Receiver the receiving endpoint of an OWDP-Test session;
Server an end system that manages one or more OWDP-Test
sessions, is capable of configuring per-session
state in session endpoints, and is capable of
returning the results of a test session;
Control-Client an end system that initiates requests for
OWDP-Test sessions, triggers the start of a set
of sessions, and may trigger their termination;
Retrieve-Client an end system that initiates requests to retrieve
the results of completed OWDP-Test sessions;
One possible scenario of relationships between these roles is shown
below.
+----------------+ +------------------+ +----------------+ +------------------+
| Session-Source |--OWDP-Test-->| Session-Receiver | | Session-Sender |--OWDP-Test-->| Session-Receiver |
+----------------+ +------------------+ +----------------+ +------------------+
^ ^ ^ ^
| | | |
| | | |
V |
+----------------+<---------------------+
| Server |<------------+
+----------------+ |
^ |
| | | |
OWDP-Control OWDP-Control | +----------------+<----------------+
| | | | Server |<-------+
V V | +----------------+ |
| ^ |
| | |
| OWDP-Control OWDP-Control
| | |
v v v
+----------------+ +-----------------+ +----------------+ +-----------------+
| Control-Client | | Retrieve-Client | | Control-Client | | Retrieve-Client |
+----------------+ +-----------------+ +----------------+ +-----------------+
A Control-Client speaks to a Server and may request test session (Unlabeled links in the figure are unspecified by this draft and may
initiation and may request that accepted test sessions be started and be proprietary protocols.)
stopped. A Retrieve-Client also speaks to a Server and may request
the results of an OWDP test session. The test session itself consists
of a stream of singleton OWDP-Test packets sent from Session-Source
to Session-Receiver.
Any combination these logical blocks may, in fact, be collocated. Different logical roles can be played by the same host. For example,
in the figure above, there could actually be only two hosts: one
playing the roles of Control-Client, Retrieve-Client, and Session-
Sender, and the other playing the roles of Server and Session-
Receiver. This is shown below.
[FIXME: Insert interesting examples.] +-----------------+ +------------------+
| Control-Client |<--OWDP-Control-->| Server |
| Retrieve-Client | | |
| Session-Sender |---OWDP-Test----->| Session-Receiver |
+-----------------+ +------------------+
Finally, because many Internet paths include segments that transport Finally, because many Internet paths include segments that transport
IP over ATM, delay and loss measurements can include the effects of IP over ATM, delay and loss measurements can include the effects of
ATM segmentation and reassembly (SAR). Consequently, OWDP has been ATM segmentation and reassembly (SAR). Consequently, OWDP has been
designed to allow for small test packets that would fit inside the designed to allow for small test packets that would fit inside the
payload of a single ATM cell. payload of a single ATM cell (this is only achieved in
unauthenticated and encrypted modes).
3. Protocol Overview 3. Protocol Overview
OWDP actually consists of two inter-related protocols: OWDP-Control OWDP consists of two inter-related protocols: OWDP-Control and OWDP-
and OWDP-Test. The former is layered over TCP and is used to Test. The former is layered over TCP and is used to initiate and
initiate and control measurement sessions and to fetch their results. control measurement sessions and to fetch their results. The latter
The latter protocol is layered over UDP and is used to send singleton protocol is layered over UDP and is used to send singleton
measurement packets along the Internet path under test. measurement packets along the Internet path under test.
The initiator of the measurement session establishes a TCP connection The initiator of the measurement session establishes a TCP connection
to a well-known port on the target point and this connection remains to a well-known port on the target point and this connection remains
open for the duration of the OWDP-Test sessions. IANA will be open for the duration of the OWDP-Test sessions. IANA will be
requested to allocate a well-known port number for OWDP-Control requested to allocate a well-known port number for OWDP-Control
sessions. OWDP server SHOULD listen to this well-known port. sessions. An OWDP server SHOULD listen to this well-known port.
OWDP-Control messages are transmitted only before OWDP-Test sessions OWDP-Control messages are transmitted only before OWDP-Test sessions
actually started and after they complete (with the possible exception are actually started and after they complete (with the possible
of an early Stop-Sessions message). exception of an early Stop-Session message).
The protocol allows negotiating three modes of operation of OWDP- The OWDP-Control and OWDP-Test protocols support three modes of
Control and OWDP-Test: unauthenticated, authenticated, and encrypted. operation: unauthenticated, authenticated, and encrypted. The
If authenticated or encrypted mode is desired, endpoints must possess authenticated or encrypted modes require endpoints to possess a
a shared secret. shared secret.
3.1. OWDP-Control 4. OWDP-Control
The client opens a TCP connection to the server on a well-known port. 4.1. Connection Setup
Before either a Control-Client or a Retrieve-Client can issue
commands of a Server, it must establish a connection to the server.
First, a client opens a TCP connection to the server on a well-known
port. The server responds with a server greeting:
The server responds with server greeting:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Unused (15 octets) . . Unused (15 octets) .
. . . .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Modes | | | Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Challenge (16 octets) . . Challenge (16 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following mode values are meaningful: 1 for unauthenticated, 2 The following mode values are meaningful: 1 for unauthenticated, 2
for authenticated, 4 for encrypted. The value of the Modes field for authenticated, 4 for encrypted. The value of the Modes field
sent by the server is the bit-wise OR of the mode values it is sent by the server is the bit-wise OR of the mode values that it is
willing to support during this session. If Modes is 1, the Challenge willing to support during this session.
field MAY be committed.
If Modes octet is zero (server doesn't wish to communicate with this If the Modes octet is zero, the server doesn't wish to communicate
client), the server MAY close the connection after this message. The with the client and MAY close the connection immediately. The client
client SHOULD close the connection if it gets a greeting with Modes SHOULD close the connection if it gets a greeting with Modes equal to
equal to zero. zero.
Otherwise, the client MUST respond with the following message: Otherwise, the client MUST respond with the following message:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | Unused | | Mode | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KID | | KID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 21 skipping to change at page 6, line 38
. +-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+
| | Yes/No | | | Yes/No |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Server-IV (16 octets) . . Server-IV (16 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here "Yes/No" is either 1 or 0. Yes (0) means that the server A zero value in the "Yes/No" field means that the server accepts the
accepts the authentication and is willing to conduct further authentication and is willing to conduct further transactions. Any
transactions. No (any non-zero value) means that the server doesn't non-zero value means that the server does not accept the
accept authentication provided by the client, or for some other authentication provided by the client or, for some other reason, is
reason is not willing to conduct further transactions in this OWDP- not willing to conduct further transactions in this OWDP-Control
Control session. session. If a "No" response is sent, the server MAY close the
connection after this message. The client SHOULD close the
If a "No" response is sent, the server MAY close the connection after connection if it gets message that says "No" at this stage.
this message. The client SHOULD close the connection if it gets
message that says "No" at this stage.
The previous transactions constitute connection setup. The previous transactions constitute connection setup.
4.2. OWDP-Control Commands
In authenticated or encrypted mode (which are identical as far as In authenticated or encrypted mode (which are identical as far as
OWDP-Control is concerned, and only differ in OWDP-Test) all further OWDP-Control is concerned, and only differ in OWDP-Test) all further
communications are encrypted with the Session-key, using CBC mode. communications are encrypted with the Session-key, using CBC mode.
The client encrypts its stream using Client-IV. The server encrypts The client encrypts its stream using Client-IV. The server encrypts
its stream using Server-IV. its stream using Server-IV.
The following commands are available for the client: Request-Session, The following commands are available for the client: Request-Session,
Start-Sessions, End-Sessions, Retrieve-Session. The command End- Start-Sessions, Stop-Session, Retrieve-Session. The command Stop-
Sessions is available to both client and server. Session is available to both client and server.
[FIXME: move next two paragraphs below?] After Start-Sessions is After Start-Sessions is sent/received by the client/server, and
sent/received by the client/server, and before it both sends and before it both sends and receives Stop-Session (order unspecified),
receives End-Sessions (order unspecified), it is said to be it is said to be conducting active measurements.
conducting active measurements.
While conducting active measurements, the only command available is While conducting active measurements, the only command available is
End-Session. Stop-Session.
3.2. Creating Test Sessions These commands are described in detail below.
4.3. Creating Test Sessions
Individual one-way delay measurement sessions are established using a Individual one-way delay measurement sessions are established using a
simple request/response protocol. An OWDP client, may issue one or simple request/response protocol. An OWDP client MAY issue zero or
more Request-Session messages to an OWDP server, which must respond more Request-Session messages to an OWDP server, which MUST respond
to each with an Accept-Session message. An Accept-Session message may to each with an Accept-Session message. An Accept-Session message
refuse a request. MAY refuse a request.
The format of Request-Session message is as follows: The format of Request-Session message is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Represents | IPVN | Unused | | 1 |IPVN-S | IPVN-R| Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address | | Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (cont.) or Unused | | Sender Address (cont.) or Unused |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | Port | | Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Receiver Address (cont.) or Unused |
| SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Address | | Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Address (cont.) or Unused | | |
| SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Flags | PHB ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inv-Lambda | | Inv-Lambda |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packets | | Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length | | Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time | | Start Time |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accuracy | | Sender Precision | Receiver Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Zero Padding |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here the first octet (1) indicates that this is Request-Session Here the first octet (1) indicates that this is Request-Session
command. command.
Represents can have three values: Source (0), Dest (1), and Third- IPVN-S and IPVN-R are IP version numbers for Sender and Receiver. In
Party(2). It tells the server on whose behalf the client is the case of IP version number being 4, twelve unused octets follow
speaking. the four-octet address.
The meaning of Port depends on the value of Represents. If it is Conf-Sender and Conf-Receiver can be 0 or 1. If 1, the server is
Source, Port is the port to expect OWDP-Test packets from. Is it is being asked to configure the corresponding agent (sender or
Dest, Port is the port to send OWDP-Test packets to. Port is unused receiver). In this case, the corresponding Port value SHOULD be
in the case of a Third-Party client. disregarded by the server. At least one of Conf-Sender and Conf-
Receiver MUST be 1.
The Source Address and Dest Address fields contain respectively the The Sender Address and Receiver Address fields contain respectively
source and destination addresses of the end points of the Internet the sender and receiver addresses of the end points of the Internet
path over which an OWDP test session is requested. The IPVN field path over which an OWDP test session is requested.
contains the IP version number of the source and destination
addresses that follow. In the case of IPVN=4, twelve unused octets
follow each address.
SID is the session identifier. It can be used in later sessions as SID is the session identifier. It can be used in later sessions as
an argument for Retrieve-Session command. It is meaningful only if an argument for Retrieve-Session command. It is meaningful only if
Represents is Dest. Conf-Receiver is 1.
The field Inv-Lambda is an unsigned integer and is the scaled The field Inv-Lambda is an unsigned integer and is the scaled
reciprocal in microseconds of rate at which the Poisson test stream reciprocal of rate (in microseconds) at which the Poisson test stream
is to be generated. This allows the average Poisson sampling is to be generated. This allows the average Poisson sampling
interval for the requested test session to be set to between 1 interval for the requested test session to be set to between 1
microsecond and over an hour. microsecond and over an hour.
The value Packets is the number of active measurement packets to be The value Packets is the number of active measurement packets to be
sent during this OWDP-Test session (note that both server and client sent during this OWDP-Test session (note that both server and client
can abort the session early). can abort the session early).
Padding length is the number of octets to be appended to normal OWDP- Padding length is the number of octets to be appended to normal OWDP-
Test packet (see more on padding in discussion of OWDP-Test). Test packet (see more on padding in discussion of OWDP-Test).
Start Time is the time when the session is to be started (but not
before Start-Sessions command is issued).
Sender Precision and Receiver Precision are signed integers in the
range +32 to -32 indicating the precision of the corresponding
clocks, in seconds to the nearest power of two, as described in
RFC 958. Sender Precision is meaningful only if Conf-Sender is not
set. Receiver Precision is meaningful only if Conf-Receiver is not
set.
To each Request-Session message, an OWDP server MUST respond with an To each Request-Session message, an OWDP server MUST respond with an
Accept-Session message: Accept-Session message:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | | | Accept | Unused | Port |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
| Unused | | SID (16 octets) |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Sender Precision | Receiver Precision |
| SID (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero Padding | | Zero Padding |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zero in the Accept field means that the server is willing to conduct Zero in the Accept field means that the server is willing to conduct
the session. Any non-zero indicates rejection of the request. the session. Any non-zero value indicates rejection of the request.
If the server rejects a Request-Session command, it SHOULD not close If the server rejects a Request-Session command, it SHOULD not close
the TCP connection. The client MAY close it if it gets negative the TCP connection. The client MAY close it if it gets negative
response to Request-Session. response to Request-Session.
The meaning of Port depend on the value of Represents in the query The meaning of Port depend on the values of Conf-Sender and Conf-
that solicited the response. If it was Dest, Port is the port to Receiver in the query that solicited the response. If both were set,
expect OWDP-Test packets from. Is it was Source, Port is the port to Port field is unused. If only Conf-Sender was set, Port is the port
send OWDP-Test packets to. If is was Third-Party, the Port field is to expect OWDP-Test packets from. If only Conf-Receiver was set,
unused. Port is the port to send OWDP-Test packets to.
SID is a locally-unique server-generated session identifier. It can If only Conf-Sender was set, SID is unused. Otherwise, SID is a
be used later as handle to retrieve the results of a session. An unique server-generated session identifier. It can be used later as
OWDP server MUST return an SID, if Represents was Source or Third- handle to retrieve the results of a session.
Party. It is not meaningful if Represents was Dest.
3.3. Starting Test Sessions SIDs SHOULD be constructed by concatenation of 4-octet IPv4 IP number
belonging to the generating machine, 8-octet timestamp, and 4-octet
random value.
Sender Precision and Receiver Precision have the same meaning as in
Request-Session command. Sender Precision is meaningful only if
Conf-Sender is set. Receiver Precision is meaningful only if Conf-
Receiver is set.
4.4. Starting Test Sessions
Having requested one or more test sessions and received affirmative Having requested one or more test sessions and received affirmative
Accept-Session responses, an OWDP client may start the execution of Accept-Session responses, an OWDP client may start the execution of
the requested test sessions by sending a Start-Sessions message to the requested test sessions by sending a Start-Sessions message to
the server. the server.
The format of this message is as follows: The format of this message is as follows:
0 1 2 3 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 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
skipping to change at page 10, line 47 skipping to change at page 12, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept has any non-zero value, the Start-Sessions request was If Accept has any non-zero value, the Start-Sessions request was
rejected; zero means that the command was accepted. The server MAY rejected; zero means that the command was accepted. The server MAY
and the client SHOULD close the connection in the case of a negative and the client SHOULD close the connection in the case of a negative
response. response.
The server SHOULD start all OWDP-Test streams immediately after it The server SHOULD start all OWDP-Test streams immediately after it
sends the response or immediately after their specified start times, sends the response or immediately after their specified start times,
whichever is later. (Note that a client can effect an immediate whichever is later. (Note that a client can effect an immediate
start by specifying in Request-Session a Start Time in the past.) The start by specifying in Request-Session a Start Time in the past.) If
client represents a Source, the client SHOULD start its OWDP-Test the client represents a Sender, the client SHOULD start its OWDP-Test
streams immediately after it sees the Control-Ack response from the streams immediately after it sees the Control-Ack response from the
Server. Server.
3.4. Stop-Sessions 4.5. Stop-Sessions
The Stop-Sessions message may be issued by either the Control-Client The Stop-Sessions message may be issued by either the Control-Client
or the Server. The format of this command is as follows: or the Server. The format of this command is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | | | 3 | Accept | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Unused | | Unused |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding (16 octets) | | Zero Padding (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Normally, the client SHOULD send this command after the OWDP-Test Normally, the client SHOULD send this command after the OWDP-Test
streams have completed. However, either client or server MAY send it streams have completed. However, either client or server MAY send it
prematurely. prematurely.
Non-zero value of Accept indicates a failure of some sort. Zero
values indicates normal (but possibly premature) completion. If
Accept had non-zero value (from either party), or if it was not
transmitted at all (for whatever reason, including TCP connection
used for OWDP-Control breaking), results of all OWDP-Test sessions
spawned by this OWDP-Control session SHOULD be considered invalid,
even if Retrieve-Session with SID from this session works during a
different OWDP-Control session.
The party that receives this command MUST stop its OWDP-Test streams The party that receives this command MUST stop its OWDP-Test streams
and respond with a Control-Ack message. Any non-zero value in Accept and respond with a Stop-Sessions message. Any non-zero value in
field means something went wrong. A zero value means OWDP-Test Accept field means something went wrong. A zero value means OWDP-
streams have been successfully stopped. Test streams have been successfully stopped.
3.5. Retrieve-Session 4.6. Retrieve-Session
The format of this client command is as follows: The format of this client command is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | | | 4 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused | | Unused |
| | | |
skipping to change at page 12, line 17 skipping to change at page 13, line 36
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with a Control-Ack message. Again, any non- The server MUST respond with a Control-Ack message. Again, any non-
zero value in the Accept field means rejection of command. Zero zero value in the Accept field means rejection of command. Zero
means that data will follow. means that data will follow.
If Yes/No was 0, the server then MUST send the OWDP-Test session data If Yes/No was 0, the server then MUST send the OWDP-Test session data
in question, followed by 16 octets of zero padding. in question, followed by 16 octets of zero padding.
The transmission starts with 4 octets that contain the number of
records that will follow, each record representing one received
packet. This is followed by 2 octets of Sender Precision, 2 octets
of Receiver precision, and 8 octets of zero padding.
Each packet is represented with 20 octets, and includes 4 octets of Each packet is represented with 20 octets, and includes 4 octets of
sequence number, 8 octets of send timestamp, and 8 octets of receive sequence number, 8 octets of send timestamp, and 8 octets of receive
timestamp. timestamp.
The last (possibly full, possibly incomplete) block (16 octets) of The last (possibly full, possibly incomplete) block (16 octets) of
data is padded with zeros. A zero padding consisting of 16 octets is data is padded with zeros. A zero padding consisting of 16 octets is
then appended. then appended.
4. OWDP-Test 5. OWDP-Test
This section describes OWDP-Test protocol. It runs over UDP using This section describes OWDP-Test protocol. It runs over UDP using
source and destination IP and port numbers negotiated during Session- sender and receiver IP and port numbers negotiated during Session-
Prepare exchange. Prepare exchange.
As OWDP-Control, OWDP-Test has three modes: unauthenticated, As OWDP-Control, OWDP-Test has three modes: unauthenticated,
authenticated, and encrypted. All OWDP-Test sessions spawned by an authenticated, and encrypted. All OWDP-Test sessions spawned by an
OWDP-Control session inherit its mode. OWDP-Control session inherit its mode.
OWDP-Control client, OWDP-Control server, OWDP-Test sender, and OWDP- OWDP-Control client, OWDP-Control server, OWDP-Test sender, and OWDP-
Test receiver can potentially all be different machines. (In a Test receiver can potentially all be different machines. (In a
typical case we expect that there will be only two machines.) typical case we expect that there will be only two machines.)
4.1. Sender Behavior 5.1. Sender Behavior
The sender sends the receiver a stream of packets with Poisson The sender sends the receiver a stream of packets with Poisson
distribution of times between packets. The format of the body of a distribution of times between packets. The format of the body of a
UDP packet in the stream depends on the mode being used. UDP packet in the stream depends on the mode being used.
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Zero padding (0-65515 octets) . . Packet padding (0-65515 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated mode: For authenticated mode:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Zero Padding | | Zero Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Zero padding (0-65503 octets) . . Packet padding (0-65503 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For encrypted mode: For encrypted mode:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero Padding | | Zero Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Zero padding (0-65511 octets) . . Packet padding (0-65511 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of timestamp is the same as that of NTP v3 protocol The format of timestamp is the same as that of NTP v3 protocol
[RFC958]. Quoting from RFC 958: [RFC958]. Quoting from RFC 958:
NTP timestamps are represented as a 64-bit fixed-point number, in NTP timestamps are represented as a 64-bit fixed-point number, in
seconds relative to 0000 UT on 1 January 1900. The integer part seconds relative to 0000 UT on 1 January 1900. The integer part
is in the first 32 bits and the fraction part in the last 32 bits, is in the first 32 bits and the fraction part in the last 32 bits,
skipping to change at page 14, line 46 skipping to change at page 16, line 32
The minimum data segment length is therefore 12 octets in The minimum data segment length is therefore 12 octets in
unauthenticated mode, 24 octets in authenticated mode, and 16 octets unauthenticated mode, 24 octets in authenticated mode, and 16 octets
in encrypted mode. in encrypted mode.
In authenticated and encrypted mode, the first block (16 octets) of In authenticated and encrypted mode, the first block (16 octets) of
each packet is encrypted using AES ECB mode. each packet is encrypted using AES ECB mode.
In unauthenticated mode, no encryption is applied. In unauthenticated mode, no encryption is applied.
The time elapsed between packets is (pseudo) random, with exponential The time elapsed between packets is pseudo-random, with exponential
(Poisson) distribution. As suggested in RFC 2330, the ith sampling distribution (resulting in a Poisson stream of packets). As
interval Ei may be computed using inverse transform: suggested in RFC 2330, the ith sampling interval Ei may be computed
using inverse transform:
Ei = -log(Ui) / lambda Ei = -ln(Ui) * Inv-Lambda
where Ui is uniformly distributed between 0 and 1 and obtained using
AES with SID as the key, running in counter mode (first encrypted
block is 0, second encrypted block is 1 in network octet order, etc.)
and lambda is the desired mean rate of the sampling distribution.
[FIXME: should state precisely how the 16 byte block is interpreted
as a number between 0 and 1].
The parameter lambda is has the value requested in the Request-Session where Ui is uniformly distributed between 0 and 1 and lambda is the
message of the OWDP-Control negotiation that spawned the session. desired mean time between packets.
The logarithm and division in the formula above MUST be computed using Pseudo-random stream of bits is obtained using AES with SID as the
IEEE 754 standard floating point arithmetic. [HELP WANTED!: Someone key, running in counter mode (first encrypted block is 0, second
with a stronger background in numerical analysis to specify how to encrypted block is 1 in network octet order, etc.) Each block of 64
compute the sampling intervals precisely and portably!] bits is used to obtain one pseudo-random number uniformly distributed
between 0 and 1. If the bits are Bj (j=1..64, numbered left to
right), the resulting value is
U = B1*2^{-1} + B2*2^{-2} + ... B64*2^{-64}
4.2. Receiver Behavior The parameter lambda is has the value requested in the Request-
Session message of the OWDP-Control negotiation that spawned the
session.
FIXME: Expand this sketch. The logarithm and division in the formula above MUST be computed
using IEEE 754 standard floating point arithmetic. [HELP WANTED!:
Someone with a stronger background in numerical analysis to specify
how to compute the sampling intervals precisely and portably!]
Finally, Packet Padding SHOULD be pseudo-random (generated
independently of any other pseudo-random numbers mentioned in this
document). However, implementations MUST provide a configuration
parameter, an option, or a different means of making Packet Padding
consist of all zeros.
5.2. Receiver Behavior
Receiver knows when the sender will send packets. The following
parameter is defined: loss threshold. It SHOULD be 10 minutes and
MAY be more, but not more than 60 minutes.
As packets are received, As packets are received,
+ Timestamp the received packet. + Timestamp the received packet.
+ In authenticated or encrypted mode, decrypt first block (16
octets) of packet body.
+ Store the packet sequence number, send times, and receive times + Store the packet sequence number, send times, and receive times
for the results to be transferred. for the results to be transferred.
+ Packets not received within parameter Tl, the loss threshold are + Packets not received within the loss threshold are considered
considered lost. FIXME: loss threshold not mentioned above. also lost. They are recorded with their seqno, presumed send time, and
need to decide if the receiver knows which packets are lost, and receive time consisting of a string of zero bits.
if so how is it represented in the results perhaps (seqno presumed
send time, receive time of 0).
5. Security Considerations Packets that have send time in the future MUST be recorded normally,
without changing their send timestamp, unless they have to be
discarded.
The goal of authenticated mode to let one be able to password-protect If any of the following is true, packet MUST be discarded:
service provided by a particular OWDP-Control server. One can
imagine a variety of circumstances where this could be useful. + Send timestamp is more than loss threshold in the past or in the
Authenticated mode is designed to prohibit theft of service. future.
+ Send timestamp differs by more than loss threshold from the time
when the packet should have been sent according to its seqno.
+ In authenticated or encrypted mode, any of the bits of zero
padding inside the first 16 octets of packet body is non-zero.
6. Security Considerations
The goal of authenticated mode to let one password-protect service
provided by a particular OWDP-Control server. One can imagine a
variety of circumstances where this could be useful. Authenticated
mode is designed to prohibit theft of service.
Additional design objective of authenticated mode was to make it Additional design objective of authenticated mode was to make it
impossible for an attacker who cannot read traffic between OWDP-Test impossible for an attacker who cannot read traffic between OWDP-Test
sender and receiver to tamper with test results in a fashion that sender and receiver to tamper with test results in a fashion that
affects the measurements, but not other traffic. affects the measurements, but not other traffic.
The goal of encrypted mode is quite different: To make it hard for a The goal of encrypted mode is quite different: To make it hard for a
party in the middle of the network to make results look "better" than party in the middle of the network to make results look "better" than
they should be. This is especially true if one of client and server they should be. This is especially true if one of client and server
doesn't coincide with neither sender nor receiver. doesn't coincide with neither sender nor receiver.
Encryption of OWDP-Control using AES CBC mode with blocks of zeros Encryption of OWDP-Control using AES CBC mode with blocks of zeros
after each message aims to achieve two goals: (i) to provide secrecy after each message aims to achieve two goals: (i) to provide secrecy
of exchange; (ii) to provide authentication of each message. of exchange; (ii) to provide authentication of each message.
FIXME: More stuff to go here. OWDP-Test sessions directed at an unsuspecting party could be used
for denial of service (DoS) attacks. In unauthenticated mode servers
should limits receivers to hosts they control or to the OWDP-Control
client.
OWDP-Test sessions could be used as covert channels of information.
Environments that are worried about covert channels should take this
into consideration.
Notice that AES in counter mode is used for pseudo-random number Notice that AES in counter mode is used for pseudo-random number
generation, so implementation of AES MUST be included even in a generation, so implementation of AES MUST be included even in a
server that only supports unauthenticated mode. server that only supports unauthenticated mode.
6. References 7. References
[AES] Advanced Encryption Standard (AES), [AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/ http://csrc.nist.gov/encryption/aes/
[RFC958]D. Mills, "Network Time Protocol (NTP)", RFC 958, September [RFC958]D. Mills, "Network Time Protocol (NTP)", RFC 958, September
1985. 1985.
[RFC2026]S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026]S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. RFC 2026, October 1996.
skipping to change at page 16, line 41 skipping to change at page 19, line 14
[RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, "Framework [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, "Framework
for IP Performance Metrics" RFC 2330, May 1998. for IP Performance Metrics" RFC 2330, May 1998.
[RFC2679]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay [RFC2679]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999. Metric for IPPM", RFC 2679, September 1999.
[RFC2680]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet [RFC2680]G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999. Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2836]S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior
Identification Codes", RFC 2836, May 2000.
[RIPE] Ripe Test-Traffic Home page, http://www.ripe.net/test- [RIPE] Ripe Test-Traffic Home page, http://www.ripe.net/test-
traffic/. traffic/.
[RIPE-NLUUG]H. Uijterwaal and O. Kolkman, "Internet Delay [RIPE-NLUUG]H. Uijterwaal and O. Kolkman, "Internet Delay
Measurements Using Test-Traffic", Spring 1998 Dutch Unix User Measurements Using Test-Traffic", Spring 1998 Dutch Unix User
Group Meeting, http://www.ripe.net/ripencc/mem- Group Meeting, http://www.ripe.net/ripencc/mem-
services/ttm/Talks/9805_nluug.ps.gz. (NOTE: it's actually services/ttm/Talks/9805_nluug.ps.gz. (NOTE: it's actually
postscript, not gzip'd postscript.) postscript, not gzip'd postscript.)
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.
[SURVEYOR-INET]S. Kalidindi and M. Zekauskas, "Surveyor: An [SURVEYOR-INET]S. Kalidindi and M. Zekauskas, "Surveyor: An
Infrastructure for Network Performance Measurements", Infrastructure for Network Performance Measurements",
Proceedings of INET'99, June 1999. Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
7. Authors' Addresses 8. Authors' Addresses
Stanislav Shalunov Stanislav Shalunov
Internet2 / UCAID Internet2 / UCAID
200 Business Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1182 Phone: +1 914 765 1182
EMail: shalunov@internet2.edu EMail: shalunov@internet2.edu
Benjamin Teitelbaum Benjamin Teitelbaum
Advanced Network & Services Advanced Network & Services
200 Business Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1118 Phone: +1 914 765 1118
EMail: ben@advanced.org EMail: ben@advanced.org
Matthew J. Zekauskas Matthew J. Zekauskas
skipping to change at page 17, line 37 skipping to change at page 20, line 20
Phone: +1 914 765 1118 Phone: +1 914 765 1118
EMail: ben@advanced.org EMail: ben@advanced.org
Matthew J. Zekauskas Matthew J. Zekauskas
Advanced Network & Services, Inc. Advanced Network & Services, Inc.
200 Business Park Drive 200 Business Park Drive
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1112 Phone: +1 914 765 1112
EMail: kalidindi@advanced.org EMail: matt@advanced.org
Expiration date: May 2001 Expiration date: June 2001
 End of changes. 

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