draft-ietf-ippm-owdp-11.txt   draft-ietf-ippm-owdp-12.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: April 2005 Anatoly Karp Expiration Date: June 2005 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
October 2004 December 2004
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-11.txt> <draft-ietf-ippm-owdp-12.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 26 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 26
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 26 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 26
4.1.2. Packet Format and Content . . . . . . . . . . . . 27 4.1.2. Packet Format and Content . . . . . . . . . . . . 27
4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 30 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 30
5. Computing Exponentially Distributed Pseudo-Random Numbers . 32 5. Computing Exponentially Distributed Pseudo-Random Numbers . 32
5.1. High-Level Description of the Algorithm . . . . . . . 32 5.1. High-Level Description of the Algorithm . . . . . . . 32
5.2. Data Types, Representation, and Arithmetic . . . . . . 33 5.2. Data Types, Representation, and Arithmetic . . . . . . 33
5.3. Uniform Random Quantities . . . . . . . . . . . . . . 34 5.3. Uniform Random Quantities . . . . . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . 35
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 35 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 35
6.2. Preventing Third-Party Denial of Service . . . . . . . 35 6.2. Preventing Third-Party Denial of Service . . . . . . . 36
6.3. Covert Information Channels . . . . . . . . . . . . . 35 6.3. Covert Information Channels . . . . . . . . . . . . . 36
6.4. Requirement to Include AES in Implementations . . . . 35 6.4. Requirement to Include AES in Implementations . . . . 36
6.5. Resource Use Limitations . . . . . . . . . . . . . . . 36 6.5. Resource Use Limitations . . . . . . . . . . . . . . . 36
6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 37 6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 37
6.7. Required Properties of MD5 . . . . . . . . . . . . . . 38 6.7. Required Properties of MD5 . . . . . . . . . . . . . . 38
6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 39 6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 40
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
8. Internationalization Considerations . . . . . . . . . . . . 40 8. Internationalization Considerations . . . . . . . . . . . . 41
9. Appendix A: Sample C Code for Exponential Deviates . . . . 41 9. Appendix A: Sample C Code for Exponential Deviates . . . . 41
10. Appendix B: Test Vectors for Exponential Deviates . . . . 46 10. Appendix B: Test Vectors for Exponential Deviates . . . . 46
11. Normative References . . . . . . . . . . . . . . . . . . . 46 11. Normative References . . . . . . . . . . . . . . . . . . . 47
12. Informative References . . . . . . . . . . . . . . . . . . 47 12. Informative References . . . . . . . . . . . . . . . . . . 47
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
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
[RFC2680] across Internet paths. Although there are now several [RFC2680] 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 not currently a standard that would [SURVEYOR], [RIPE], there is not currently a standard that would
skipping to change at page 20, line 13 skipping to change at page 20, line 13
range of packets that were not sent: range of packets that were not sent:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped | | First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped | | Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The last (possibly full, possibly incomplete) block (16 octets) of Skip Ranges MUST be in order. The last (possibly full, possibly
data MUST be padded with zeros, if necessary. This ensures that the incomplete) block (16 octets) of data MUST be padded with zeros, if
next session description record starts on a block boundary. necessary. This ensures that the next session description record
starts on a block boundary.
Finally, a single block (16 octets) of IZP is concatenated on the end Finally, a single block (16 octets) of IZP is concatenated on the end
to complete the Stop-Sessions message. to complete the Stop-Sessions message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 17 skipping to change at page 23, line 18
between Start-Sessions and Stop-Sessions, incomplete requests can between Start-Sessions and Stop-Sessions, incomplete requests can
only happen on a different OWAMP-Control connection (from the same or only happen on a different OWAMP-Control connection (from the same or
different host as Control-Client). different host as Control-Client).
The server MUST respond with a Fetch-Ack message. The format of this The server MUST respond with a Fetch-Ack message. The format of this
server response is as follows: server response 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Complete | Unused (2 octets) | | Accept | Finished | Unused (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno | | Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges | | Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records | | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, non-zero in the Accept field means a rejection of command. Again, non-zero in the Accept field means a rejection of command.
The server MUST specify zero for all remaining fields if Accept is The server MUST specify zero for all remaining fields if Accept is
non-zero. The client MUST ignore all remaining fields (except for the non-zero. The client MUST ignore all remaining fields (except for the
IZP) if Accept is non-zero. The full list of available Accept values IZP) if Accept is non-zero. The full list of available Accept values
is described in the ``Values of the Accept Field'' section. is described in the ``Values of the Accept Field'' section.
Complete is non-zero if the OWAMP-Test session has terminated. Finished is non-zero if the OWAMP-Test session has terminated.
Next Seqno indicates the next sequence number that would have been Next Seqno indicates the next sequence number that would have been
sent from this send session. For completed sessions, this will equal sent from this send session. For completed sessions, this will equal
NumPackets from the Request-Session. NumPackets from the Request-Session. This information is only
available if the session has terminated. If Finished is zero, then
Next Seqno MUST be set to zero by the server.
Number of Skip Ranges indicates the number of holes that actually Number of Skip Ranges indicates the number of holes that actually
occurred in the sending process. occurred in the sending process. This information is only available
if the session has terminated. If Finished is zero, then Skip Ranges
MUST be set to zero by the server.
Number of Records is the number of packet records that fall within Number of Records is the number of packet records that fall within
the requested range. This number might be less than the Number of the requested range. This number might be less than the Number of
Packets in the reproduction of the Request-Session command because of Packets in the reproduction of the Request-Session command because of
a session that ended prematurely or it might be greater because of a session that ended prematurely or it might be greater because of
duplicates. duplicates.
If Accept was non-zero, this concludes the response to the Fetch- If Accept was non-zero, this concludes the response to the Fetch-
Session message. If Accept was 0, the server then MUST immediately Session message. If Accept was 0, the server then MUST immediately
send the OWAMP-Test session data in question. send the OWAMP-Test session data in question.
The OWAMP-Test session data consists of the following (concatenated): The OWAMP-Test session data consists of the following (concatenated):
+ A reproduction of the Request-Session command that was used to + A reproduction of the Request-Session command that was used to
start the session; it is modified so that actual sender and start the session; it is modified so that actual sender and
receiver port numbers that were used by the OWAMP-Test session receiver port numbers that were used by the OWAMP-Test session
always appear in the reproduction. always appear in the reproduction.
+ 16 octets of IZP.
+ Zero or more (as specified) Skip Range descriptions. The last + Zero or more (as specified) Skip Range descriptions. The last
(possibly full, possibly incomplete) block (16 octets) of Skip (possibly full, possibly incomplete) block (16 octets) of Skip
Range descriptions is padded with zeros if necessary. (These Range descriptions is padded with zeros if necessary. (These
zeros are simple padding and should be distinguished from the 16 zeros are simple padding and should be distinguished from the 16
octets of IZP that follow.) octets of IZP that follow.)
+ 16 octets of IZP. + 16 octets of IZP.
+ Zero or more (as specified) packet records. The last (possibly + Zero or more (as specified) packet records. The last (possibly
full, possibly incomplete) block (16 octets) of data is padded full, possibly incomplete) block (16 octets) of data is padded
skipping to change at page 29, line 35 skipping to change at page 29, line 35
The OWAMP-Test packet layout is the same in authenticated and The OWAMP-Test packet layout is the same in authenticated and
encrypted modes. The encryption operations are, however, different. encrypted modes. The encryption operations are, however, different.
The difference is that in encrypted mode both the sequence number and The difference is that in encrypted mode both the sequence number and
the timestamp are encrypted to provide maximum data integrity the timestamp are encrypted to provide maximum data integrity
protection while in authenticated mode the sequence number is protection while in authenticated mode the sequence number is
encrypted and the timestamp is sent in clear text. Sending the encrypted and the timestamp is sent in clear text. Sending the
timestamp in clear text in authenticated mode allows one to reduce timestamp in clear text in authenticated mode allows one to reduce
the time between when a timestamp is obtained by a sender and when the time between when a timestamp is obtained by a sender and when
the packet is shipped out. In encrypted mode, the sender has to the packet is shipped out. In encrypted mode, the sender has to
fetch the timestamp, encrypt it, and send it; in authenticated mode, fetch the timestamp, encrypt it, and send it; in authenticated mode,
the middle step is removed, improving accuracy (the sequence number the middle step is removed, potentially improving accuracy (the
can be encrypted before the timestamp is fetched). sequence number can be encrypted before the timestamp is fetched).
In authenticated mode, the first block (16 octets) of each packet is In authenticated mode, the first block (16 octets) of each packet is
encrypted using AES Electronic Cookbook (ECB) mode. The key to use encrypted using AES Electronic Cookbook (ECB) mode.
is the same key as is used for the corresponding OWAMP-Control
session (where it is used in a different chaining mode). ECB mode The key to use is obtained as follows: the 16-octet session
does not involve any actual chaining; this way, lost, duplicated, or identifier (SID) is encrypted with the same session key as is used
reordered packets do not cause problems with deciphering any packet for the corresponding OWAMP-Control session (where it is used in a
in an OWAMP-Test session. different chaining mode); this is a single-block ECB encryption; its
result is the key to use in encrypting (and decrypting) the packets
of the particular OWAMP-Test session.
ECB mode used for encrypting the first block of OWAMP-Test packets in
authenticated mode does not involve any actual chaining; this way,
lost, duplicated, or reordered packets do not cause problems with
deciphering any packet in an OWAMP-Test session.
In encrypted mode, the first two blocks (32 octets) are encrypted In encrypted mode, the first two blocks (32 octets) are encrypted
using AES CBC mode. The key to use is the same key as is used for using AES CBC mode. The key to use is obtained in the same way as
the corresponding OWAMP-Control session. Each OWAMP-Test packet is the key for authenticated mode. Each OWAMP-Test packet is encrypted
encrypted as a separate stream, with just one chaining operation; as a separate stream, with just one chaining operation; chaining does
chaining does not span multiple packets so that lost, duplicated, or not span multiple packets so that lost, duplicated, or reordered
reordered packets do not cause problems. packets do not cause problems. The initialization vector for the CBC
encryption is a string of zeros.
Implementation note: Naturally, the key schedule for each OWAMP-Test
session need only be set up once per session, not once per packet.
In unauthenticated mode, no encryption is applied. In unauthenticated mode, no encryption is applied.
Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be
generated independently of any other pseudo-random numbers mentioned generated independently of any other pseudo-random numbers mentioned
in this document). However, implementations MUST provide a in this document). However, implementations MUST provide a
configuration parameter, an option, or a different means of making configuration parameter, an option, or a different means of making
Packet Padding consist of all zeros. Packet Padding consist of all zeros.
The time elapsed between packets is computed according to the slot The time elapsed between packets is computed according to the slot
skipping to change at page 49, line 31 skipping to change at page 50, line 4
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgments Acknowledgments
We would like to thank Guy Almes, Hamid Asgari, Steven Van den We would like to thank Guy Almes, Hamid Asgari, Steven Van den
Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly, Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly,
Kaynam Hedayat, Petri Helenius, Kitamura Yasuichi, Daniel H. T. R. Susan Evett, Kaynam Hedayat, Petri Helenius, Kitamura Yasuichi,
Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Al Morton, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin,
Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy Scherrer, Henk Al Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy
Uijterwaal, and Sam Weiler for their comments, suggestions, reviews, Scherrer, Henk Uijterwaal, and Sam Weiler for their comments,
helpful discussion and proof-reading. suggestions, reviews, helpful discussion and proof-reading.
Expiration date: April 2005 Expiration date: June 2005
 End of changes. 

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