Network Working Group A. McGregor Internet Draft M. Luckie Expiration Date: May 2004 Waikato University November 2003 IP Measurement Protocol (IPMP) 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 defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The practice and need for active measurement of networks is well established. Current tools are not well suited to this task, primarily 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. It is designed to allow routers to participate in measurements by inserting 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 November 2003 Table of Contents 1. Introduction ............................................... 3 2. Terminology and Definitions ................................ 4 3. Packet Formats ............................................. 4 3.1 IPMP Echo Request and Echo Reply .......................... 4 3.2 Path Record Format ........................................ 5 3.3 IPMP Information Request and Information Reply ............ 7 3.4 Real-time Reference Point Format ........................... 9 3.5 IP Protocol Header Values ................................. 10 4. Processing of IPMP packets ................................. 10 4.1 Measurement host processing ............................... 10 4.2 Echoing system processing ................................. 11 4.3 Forwarding System Processing .............................. 12 4.4 Path Record Insertion ..................................... 12 4.5 Denial of service attacks ................................. 13 5. Discussion ................................................. 13 5.1 Checksums ................................................. 13 5.2 Real-time Timestamps ...................................... 13 5.3 Inferred Real Time ........................................ 14 5.4 Minimum Implementations ................................... 14 5.4.1 Echoing System .......................................... 14 5.4.2 Forwarding System ....................................... 15 6. Security Considerations .................................... 15 7. Acknowledgements ........................................... 15 8. References ................................................. 15 8.1 Normative References ...................................... 15 8.2 Informative References .................................... 16 9. Authors' Address ........................................... 16 10. Full Copyright Statement .................................. 17 McGregor [Page 2] INTERNET-DRAFT IP Measurement Protocol November 2003 1. Introduction The practice and need for active measurement of networks is well established. Current tools are not well suited to this task, primarily because the protocols which they employ have not been designed for measurement of the modern Internet. For example, the Internet Control Message Protocol (ICMP) is widely used for measurements (in part because there is not a better alternative) despite its well known limitations for this task. These limitations include it being treated differently from other IP protocols at routers and hosts because it is difficult to efficiently generate appropriate response packets. In addition, ICMP has been implicated in denial of service attacks press reports, and because of the number of sites generating monitoring traffic. As a consequence, some Internet Service Providers (ISPs) disable ICMP even though this potentially causes poor performance and does not comply with [RFC 1009]. Current packet probing techniques are not suited to measuring packet delay at the router level, for several reasons. Routers often make bad measurement targets because they are optimised for the relatively simple task of forwarding packets. Because they are an opportunity for denial of service attacks, routers may process tasks that are resource intensive 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 delays occur in the network difficult. IPMP addresses all of these issues by providing a measurement protocol that is tightly constrained [RFC 1925], efficient, and easy to implement. The protocol has been designed so measurement packets can be processed with approximately the same level of computation as needed for IP packet forwarding. The protocol operates as an echo protocol allowing packet loss, one-way path length, round-trip time, and one-way delay measurements to be taken. The protocol also allows a measurement host to identify individual router units from the interface IP addresses it collects in the echo exchange by exchanging information packets after the measurement has completed. McGregor [Page 3] INTERNET-DRAFT IP Measurement Protocol November 2003 Packets are generated by a measurement host and returned by an echoing router or host. An echoing router or host is known as an echoing system in this memo. The translation of router timestamps to real-time timestamps is supported through a separate information request and reply exchange between the measurement system and systems that insert timestamps into the echo request or reply. 2. Terminology and Definitions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described [RFC 2119] and indicate requirement levels for compliant IPMP implementations. 3. Packet Formats 3.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Faux Source Port | Faux Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Faux IP Proto | IPMP Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Pointer | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Path Record(s) | : ..... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version = 0 Faux IP Proto, Faux Source Port, Faux Destination Port The Faux IP Proto mimics the IP header's protocol field. The Faux Source and Destination Port fields mimic the TCP or UDP source and destination port fields (as appropriate). These fields allow an IPMP echo packet to be queued or filtered based on a quintuple of values when combined with the IP source and destination addresses. Intermediate routers schedule this packet if they implement a packet scheduling discipline that is not first-in first-out (FIFO). When the echo packet is received at a target, the Faux Source and Destination Ports MUST be swapped to reflect the way that ports are conceptually swapped in a UDP or TCP header at a target. McGregor [Page 4] INTERNET-DRAFT IP Measurement Protocol November 2003 IPMP Options 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Res |S|I|R| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E = echo packet I = information packet (see Section 3.3) R = request packet = 1 / response packet = 0 S = singleton packet, used for one-way probes, not echoed Identifier, Sequence Number The echo request packet should contain enough information to match an echo response packet. The identifier SHOULD be set to the lower 16 bits of the process identifier responsible for sending the packet, and the sequence number SHOULD increment for each echo request packet sent to a unique IP address with a particular identifier value. Firewalls that keep state SHOULD use the Identifier field - combined with the source and destination IP addresses and IP protocol number (not Faux IP Proto) - to hash a packet in order to decide which echo packets to allow past. Path Pointer The position of the next available path record location, in bytes from the beginning of the IPMP header, if there is space. If an intermediary inserts a path record, it MUST increment the path pointer by the size of the path record inserted. 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 and ending with the end of the IPMP packet. For computing the checksum, the checksum is set to zero. Path Records The measurement host MAY pre-allocate space for path records to be inserted. The start and end offsets of the space are given by the IPMP path pointer and IP length fields respectively. The pre-allocated space MUST be initialised to zero. McGregor [Page 5] INTERNET-DRAFT IP Measurement Protocol November 2003 3.2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP version 4 (IPv4) Address of Receiving Interface | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | Reserved | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP version 6 (IPv6) Address of Receiving Interface | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HLIM | Reserved | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 / IPv6 Address of Receiving Interface 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. TTL / HLIM A host or router MAY include the value of the Time to Live (TTL) or Hop Limit (HLIM) field in the packet's IP header after it has been decremented as part of the forwarding process. This allows an end-host to identify gaps in the network where a path record was not inserted. If this field is not inserted by a host or router that does insert a path record it MUST be left at zero. Timestamp A host or router MAY include the time at which the interface completed receiving the packet. If the timestamp is not set in the path record, the default value is zero. The timestamp is allocated 48 bits, although the host or router can use any number of bits. The timestamp, if included, SHOULD represent the time that the last bit of the packet was received. McGregor [Page 6] INTERNET-DRAFT IP Measurement Protocol November 2003 3.3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Faux Source Port | Faux Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Faux Proto | IPMP Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : (optional) Reported Time Of Interest : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Faux Source Port | Faux Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Faux Proto | IPMP Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Performance Data Pointer | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address Identifying Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPMP Processing Overhead | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Real-Time Reference Points | : ..... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Performance Data | : ..... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McGregor [Page 7] INTERNET-DRAFT IP Measurement Protocol May 2003 Version, IPMP Options, Checksum, Faux Source Port, Faux Destination Port, Faux P-Type, Identifier, Sequence Number See Section 3.1 Performance Data Pointer The position, of the performance data field, in bytes from the beginning of the IPMP packet, if it exists. If there is no performance data field, the default is 0. IP Address Identifying Router In order for a measurement host to identify individual routers on a network, a router must reply to information requests sent to any of its interfaces using a consistent address in this field. The field may contain any address unique to the router. 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. The echo system may use the values supplied in Faux IP Proto, Faux Source Port, and Faux Destination Port if it implements a queueing discipline that is not FIFO. If the overhead is unknown, then the value recorded is MAX_TIME, i.e., 0xffffffff. Reported Time of Interest A measurement system MAY request that the end system constrain the real-time reference points to cover a particular timestamp that it received. In this case, the timestamping system SHOULD return a real-time reference point for just this timestamp or a pair of reference points, one before and one after, the timestamp. In other cases the timestamping system MAY return an arbitrary number of reference points bounded by the size of the packet it can send. Real-time Reference Points A real-time reference point (see Section 3.4) 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 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. McGregor [Page 8] INTERNET-DRAFT IP Measurement Protocol May 2003 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 formatted as a VarBindList from the SNMPv2-PDU defined in [RFC 3416]. In this context, ObjectSyntax is the only valid choice within VarBind. For example: IPMP-PERFORMANCE-DATA DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, FROM SNMPv2-SMI; max-bindings INTEGER ::= 2147483647 -- IPMP simplified list element IPMPVarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } -- variable-binding list VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF IPMPVarBind END McGregor [Page 9] INTERNET-DRAFT IP Measurement Protocol May 2003 3.4 Real-time Reference Point 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reported Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reported Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Real-time Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Estimated Error | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reported Timestamp A 48-bit timestamp that the host or router used in a path record. Real-time Timestamp A Network Time Protocol (NTP) formatted timestamp representing the real time. Estimated Error An NTP formatted timestamp estimating the error bounds of the real-time timestamp. 3.5 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 10] INTERNET-DRAFT IP Measurement Protocol May 2003 4. Processing of IPMP packets 4.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 the presence of errors, if they occur. 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. When an IPMP echo reply arrives, the checksum is recomputed and checked with the checksum present in the IPMP header. 4.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 Faux Source and Destination ports; 3. setting the reply bit in the IPMP Options field and incrementally updating the checksum; 4. optionally inserting a path record as described in Section 4.4; and 5. scheduling the packet for forwarding, taking into account the queue type field, if appropriate. The echoing system does not: o validate the value of the IPMP checksum present in the header against the contents of the packet; o recalculate the IPMP checksum from scratch before transmitting the packet; o decrement or otherwise alter the IP header's TTL or recalculate the IP header's checksum; or McGregor [Page 11] INTERNET-DRAFT IP Measurement Protocol May 2003 o process fragments or IP options. Processing IPMP Information Request packets requires more resources than an Echo Request. Direct measurements are not made from the Information Request packets. Consequently, an implementer may choose to processes Information Request packets off the interface card and/or at low priority. 4.3 Forwarding System Processing A forwarding router does not need to be IPMP aware. In the simplest case, an IPMP packet is forwarded like any other IP packet. If the forwarding system schedules packets based on the value of any combination of the IP protocol field and the TCP or UDP source and destination ports, then the forwarding system MUST use the Faux fields in the IPMP header for this purpose instead of the IP, TCP or UDP fields. Note that the Faux Source and Destination port numbers are in the same position in an IPMP packet as they are in a TCP or UDP packet, but the Faux IP proto is not. A forwarding router MAY include a path record as described in the following section. 4.4 Path Record Insertion Inclusion of path records is optional. A path record MAY be inserted by forwarding systems on the forward and reverse paths, by the measurement host, and by the echoing system. A forwarding system SHOULD NOT insert a path record if it cannot modify the packet in the same processing stream that any other packet would take. This is to avoid the measurement path being significantly different than that taken by a regular packet, and to reduce opportunities for denial of service attacks (see Section 4.5). A system that can insert a path record MUST check for sufficient space in the echo packet based on the size of the path record inserted. An IPv4 path record requires 12 bytes, while the IPv6 path record requires 24 bytes. A system which inserts a path record MUST increase the Path Pointer as appropriate, and MUST also incrementally update the IPMP Checksum field as described in [RFC 1624]. The length of the packet is not changed. McGregor [Page 12] INTERNET-DRAFT IP Measurement Protocol May 2003 A system that adds a path record MAY include a timestamp in the path record. If it does not include a timestamp, the timestamp field in the path record is left unaltered, i.e., remains zero. 4.5 Denial of service attacks Because IPMP echo request packets are processed with approximately 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 can be used on a router or host. Because Information Request packets are not used to make measurements, an implementer 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. 5. Discussion 5.1 Checksums The IPMP checksum is calculated by the measurement host when it creates the echo request packet. It is incrementally updated by forwarding systems that insert a path record. The checksum is not checked by a forwarding system or an echoing system. Errors that occur between the measurement host and the echoing system on the forward and reverse paths are detected when the echo reply is received at the measurement host. 5.2 Real-time Timestamps 32 bit real-time timestamp fields are coded following the conventions described in [RFC 1305]. Summarising from [RFC 1305]: 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 1 January 1900 00:00. The integer part is in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the nonsignificant low order can be set to 0. McGregor [Page 13] INTERNET-DRAFT IP Measurement Protocol May 2003 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. 5.3 Inferred Real Time The real time of a timestamp in a path record can 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 drift of the clock is assumed to be linear. 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 timestamp in the path record structure may be of any format, as discussed in Section 3.2; potentially, the timestamp can wrap over the course of a series of measurements. It is the responsibility of the measurement host to send information requests to the timestamping systems sufficiently frequently to avoid information loss. The correct frequency can be estimated from an information reply. 5.4 Minimum Implementations 5.4.1 Echoing System The simplest echoing system implementation returns the IPMP echo request without a path record. As described in Section 4.2, this only requires that the IP source and destination addresses be exchanged, the R bit in the IPMP options field to be set, 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 process IPMP Information Requests. McGregor [Page 14] INTERNET-DRAFT IP Measurement Protocol May 2003 Systems which provide even the minimum level of implementation will allow a number of measurements to be made that are not currently possible, specifically if they are routers that currently process ICMP at a low priority to avoid DOS attacks. 5.4.2 Forwarding System Forwarding systems do not need to be IPMP aware. 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 4.4. In this case the forwarding system does not need to process IPMP Information Request packets. 6. Security Considerations An IPMP echo exchange reveals the path that may be taken between two hosts. Some ISPs may feel that their security is weakened if attackers know of an address in the core of their network, and may choose to enable path record insertion for selected IP addresses. IPMP can be abused for denial of service attacks disguised as legitimate measurement activity, although we feel that the potential impact of IPMP denial of service attacks has been minimised. 7. Acknowledgements The comments of Randy Presuhn are appreciated. Maureen C. Curran provides editorial assistance on these drafts. 8. References 8.1 Normative References [RFC 1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and analysis", RFC 1305, March 1992. [RFC 1624] Rijsinghani, A., editor. "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994. [RFC 2030] Mills, D. "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. McGregor [Page 15] INTERNET-DRAFT IP Measurement Protocol May 2003 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC 3416] Presuhn, R., editor. "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMPv2)", RFC 3416, STD 62, December 2002. 8.2 Informative References [RFC 1009] Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC 1009, USC/Information Sciences Institute, June 1987. [RFC 1925] Callon, R., editor. "The Twelve Networking Truths", RFC 1925, April 1996. 9. Authors' Addresses Anthony J. (Tony) McGregor Department of Computer Science Waikato University Private Bag 3105 Hamilton New Zealand Phone: +64 7 838 4651 EMail: tonym@cs.waikato.ac.nz Matthew J. Luckie Department of Computer Science Waikato University Private Bag 3105 Hamilton New Zealand EMail: mjl@luckie.org.nz Expiration Date: May 2004 McGregor [Page 16] INTERNET-DRAFT IP Measurement Protocol May 2003 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGregor [Page 17]