--- 1/draft-ietf-ippm-owdp-08.txt 2006-02-04 23:45:58.000000000 +0100 +++ 2/draft-ietf-ippm-owdp-09.txt 2006-02-04 23:45:58.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group Stanislav Shalunov Internet Draft Benjamin Teitelbaum -Expiration Date: November 2004 Anatoly Karp +Expiration Date: January 2005 Anatoly Karp Jeff W. Boote Matthew J. Zekauskas Internet2 - May 2004 + July 2004 A One-way Active Measurement Protocol (OWAMP) - + 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -301,28 +301,43 @@ first 29 bits. In unauthenticated mode, Username, Token, and Client-IV are unused. Otherwise, Username is a 16-octet indicator of which shared secret the client wishes to use to authenticate or encrypt and Token is the concatenation of a 16-octet challenge and a 16-octet Session-key, encrypted using the AES (Advanced Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be performed using an Initialization Vector (IV) of zero and a key value that is the shared - secret associated with Username. The shared secret will typically be - provided as a passphrase; in this case, the MD5 sum [RFC1321] of the - passphrase (without possible newline character(s) at the end of the - passphrase) SHOULD be used as a key for encryption by the client and - decryption by the server (the passphrase also SHOULD NOT contain - newlines in the middle). + secret associated with Username. (Both the server and the client use + the same mappings from user names to secret keys; the server, being + prepared to conduct sessions with more than one client, uses user + names to choose the appropriate secret key; a client would typically + have different secret keys for different servers. The situation is + analogous to that of passwords, except that secret keys, rather than + being the typical low-entropy passwords, are suitable for use as AES + keys.) The shared secret will typically be provided as a passphrase; + in this case, the MD5 sum [RFC1321] of the passphrase (without + possible newline character(s) at the end of the passphrase) SHOULD be + used as a key for encryption by the client and decryption by the + server (the passphrase also SHOULD NOT contain newlines in the + middle). Session-key and Client-IV are generated randomly by the client. + Session-key MUST be generated with sufficient entropy not to reduce + the security of the underlying cipher. Client-IV merely needs to be + unique (i.e., it MUST never be repeated for different sessions using + the same secret key; a simple way to achieve that without the use of + cumbersome state is to generate the Client-IV strings using a + cryptographically secure pseudo-random number source: if this is + done, the first repetition is unlikely to occur before 2^64 sessions + with the same secret key are conducted). The server MUST respond with the following message: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Unused, MBZ (15 octets) | | | | +-+-+-+-+-+-+-+-+ @@ -334,21 +349,25 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Uptime (Timestamp) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Zero Padding (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Unused 15-octet part MUST be zero. The client MUST ignore its - value. + value. MBZ (MUST be zero) fields here and hereafter have the same + semantics: the party that sends the message MUST set the field to a + string of zero bits; the party that interprets the message MUST + ignore the value. (This way the field could be used for future + extensions.) Server-IV is generated randomly by the server. In unauthenticated mode, Server-IV is unused. A zero value in the Accept field means that the server accepts the authentication and is willing to conduct further transactions. A value of 1 means that the server does not accept the authentication provided by the client or, for some other reason, is not willing to conduct further transactions in this OWAMP-Control session. All other values are reserved. The client MUST interpret all values of @@ -615,25 +635,25 @@ communication is IPv6-based. If it has no IPv4 addresses at all, the last 4 octets of an IPv6 address can be used instead. Note that SID is always chosen by the receiver. If truly random values are not available, it is important that SID be made unpredictable as knowledge of SID might be used for access control. 5.4. Send Schedules The sender and the receiver need to both know the same send schedule. This way, when packets are lost, the receiver knows when they were - sent. It is desirable to compress common schedules and still to be - able to use an arbitrary one for the test sessions. In many cases, - the schedule will consist of repeated sequences of packets: this way, - the sequence performs some test, and the test is repeated a number of - times to gather statistics. + supposed to be sent. It is desirable to compress common schedules + and still to be able to use an arbitrary one for the test sessions. + In many cases, the schedule will consist of repeated sequences of + packets: this way, the sequence performs some test, and the test is + repeated a number of times to gather statistics. To implement this, we have a schedule with a given number of `slots'. Each slots has a type and a parameter. Two types are supported: exponentially distributed pseudo-random quantity (denoted by a code of 0) and a fixed quantity (denoted by a code of 1). The parameter is expressed as a timestamp and specifies a time interval. For a type 0 slot (exponentially distributed pseudo-random quantity) this interval is the mean value (or 1/lambda if the distribution density function is expressed as lambda*exp(-lambda*x) for positive values of x). For a type 1 slot, the parameter is the delay itself. The @@ -819,23 +839,23 @@ the Request-Session command. If a receiver of an OWAMP-Test session learns through OWAMP-Control Stop-Sessions message that the OWAMP-Test sender's last sequence number is lower than any sequence number actually received, the results of the complete OWAMP-Test session MUST be invalidated. A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control Stop-Sessions command, MUST discard any packet records -- including lost packet records -- with a (computed) send time that falls between - the current time minus timeout and the current time. This ensures + the current time minus Timeout and the current time. This ensures statistical consistency for the measurement of loss and duplicates in - the event that the timeout is greater than the time it takes for the + the event that the Timeout is greater than the time it takes for the Stop-Sessions command to take place. To effect complete sessions, each side of the control connection SHOULD wait until all Sessions are complete before sending the Stop- Sessions message. The completed time of each sessions is determined as Timeout after the scheduled time for the last sequence number. Endpoints MAY add a small increment to the computed completed time for send endpoints to ensure the Stop-Sessions message reaches the receiver endpoint after Timeout. @@ -906,21 +926,21 @@ command because of a session that ended prematurely; or it might be greater because of duplicates. + 12 octets of Integrity Zero Padding. + Zero or more (as specified) packet records. Each packet record is 25 octets, and includes 4 octets of sequence number, 8 octets of send timestamp, 2 octets of send timestamp error estimate, 8 octets of receive timestamp, and 2 octets of receive - timestamp error estimate and 1 octet of TTL (in this order): + timestamp error estimate and 1 octet of TTL (or Hop Limit in IPv6): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00| Seq Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 04| Send Timestamp | 08| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Send Error Estimate | | @@ -932,25 +952,37 @@ 24| TTL | +-+-+-+-+-+-+-+-+ Packet records are sent out in the same order they are made when the results of the session are recorded. Therefore, the data is in arrival order. Note that lost packets (if any losses were detected during the OWAMP- Test session) MUST appear in the sequence of packets. They can appear either at the point when the loss was detected or at any later - point. Lost packet records are distinguished by the receive - timestamp consisting of a string of zero bits and an error estimate - with Multiplier=1, Scale=64, and S=0 (see OWAMP-Test description for - definition of these quantities and explanation of timestamp format - and error estimate format). + point. Lost packet records are distinguished as follows: + + + A send timestamp filled with the presumed send time (as computed + by the send schedule). + + + A send error estimate filled with Multiplier=1, Scale=64, and S=0 + (see the OWAMP-Test description for definition of these quantities + and explanation of timestamp format and error estimate format). + + + A receive timestamp consisting of all zero bits. + + + A normal receive error estimate as determined by the error of the + clock being used to declare the packet lost (it MUST be declared + lost if it is not received Timeout after the presumed send time as + determined by the receivers clock). + + + A TTL value of 255. The last (possibly full, possibly incomplete) block (16 octets) of data is padded with zeros if necessary. (These zeros are simple padding and should be distinguished from the 16 octets of Integrity Zero Padding that follow the session data and conclude the response to Fetch-Session.) 6. OWAMP-Test This section describes OWAMP-Test protocol. It runs over UDP using @@ -962,22 +994,23 @@ OWAMP-Control session inherit its mode. OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and OWAMP-Test receiver can potentially all be different machines. (In a typical case we expect that there will be only two machines.) 6.1. Sender Behavior The sender sends the receiver a stream of packets with schedule as specified in the Request-Session command. The sender SHOULD set the - TTL in the UDP packet to 255. The format of the body of a UDP packet - in the stream depends on the mode being used. + TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The + format of the body of a UDP packet in the stream depends on the mode + being used. For unauthenticated mode: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | @@ -1106,47 +1142,52 @@ Receiver knows when the sender will send packets. The following parameter is defined: Timeout (from Request-Session). Packets that are delayed by more than Timeout are considered lost (or `as good as lost'). Note that there is never an actual assurance of loss by the network: a `lost' packet might still be delivered at any time. The original specification for IPv4 required that packets be delivered within TTL seconds or never (with TTL having a maximum value of 255). To the best of the authors' knowledge, this requirement was never actually implemented (and of course only a complete and universal implementation would ensure that packets don't travel for longer than - TTL seconds). Further, IPv4 specification makes no claims about the - time it takes the packet to traverse the last link of the path. + TTL seconds). In fact, in IPv6 the name of this field has actually + been changed to Hop Limit. Further, IPv4 specification makes no + claims about the time it takes the packet to traverse the last link + of the path. The choice of a reasonable value of Timeout is a problem faced by a user of OWAMP protocol, not by an implementor. A value such as two minutes is very safe. Note that certain applications (such as interactive `one-way ping') might wish to obtain the data faster than that. As packets are received, + Timestamp the received packet. + In authenticated or encrypted mode, decrypt first block (16 octets) of packet body. + Store the packet sequence number, send time, receive time, and the - TTL from the packet IP header for the results to be transferred. + TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for + the results to be transferred. + Packets not received within the Timeout are considered lost. They are recorded with their true seqno, presumed send time, receive - time consisting of a string of zero bits, and TTL of 255. + time consisting of a string of zero bits, and TTL (or Hop Limit) + of 255. - Implementations SHOULD fetch the TTL value from the IP header of the - packet. If an implementation does not fetch the actual TTL value - (the only good reason to not do so is inability to access the TTL - field of arriving packets), it MUST record the TTL value as 255. + Implementations SHOULD fetch the TTL/Hop Limit value from the IP + header of the packet. If an implementation does not fetch the actual + TTL value (the only good reason to not do so is inability to access + the TTL field of arriving packets), it MUST record the TTL value as + 255. Packets that are actually received are recorded in the order of arrival. Lost packet records serve as indications of the send times of lost packets. They SHOULD be placed either at the point where the receiver learns about the loss or at any later point; in particular, one MAY place all the records that correspond to lost packets at the very end. Packets that have send time in the future MUST be recorded normally, without changing their send timestamp, unless they have to be @@ -1339,20 +1379,64 @@ client. OWAMP-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 generation, so implementation of AES MUST be included even in a server that only supports unauthenticated mode. +9.1. An OWAMP server can consume resources of various kinds. The two + most important kinds of resources are network capacity and memory + (primary or secondary) for storing test results. + + Any implementation of OWAMP server MUST include technical mechanisms + to limit the use of network capacity and memory. Mechanisms for + managing the resources consumed by unauthenticated users and users + authenticated with a username and passphrase SHOULD be separate. The + default configuration of an implementation MUST enable these + mechanisms and set the resource use limits to conservatively low + values. + + One way to design the resource limitation mechanisms is as follows: + assign each session to a user class. User classes are partially + ordered with ``includes'' relation, with one class (``all users'') + that is always present and that includes any other class. The + assignment of a session to a user class can be based on the presence + of authentication of the session, the user name, IP address range, + time of day, and, perhaps, other factors. Each user class would have + a limit for usage of network capacity (specified in units of + bit/second) and memory for storing test results (specified in units + of octets). Along with the limits for resource use, current use + would be tracked by the server. When a session is requested by a + user in a specific user class, the resources needed for this session + are computed: the average network capacity use (based on the sending + schedule) and the maximum memory use (based on the number of packets + and number of octets each packet would need to be stored internally + -- note that outgoing sessions would not require any memory use). + These resource use numbers are added to the current resource use + numbers for the given user class; if such addition would take the + resource use outside of the limits for the given user class, the + session is rejected. When resources are reclaimed, corresponding + measures are subtracted from the current use. Network capacity is + reclaimed as soon as the session ends. Memory is reclaimed when the + data is deleted. For unauthenticated sessions, memory consumed by an + OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control + connection that initiated the session is closed (gracefully or + otherwise). For authenticated sessions, the administrator who + configures the service should be able to decide the exact policy, but + useful policy mechanisms that MAY be implemented are the ability to + automatically reclaim memory when the data is retrieved and the + ability to reclaim memory after a certain configurable (based on user + class) period of time passes after the OWAMP-Test session terminates. + 10. IANA Considerations IANA is requested to allocate a well-known TCP port number for OWAMP- Control part of the OWAMP protocol. 11. Internationalization Considerations The protocol does not carry any information in a natural language. 12. Appendix A: Sample Implementation of Exponential Deviate Computation @@ -1684,11 +1769,11 @@ Stanislav Shalunov Benjamin Teitelbaum Anatoly Karp Jeff Boote Matthew J. Zekauskas - Expiration date: November 2004 + Expiration date: January 2005