--- 1/draft-ietf-ippm-owdp-13.txt 2006-02-04 23:46:04.000000000 +0100 +++ 2/draft-ietf-ippm-owdp-14.txt 2006-02-04 23:46:04.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group Stanislav Shalunov Internet Draft Benjamin Teitelbaum Expiration Date: June 2005 Anatoly Karp Jeff W. Boote Matthew J. Zekauskas Internet2 December 2004 A One-way Active Measurement Protocol (OWAMP) - + Status of this Memo By submitting this Internet-Draft, I certify that any applicable 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 RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -47,23 +47,23 @@ well as other unidirectional characteristics, such as one-way loss. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship of Test and Control Protocols . . . . . . 4 1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7 - 3.2. Integrity Zero Padding (IZP) . . . . . . . . . . . . . 10 + 3.2. Integrity Zero Padding (IZP) . . . . . . . . . . . . . 11 3.3. Values of the Accept Field . . . . . . . . . . . . . . 11 - 3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 11 + 3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 12 3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 12 3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 17 3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 18 3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19 3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22 4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 27 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 27 4.1.2. Packet Format and Content . . . . . . . . . . . . 28 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 31 @@ -104,21 +104,21 @@ sources--either directly or through their proximity to Network Time Protocol (NTP) primary (stratum 1) time servers. By standardizing a technique for collecting IPPM one-way active measurements, we hope to create an environment where IPPM metrics may be collected across a far broader mesh of Internet paths than is currently possible. One particularly compelling vision is of widespread deployment of open OWAMP servers that would make measurement of one-way delay as commonplace as measurement of round-trip time using an ICMP-based tool like ping. - Additional design goals of OWAMP include being hard to detect and + Additional design goals of OWAMP include: being hard to detect and manipulate, security, logical separation of control and test functionality, and support for small test packets. (Being hard to detect makes interference with measurements more difficult for intermediaries in the middle of the network.) OWAMP test traffic is hard to detect because it is simply a stream of UDP packets from and to negotiated port numbers, with potentially nothing static in the packets (size is negotiated, as well). OWAMP also supports an encrypted mode that further obscures the traffic, at the same time making it impossible to alter timestamps undetectably. @@ -266,22 +266,26 @@ All multi-octet quantities defined in this document are represented as unsigned integers in network byte order unless specified otherwise. 3. OWAMP-Control Each type of OWAMP-Control message has a fixed length. The recipient will know the full length of a message after examining the first 16 octets of it. No message is shorter than 16 octets. - If the full message is not received within 30 minutes after it is - expected, connection SHOULD be dropped. + An implementation SHOULD expunge unused state to prevent denial-of- + service attacks, or unbounded memory usage, on the server. For + example, if the full control message is not received within some + number of minutes after it is expected, the TCP connection associated + with the OWAMP-Control session SHOULD be dropped. In absence of + other considerations, 30 minutes seems like a reasonable upper bound. 3.1. Connection Setup Before either a Control-Client or a Fetch-Client can issue commands of a Server, it has to 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: 0 1 2 3 @@ -342,53 +346,65 @@ . Client-IV (16 octets) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here Mode is the mode that the client chooses to use during this OWAMP-Control session. It will also be used for all OWAMP-Test sessions started under control of this OWAMP-Control session. In Mode, one or zero bits MUST be set within last three bits. The first 29 bits of Mode MUST be zero. A server MUST ignore the values of the - first 29 bits. + first 29 bits. If zero Mode bits are set by the client, the client + indicates that it will not continue with the session; in this case, + the client and the server SHOULD close the TCP connection associated + with the OWAMP-Control session. In unauthenticated mode, Username, Token, and Client-IV are unused. Otherwise, Username is a 16-octet indicator that tells the server which shared secret the client wishes to use to authenticate or encrypt, while 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. (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) MUST be used as a key for encryption by - the client and decryption by the server (the passphrase also MUST NOT - contain newlines in the middle). + that secret keys, rather than having the low entropy typical of + passwords, are suitable for use as AES keys.) + + The shared secret MUST be generated with sufficient entropy not to + reduce the security of the underlying cipher. Typical methods of its + generation might be from a random number generator [RFC1750] or from + the hash of a passphrase. If the shared secret is provided as a + passphrase (typical for the case of interactive tools) then the MD5 + sum [RFC1321] of the passphrase (without possible newline + character(s) at the end of the passphrase) MUST be used as the key + for encryption by the client and decryption by the server (the + passphrase also MUST NOT contain newlines in the middle). This + ensures that a passphrase used to generate a secret in one + implementation will generate the same secret in another + implementation and the implementations will, therefore, be + interoperable. 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 security of the underlying cipher [RFC1750]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MBZ (15 octets) | | | | +-+-+-+-+-+-+-+-+ @@ -415,38 +431,38 @@ Server-IV is generated randomly by the server. In unauthenticated mode, Server-IV is unused. The Accept field indicates the server's willingness to continue communication. A zero value in the Accept field means that the server accepts the authentication and is willing to conduct further transactions. Non-zero values indicate that the server does not accept the authentication or, for some other reason, is not willing to conduct further transactions in this OWAMP-Control session. The - full list of available Accept values is described in the ``Values of - the Accept Field'' section. + full list of available Accept values is described in Section 3.3, + ``Values of the Accept Field''. If a negative (non-zero) response is sent, the server MAY and the client SHOULD close the connection after this message. Uptime is a timestamp representing the time when the current instantiation of the server started operating. (For example, in a multi-user general purpose operating system (OS), it could be the time when the server process was started.) If Accept is non-zero, Uptime SHOULD be set to a string of zeros. In authenticated and encrypted modes, Uptime is encrypted as described in the next section, unless Accept is non-zero. (Authenticated and encrypted mode cannot be entered unless the control connection can be initialized.) - Timestamp format is described in ``Sender Behavior'' section below. - The same instantiation of the server SHOULD report the same exact - Uptime value to each client in each session. + Timestamp format is described in Section 4.1.2. The same + instantiation of the server SHOULD report the same exact Uptime value + to each client in each session. Integrity Zero Padding (IZP) is treated the same way as IZP in the next section and beyond. The previous transactions constitute connection setup. 3.2. Integrity Zero Padding (IZP) IZP MUST be all zeros in all messages that use IZP. The recipient of a message where IZP is not zero MUST reject the message, as it is an @@ -615,22 +631,22 @@ SHOULD be disregarded by the server. At least one of Conf-Sender and Conf-Receiver MUST be 1. (Both can be set, in which case the server is being asked to perform a session between two hosts it can configure.) Number of Schedule Slots, as mentioned before, specifies the number of slot records that go between the two blocks of IZP. It is used by the sender to determine when to send test packets (see next section). Number of Packets is the number of active measurement packets to be - sent during this OWAMP-Test session (note that both server and client - can abort the session early). + sent during this OWAMP-Test session (note that either the server or + the client can abort the session early). If Conf-Sender is not set, Sender Port is the UDP port from which OWAMP-Test packets will be sent. If Conf-Receiver is not set, Receiver Port is the UDP port OWAMP-Test to which packets are requested to be sent. The Sender Address and Receiver Address fields contain, respectively, the sender and receiver addresses of the end points of the Internet path over which an OWAMP test session is requested. @@ -689,21 +705,21 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IZP (12 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this message, zero in the Accept field means that the server is willing to conduct the session. A non-zero value indicates rejection of the request. The full list of available Accept values is - described in the ``Values of the Accept Field'' section. + described in Section 3.3, ``Values of the Accept Field''. If the server rejects a Request-Session message, it SHOULD not close the TCP connection. The client MAY close it if it receives negative response to the Request-Session message. The meaning of Port in the response depends on the values of Conf-Sender and Conf-Receiver in the query that solicited the response. If both were set, the Port field is unused. If only Conf-Sender was set, Port is the port from which to expect OWAMP-Test packets. If only Conf-Receiver was set, Port is the port to which @@ -812,22 +828,22 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IZP (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If Accept is non-zero, the Start-Sessions request was rejected; zero means that the command was accepted. The full list of available - Accept values is described in the ``Values of the Accept Field'' - section. The server MAY, and the client SHOULD, close the connection + Accept values is described in Section 3.3, ``Values of the Accept + Field''. The server MAY, and the client SHOULD, close the connection in the case of a rejection. The server SHOULD start all OWAMP-Test streams immediately after it sends the response or immediately after their specified start times, whichever is later. If the client represents a Sender, the client SHOULD start its OWAMP-Test streams immediately after it sees the Start-Ack response from the Server (if the Start-Sessions command was accepted) or immediately after their specified start times, whichever is later. See more on OWAMP-Test sender behavior in a separate section below. @@ -897,22 +913,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All these records comprise one logical message: the Stop-Sessions command. Above, the first octet (3) indicates that this is the Stop-Sessions command. Non-zero Accept values indicate a failure of some sort. Zero values indicate normal (but possibly premature) completion. The full list - of available Accept values is described in the ``Values of the Accept - Field'' section. + of available Accept values is described in Section 3.3, ``Values of + the Accept Field''. If Accept had a non-zero value (from either party), results of all OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be considered invalid, even if a Fetch-Session with SID from this session works for a different OWAMP-Control session. If Accept was not transmitted at all (for whatever reason, including the TCP connection used for OWAMP-Control breaking), the results of all OWAMP-Test sessions spawned by this OWAMP-control session MAY be considered invalid. @@ -1041,21 +1057,21 @@ | | | IZP (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Again, non-zero in the Accept field means a rejection of command. The server MUST specify zero for all remaining fields if Accept is 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 - is described in the ``Values of the Accept Field'' section. + is described in Section 3.3, ``Values of the Accept Field''. Finished is non-zero if the OWAMP-Test session has terminated. Next Seqno indicates the next sequence number that would have been sent from this send session. For completed sessions, this will equal 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 @@ -1460,23 +1476,23 @@ almost verbatim quotation from [KNUTH], p.133. Algorithm S: Given a real positive number 'mu', produce an exponential random variate with mean 'mu'. First, the constants Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 are computed in advance. The exact values which MUST be used by all - implementations are given in the reference code (see Appendix A). - This is necessary to insure that exactly the same pseudo-random - sequences are produced by all implementations. + implementations are given in the next section. This is necessary to + insure that exactly the same pseudo-random sequences are produced by + all implementations. S1. [Get U and shift.] Generate a 32-bit uniform random binary fraction U = (.b0 b1 b2 ... b31) [note the binary point] Locate the first zero bit b_j, and shift off the leading (j+1) bits, setting U <- (.b_{j+1} ... b31) Note: In the rare case that the zero has not been found, it is prescribed that the algorithm return (mu*32*ln2). @@ -1502,21 +1518,21 @@ u_int64_t u; u |--> (double)u / (2**32) The algorithm produces a sequence of such u_int64_t integers that, for any given value of SID, is guaranteed to be the same on any implementation. We specify that the u_int64_t representations of the first 11 values - of the Q array in the high-level algorithm be as follows: + of the Q array in the high-level algorithm MUST be as follows: #1 0xB17217F8, #2 0xEEF193F7, #3 0xFD271862, #4 0xFF9D6DD0, #5 0xFFF4CFD0, #6 0xFFFEE819, #7 0xFFFFE7FF, #8 0xFFFFFE2B, #9 0xFFFFFFE0, @@ -1574,24 +1590,24 @@ U4. [Do output] Output the i_th quartet of octets from s starting from high-order octets, converted to native byte order and represented as OWPNum64 value (as in 3.b). U5. [Loop] Go to step U2. 6. Security Considerations 6.1. Introduction - The goal of authenticated mode to let one passphrase-protect service - provided by a particular OWAMP-Control server. One can imagine a - variety of circumstances where this could be useful. Authenticated - mode is designed to prohibit theft of service. + The goal of authenticated mode to let one passphrase-protect the + service provided by a particular OWAMP-Control server. One can + imagine a variety of circumstances where this could be useful. + Authenticated mode is designed to prohibit theft of service. An additional design objective of the authenticated mode was to make it impossible for an attacker who cannot read traffic between OWAMP- Test sender and receiver to tamper with test results in a fashion that affects the measurements, but not other traffic. 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 they should be. This is especially true if one of client and server does not coincide with either sender or receiver. @@ -1661,23 +1677,23 @@ 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. 6.6. Use of Cryptographic Primitives in OWAMP At an early stage in designing the protocol, we considered using - Transport Layer Security (TLS) and IPsec as cryptographic security - mechanisms for OWAMP. The disadvantages of those are as follows (not - an exhaustive list): + Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401] + as cryptographic security mechanisms for OWAMP. The disadvantages of + those are as follows (not an exhaustive list): Regarding TLS: + While TLS could be used to secure TCP-based OWAMP-Control, but difficult to use to secure UDP-based OWAMP-Test: OWAMP-Test packets, if lost, are not resent, so packets have to be (optionally) encrypted and authenticated while retaining individual usability. Stream-based TLS is not conducive of this. + Dealing with streams, does not authenticate individual messages @@ -1714,25 +1730,25 @@ IPsec (for comparison purposes with encryption above layer 4, SSH use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to be able to deploy OWAMP on as large of a number of different platforms as possible. + The deployment problems of a protocol dependent on IPsec would be especially acute in the case of lightweight embedded devices. Ethernet switches, DSL ``modems,'' and other such devices mostly do not support IPsec. - + The API for manipulation IPsec from an application is currently + + The API for manipulating IPsec from an application is currently poorly understood. Writing a program that needs to encrypt some packets, authenticate some packets, and leave some open -- for the same destination -- would become more of an exercise in IPsec - rather than IP measurement. + rather than in IP measurement. For the enumerated reasons, we decided to use a simple cryptographic protocol (based on a block cipher in CBC mode) that is different from TLS and IPsec. 6.7. Required Properties of MD5 The protocol makes use of the MD5 hash function to convert a user-supplied passphrase into a key that will be used to encrypt a short piece of random data (the session key). @@ -1840,22 +1856,22 @@ IANA is requested to allocate a well-known TCP port number for the OWAMP-Control part of the OWAMP protocol. 8. Internationalization Considerations The protocol does not carry any information in a natural language. 9. Appendix A: Sample C Code for Exponential Deviates The values in array Q[] are the exact values that MUST be used by all - implementations. The rest of this appendix only serves for - illustrative purposes. + implementations (see sections 5.1 and 5.2). This appendix only + serves for illustrative purposes. /* ** Example usage: generate a stream of exponential (mean 1) ** random quantities (ignoring error checking during initialization). ** If a variate with some mean mu other than 1 is desired, the output ** of this algorithm can be multiplied by mu according to the rules ** of arithmetic we described. ** Assume that a 16-octet 'seed' has been initialized ** (as the shared secret in OWAMP, for example) @@ -2171,29 +2187,40 @@ [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An Infrastructure for Network Performance Measurements', Proceedings of INET'99, June 1999. http://www.isoc.org/inet99/proceedings/4h/4h_2.htm [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, Implementation and Analysis', RFC 1305, March 1992. + [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, `Randomness + Recommendations for Security', December 1994. + + [RFC2246] T. Dierks, C. Allen, `The TLS Protocol Version 1.0', + January 1999. + + [RFC2401] S. Kent, R. Atkinson, `Security Architecture for the + Internet Protocol', November 1998. + + [RFC3546] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. + Wright, `Transport Layer Security (TLS) Extensions', June 2003. + 13. Authors' Addresses Stanislav Shalunov Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104 Email: shalunov@internet2.edu SIP: shalunov@internet2.edu - Benjamin Teitelbaum Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104 Email: ben@internet2.edu SIP: ben@internet2.edu Anatoly Karp 4710 Regent St, Apt 81B Madison, WI 53705