Network Working Group A.J. McGregor Internet Draft Waikato University Expiration Date: August 2002 February 2002 IP Measurement Protocol (IPMP) 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. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft shadow directories can be accessed at http://www.ietf.org/shadow.html This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 2. Abstract The practice and need for active network measurement is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. The IP Measurement Protocol (IPMP) is based on packet-probes, and is designed to allow routers to participate in measurements by the insertion of path information as the probe passes between a pair of hosts. IPMP is tightly constrained and easy to implement. McGregor [Page 1] INTERNET-DRAFT IP Measurement Protocol February 2002 2. Introduction The practice and need for active network measurement is well established, however current tools are not well suited to this task, mostly because the protocols which they employ have not been designed for measurement of the modern Internet. ICMP, for example, is widely used for measurement despite its well known limitations for this task. These limitations include it being treated different to other IP protocols at routers and hosts. ICMP has also received bad press from denial of service attacks and because of the number of sites generating monitoring traffic. As a consequence some ISPs disable ICMP even though this potentially causes poor performance and does not comply with RFC1009 [1]. Current packet probing techniques are not suited to measuring packet delay at the router level. Routers often make bad measurement targets because they are optimised for the relatively simple task of forwarding packets. Routers may process tasks that are resource intensive and therefore an opportunity for a denial of service attack at low priority or not at all. Some measurement techniques construct measurement traffic that can be difficult to efficiently detect and respond to amongst other network traffic. This type of measurement traffic precludes measuring to a router and makes the task of identifying where delay occurs in the network difficult. IPMP addresses these issues by providing a measurement protocol that is tightly constrained, efficient and easy to implement. The protocol has been designed so measurement packets can be processed with about the same level of computation as IP packet forwarding. The protocol operates as an echo protocol allowing packet loss, path length, RTT and in some cases, one-way delay measurements to be taken. Packets are generated by a measurement host and returned by an echoing router or host, known as an echoing system in this memo. The translation of router time stamps to real time time stamps is supported through a separate information request and reply exchange between the measurement system and systems that insert time stamps into the echo request or reply. McGregor [Page 2] INTERNET-DRAFT IP Measurement Protocol February 2002 2.1 Packet formats 2.1.1 IPMP Echo Request and Echo Reply 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Protocol Queue| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000000 | Type | Returned TTL | Return Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Path Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Queue | Destination Port Queue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Data | : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Path Record(s) | : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (if required) | : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Path Record format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McGregor [Page 3] INTERNET-DRAFT IP Measurement Protocol February 2002 Version = 0. Type = 1, echo request 0, echo reply Return type = 0 echo request any value in the echo reply Checksum The checksum is the 16-bit one's complement of the one's complement sum of the IPMP message starting with the version number. For computing the checksum, the checksum and returned checksum fields are zero. Length The total length, in bytes, of the IPMP packet. The length should not normally exceed 556 bytes. That is the data field plus the space allocated for path records should not exceed 544 bytes. Longer packets risk being discarded if they need to be forwarded over a path with an MTU less that 576. Within these limits a maximum of 45 path records may be included in the packet, allowing 4 bytes for a unique identifier in the data field. Protocol Queue, Source Port Queue, Destination Port Queue The IPMP protocol queue value, the IPMP source port queue value, and the IPMP destination port queue value allow an IPMP measurement to be queued or filtered based on a five-tuple of values when combined with the IP source and destination addresses. The intermediate routers schedule this packet if they implement a packet scheduling discipline that is not FIFO. Returned TTL Zero in the echo request. The value of the IP header TTL field when the packet was received by the echoing system in the echo reply. McGregor [Page 4] INTERNET-DRAFT IP Measurement Protocol February 2002 Path Pointer The position, in bytes from the beginning of the IPMP packet, of the next available path record location. If there are no path pointer fields available this field is set to length. Data The data field is set by the measurement host. The echo reply contains an identical data field to the echo request. The content of the data field must allow the echo reply to be matched with the echo request when it arrives at the measurement host. Forwarding IP Address The address of interface at which the packet was received by the system that inserted the Path Record into the Echo Request or Echo Reply packet. Timestamp The time at which the interface received the packet recorded as an RFC1305 NTP format [2] timestamp. The relationship between this timestamp and real time, if there is one, must be derived using information from an IPMP Information Reply (see section 4.3). If the timestamp is not included its value is 0. If a timestamp is included by a system the system must be able to processes IPMP Information Request Packets at the address included in the Path Record. 2.1.2 IPMP Information Request and Information Reply Information Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | 00000000 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000000 | Type | 00000000 | 00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McGregor [Page 5] INTERNET-DRAFT IP Measurement Protocol February 2002 Information Reply 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | 00000000 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000000 | Type | 00000000 | Precision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Performance Data Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accuracy | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPMP Processing Overhead | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Real Time Reference Points | | | | | | | : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Performance Data | : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Real Time Reference Point 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Real Time | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reported Time | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McGregor [Page 6] INTERNET-DRAFT IP Measurement Protocol February 2002 Version = 0. Type = 32, Information Request 33, Information Reply Checksum The checksum is the 16-bit one's complement of the one's complement sum of the IPMP message starting with the version number. For computing the checksum, the checksum and returned checksum fields are zero. Precision The number of bits in the fractional part of timestamps that are valid. Length The total length, in bytes, of the IPMP packet. The length should not normally exceed 556 bytes. That is the Real Time Reference Points and Performance Data fields should not exceed 524 bytes. Longer packets risk being discarded if they need to be forwarded of a path with a MTU less that 576. If no performance data is included 32 Real Time Reference Points may be included in the packet. Performance Data Pointer The position, in bytes from the beginning of the IPMP packet, of the performance data field if it exists. If there is no performance data this field is 0. Forwarding IP Address The address of the interface to which the Information Request was sent. McGregor [Page 7] INTERNET-DRAFT IP Measurement Protocol February 2002 Accuracy The maximum difference between actual real time and and the inferred real time (see section 4.3.2) of any timestamp generated by this interface. If there is no relationship between real time and the timestamps recorded by the interface or the extent of the difference from real time is unknown accuracy is set to 0. IPMP Processing Overhead The maximum difference between the time taken to process and forward an IPMP packet and the time taken to forward an IP packet with the same characteristics. If the overhead is unknown this is reported as MAX_TIME, i.e. all bits to 1. Real Time Reference Point A real time reference point gives the relationship between real time and the timestamp that would have been placed in a Path Record by the interface at that time. If there is no relationship between real time and timestamps no reference points are included in the Information Reply. If any reference points are included there must be at least two. Within the bounds of the overall size of the packet any number of reference points may be included. Performance Data The Performance Data field allows arbitrary information from the MIB of the system or the interface to optionally be included in the Information Reply. It is formated as a VarBindList from the SNMPv2-PDU defined in [4]. In this context ObjectSyntax is the only valid choice within VarBind. I.E. IPMP-PERFORMANCE-DATA DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, FROM SNMPv2-SMI; McGregor [Page 8] INTERNET-DRAFT IP Measurement Protocol February 2002 -- IPMP simplified list element IPMPVarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } -- variable-binding list VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF IPMPVarBind END 2.2 IP Protocol Header Values Version = 4 IHL = 5 Identification = 0 Flags = DF Fragment offset = 0 IP Protocol type = TO BE ASSIGNED. IP options are forbidden. McGregor [Page 9] INTERNET-DRAFT IP Measurement Protocol February 2002 3. Processing of IPMP packets 3.1 Measurement host processing A measurement host constructs an IPMP request, encapsulates it in an IP datagram and the appropriate link layer protocol and sends it into the network. Performance information is gleaned from the presence or absence of a reply, the delay between the request and the reply the value of TTL and the path record(s) if present and possibly the presence of errors. The measurement host, when constructing the echo request, sets all words from the end of the data field to the end of the echo request (the space allocated for path records) to zero. The data field must contain information that allows the measurement host to match echo replies to echo requests. The data field might also contain checking information for part or all of the data and/or control fields of the IPMP packet. This checking information may allow matching of echo requests and replies where there are errors in other parts of the IPMP packet and the determination of the BER of the path. When an IPMP echo reply arrives the checksum is recomputed. Unless further protection is provided in the data field an IPMP echo reply with an incorrect checksum should be discarded because of the risk of data corruption causing incorrect matching with the echo request. 3.2 Echoing system processing The IPMP Echo Request and Echo Reply packet formats are designed to make processing at the echoing host simple and efficient. On receipt of the IPMP Echo Request the echoing system constructs the echo reply from the echo request by: 1. exchanging the IP source and destination addresses 2. exchanging the third and fourth 16-bit words of the IPMP packet or otherwise setting the type field (see section 4.1) 3. optionally inserting a path record (as described in section 3.3.1). 4. scheduling the packet for forwarding taking account of the queue type field if appropriate. McGregor [Page 10] INTERNET-DRAFT IP Measurement Protocol February 2002 The echoing system does not: o calculate or check the IPMP checksum o decrement or otherwise alter TTL or recalculate the IP checksum o process fragments or IP options Processing IPMP Information Request packets requires more resources than an Echo Request. Direct measurements are not made from Information Request packets. Consequently an implementor may choose to processes Information Request packets off the interface card and/or at low priority. 3.3 Forwarding System Processing A forwarding router does not need to be IPMP aware. In the simplest case IPMP is forwarded like any other IP protocol. If the router forwards schedules packets based (perhaps in part) on the value of the IP protocol field, from the IP header, then the forwarding router must use the queue type field of the IPMP field for scheduling instead of the IP protocol field. A forwarding router may include a path record as described below. 3.3.1 Path Record Inclusion of path records is optional. A path record MAY be inserted by forwarding routers (on the forward or reverse path) and the echoing system. A system which adds a path record must increase the Path Pointer by 12 and must also update the Checksum field. The length of the packet is not changed. Before updating the Path Pointer it must be compared with length to ensure that sufficient space is available for the new path record. A system that adds a path record may include a timestamp in the path record using the timestamp NTP format described in section 4.3. If it does not include a timestamp the timestamp field in the path record is left unaltered. McGregor [Page 11] INTERNET-DRAFT IP Measurement Protocol February 2002 3.4 Denial of service attacks Because IPMP echo request packets are processed with about the same effort as forwarding an IP packet they do not introduce any new denial of service opportunities. IPMP Information Request packets require more processing and may be used as the basis of a denial of service attack in the same way as any information request on a router or host. Because Information Request packets are not used to make measurements an implementor may implement protection against denial of service attacks made with these packets in the same way as other information requests. This might involve processing IPMP Information Requests at a low priority or regulating the maximum flow of packets. 4 Discussion 4.1 Echoing system update of the type field. The echoing system might set the type field in the IPMP field (see step 2 in section 3.2) in any one of a number of ways. An implementor should use the most efficient for the architecture in use. These methods include: o swapping the third and fourth 16-bit words o swapping the sixth and eighth bytes o writing a 0 to the sixth byte and a 1 to the eighth byte o writing a 0 to the third 16-bit word and a 1 to the fourth 16 bit word o writing a 0 to the sixth byte or third 16-bit word 4.2 Checksums The IPMP checksum is calculated by the measurement host when it creates the echo request packet. It is updated (as described in section 4.2.1) by forwarding routers that insert a route record into the IPMP packet. The checksum is not checked by the echoing system. Errors that occur between the measurement host and the echoing system are detected when the echo reply is received at the measurement host (as are errors that occur between the echoing system and the measurement host). McGregor [Page 12] INTERNET-DRAFT IP Measurement Protocol February 2002 The IP header in the encapsulated echo reply packet is identical to the IP header in the encapsulated echo request except that the source and destination IP addresses are revered. Because the IP checksum algorithm does not detect miss-ordered (16-bit) words this means that the checksum in IP header on the echo reply has the same value as the checksum in IP header of the echo request. A similar argument applies to the IPMP checksum, however the echoing system is at liberty to place any value in the return type field. The measurement host must replace this value with 1 before checking the IPMP checksum. The algorithm for checking the integrity of an IPMP echo receive packet is: 1. set the Return Code field to 1 2. recalculate the checksum as described in section 2.1 3. compare the calculated checksum with the received checksum and discard the packet if they are not equal 4.2.1 Checksum update at a forwarding router. A forwarding router that does not include a path record does not check or modify the IPMP checksum. (Normal IP forwarding occurs including decrementing TTL and updating the IP header checksum.) A forwarding router that includes a path pointer must update the IPMP checksum. This may be done in two ways: a) Absolute. Check that the checksum matches for the received packet. If it does not set the checksum in the forwarded packet to 0. If the checksum in the received packet does match add the Route Record to the packet and recalculate the checksum. b) Relative. Form the checksum of the path record (this will be a constant for a particular interface if timestamps are not used) and the previous checksum. Option a) or b) is selected on the basis of efficiency. McGregor [Page 13] INTERNET-DRAFT IP Measurement Protocol February 2002 4.3 Timestamps The timestamp field is coded following the conventions described in RFC1305 NTP [2]. 4.3.1 Timestamp format Summarising from RFC1305: In conformance with standard Internet practice, timestamps are specified as integer or fixed-point quantities, with bits numbered in big-endian fashion from 0 starting at the left, or high-order, position. All quantities are unsigned and may occupy the full field width with an implied 0 preceding bit 0. Timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the non-significant low order can be set to 0. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds Fraction (0-padded) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This format allows convenient multiple-precision arithmetic and conversion to UDP/TIME representation (seconds), but does complicate the conversion to ICMP Timestamp message representation, which is in milliseconds. The most future time that can be represented is 4,294,967 (some time in the year 2036) with a precision of about 200 picoseconds, which should be adequate for even the most demanding measurements. RFC 2030 (SNTP) contains a proposal for extending timestamps beyond the year 2036. McGregor [Page 14] INTERNET-DRAFT IP Measurement Protocol February 2002 4.3.2 Inferred Real Time The real time of the timestamp may be inferred when a system provides an IPMP Information Reply with at least one Real Time Reference Point earlier and one later than the timestamp. For the purpose of this inference the clock drift of the interfaces clock is assumed to be linear and linear interpolation is used between the two nearest Real Time Reference Points where one is greater than and one is less than, the timestamp. The accuracy field of an Information Reply reports the greatest difference between an inferred real time, calculated using linear interpolation, and true real time. 4.4 Minimum Implementations. 4.4.1 Echoing System The simplest echoing system implementation returns the IPMP echo request without a path record. As described in section 3.2 this only requires that the IP source and destination addresses be exchanged, the type field changed and the packet scheduled for forwarding. Because of the format of the IPMP echo request and echo reply packets this can be implemented with a very small number of instructions. A system that does not insert path records does not need to processes IPMP Echo Requests. Systems which just provide this level of implementation allow a number of measurements to be made that are not currently possible, particularly if they are routers that processes ICMP at a low priority to avoid DOS attacks. 4.4.2 Forwarding System Forwarding systems do not need to be IPMP aware (unless they implement protocol based scheduling). A forwarding system that is IPMP aware may include path records with only the Forwarding IP Address set. This requires writing the address to the packet and updating the checksum and Path Pointer in the packet as described in section 3.3.1 and 4.2.1. In this case the forwarding system does not need to process IPMP Information Request packets. McGregor [Page 15] INTERNET-DRAFT IP Measurement Protocol February 2002 5. References [1] Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC 1009, USC/Information Sciences Institute, June 1987. [2] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and analysis", RFC 1305, March 1992. [3] Mills, D. "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [4] Case, J., et al. "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, October 1996. 6. Author's Address Anthony J. McGregor Department of Computer Science Waikato University Private Bag 3105 Hamilton New Zealand Phone: +64 7 838 4651 EMail: tonym@cs.waikato.ac.nz Expiration Date: August 2002 McGregor [Page 15]