IPPM Working Group S. Niccolini Internet-Draft S. Tartarelli Expires: August 15, 2005 NEC February 11, 2005 How to store traceroute measurements and related metrics draft-niccolini-ippm-storetraceroutes-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 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 Internet-Draft will expire on August 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes a standard way to store traceroute measurements and possibly their related metrics. To better address the traceroute measurements storing issue, the authors first of all give a definition of the traceroute tool, describe the tool itself as well as its parameters and the default values on the most common operating systems and the output results that can be stored. Afterwards, the Niccolini & Tartarelli Expires August 15, 2005 [Page 1] Internet-Draft IPPM Way to store traceroutes February 2005 common information model with the base elements of the traceroute measurement storing is defined dividing the information elements in two semantically separated groups (configuration elements and results ones). On the basis of the information model a data model is then proposed in order to actually store the traceroute measurements. Finally the relevant metrics related to traceroute measurements are defined using the metrics already standardized in the IPPM working group, where they are found to be applicables. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of traceroute . . . . . . . . . . . . . . . . . . 5 2.1 Traceroute configuration parameters . . . . . . . . . . . 5 3. Known problems with traceroute . . . . . . . . . . . . . . . 9 4. Reports/results . . . . . . . . . . . . . . . . . . . . . . 10 5. Information model for storing traceroutes measurements . . . 11 5.1 Data types . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Information Elements . . . . . . . . . . . . . . . . . . . 12 5.2.1 Configuration Information Elements . . . . . . . . . . 12 5.2.1.1 traceRouteCtlTestName . . . . . . . . . . . . . . 12 5.2.1.2 traceRouteCtlTargetAddressType . . . . . . . . . . 12 5.2.1.3 traceRouteCtlTargetAddress . . . . . . . . . . . . 12 5.2.1.4 traceRouteCtlByPassRouteTable . . . . . . . . . . 13 5.2.1.5 traceRouteCtlProbeDataSize . . . . . . . . . . . . 13 5.2.1.6 traceRouteCtlTimeOut . . . . . . . . . . . . . . . 13 5.2.1.7 traceRouteCtlProbesPerHop . . . . . . . . . . . . 14 5.2.1.8 traceRouteCtlPort . . . . . . . . . . . . . . . . 14 5.2.1.9 traceRouteCtlMaxTtl . . . . . . . . . . . . . . . 14 5.2.1.10 traceRouteCtlDSField . . . . . . . . . . . . . . 14 5.2.1.11 traceRouteCtlSourceAddressType . . . . . . . . . 15 5.2.1.12 traceRouteCtlSourceAddress . . . . . . . . . . . 15 5.2.1.13 traceRouteCtlIfIndex . . . . . . . . . . . . . . 15 5.2.1.14 traceRouteCtlMiscOptions . . . . . . . . . . . . 15 5.2.1.15 traceRouteCtlMaxFailures . . . . . . . . . . . . 16 5.2.1.16 traceRouteCtlDontFragment . . . . . . . . . . . 16 5.2.1.17 traceRouteCtlInitialTtl . . . . . . . . . . . . 16 5.2.1.18 traceRouteCtlDescr . . . . . . . . . . . . . . . 16 5.2.1.19 traceRouteCtlType . . . . . . . . . . . . . . . 16 5.2.2 Results Information Elements . . . . . . . . . . . . . 17 5.2.2.1 traceRouteResultsStartDateAndTime . . . . . . . . 17 5.2.2.2 traceRouteResultsIpTgtAddrType . . . . . . . . . . 17 5.2.2.3 traceRouteResultsIpTgtAddr . . . . . . . . . . . . 17 5.2.2.4 traceRouteResultsProbeIndex . . . . . . . . . . . 17 Niccolini & Tartarelli Expires August 15, 2005 [Page 2] Internet-Draft IPPM Way to store traceroutes February 2005 5.2.2.5 traceRouteResultsProbeHopIndex . . . . . . . . . . 18 5.2.2.6 traceRouteResultsProbeIndexPerHop . . . . . . . . 18 5.2.2.7 traceRouteResultsProbeHopAddrType . . . . . . . . 18 5.2.2.8 traceRouteResultsProbeHopAddr . . . . . . . . . . 18 5.2.2.9 traceRouteResultsProbeHopASNumber . . . . . . . . 19 5.2.2.10 traceRouteResultsProbeHopGeoLocation . . . . . . 19 5.2.2.11 traceRouteResultsProbeRoundTripTime . . . . . . 19 5.2.2.12 traceRouteResultsProbeResponseStatus . . . . . . 19 5.2.2.13 traceRouteResultsProbeTime . . . . . . . . . . . 19 5.2.2.14 traceRouteResultsEndDateAndTime . . . . . . . . 20 6. Data model for storing traceroutes measurements . . . . . . 21 7. Relevant metrics for traceroute measurements . . . . . . . . 22 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Security considerations . . . . . . . . . . . . . . . . . . 24 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Normative References . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . 28 Niccolini & Tartarelli Expires August 15, 2005 [Page 3] Internet-Draft IPPM Way to store traceroutes February 2005 1. Introduction Traceroutes are being used by lots of measurement efforts, either as an independent measurement or to get path information to support other measurement efforts. That is why there is the need to standardize the way traceroute measurements are stored and the related metrics associated with such measurements. Since traceroute is a tool that has built-in configurable mechanisms like time-outs and can experience problems related to the crossing of firewalls thus experiencing fake losses or incomplete delay information, the standard metrics defined by IPPM working group in matter of delay, connectivity and losses may not be complete enough to define univocally the metrics retrieved by the traceroute tool. In such a context, already standardized metrics have to be closely examined in order to check for their applicability. Moreover there is a need to better define the traceroute tool as well as its parameters and the results it outputs since, to the authors' knowledge, there is so far no standard describing these. These are the motivations that moved the authors to write this draft in the context of the IPPM working group even if other working groups (like DISMAN) have already addressed similar issues related to the definition of the MIB for configuring and retrieving traceroute measurements results. The rest of the draft is organised as follows: Section 2 gives the definition of traceroute used as reference in the rest of the draft as well as the traceroute configurable parameters and their default values for the most common operating systems. Section 3 reports on both known problems of traceroute and existing alternatives. Section 4 describes the results available from the traceroute output screen. Section 5 and Section 6 respectively describe our proposed Information model and Data model for storing traceroute measurments. Section 7 reports on the proposed relevant metrics while Section 8 gives our conclusions. The draft ends with security considerations and open issues in Section 9 and Section 10 respectively. Niccolini & Tartarelli Expires August 15, 2005 [Page 4] Internet-Draft IPPM Way to store traceroutes February 2005 2. Definition of traceroute Traceroute is a network diagnostic tool used to determine the hop by hop path from a source to a destination and the Round Trip Time (RTT) from the source to each hop. Traceroute can therefore be used to discover where and how a host is connected to the Internet and can be usefully employed to troubleshoot network connections. Typically, traceroute attemps to discover the path to a destination by sending UDP probes with specific time-to-live (TTL) values in the IP packet header and trying to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host. More in detail, the host running the traceroute sends the first set of probes with TTL equal to one (some implementations allow setting the initial TTL to a value equal to "n" different from one, so that the first "n-1" hops are skipped and the first hop that will be traced is the "n-th" in the path). Upon receiving a probe, the first hop host decreases the TTL value by one. By observing a TTL value equal to zero, the host rejects the probe and typically returns an ICMP message with a TIME_EXCEEDED value. Traceroute can therefore derive the IP address of the first hop from the header of the ICMP message and evaluate the RTT between the source and the first hop. The next hops are discovered following the same procedure, taking care of increasing at each step the TTL value of the outgoing probes by one. The TTL value is increased until either an ICMP PORT_UNREACHABLE message is received, meaning that the destination has been reached, or the maximum configured number of hops has been hit. Some implementations, use ICMP Echos, instead of UDP datagrams. However, many routers do not return ICMP messages about ICMP messages, i.e. no ICMP TIME_EXCEEDED is returned for an ICMP Echo. Therefore, in this draft we RECOMMEND to base implementations on UDP datagrams. 2.1 Traceroute configuration parameters In order to define an information model for storing traceroutes, we first investigated which configuration parameters are relevant when running traceroute. We considered three major traceroute implementations and compared them based on configurable parameters and default values. The LINUX (SUSE 9.1) and UNIX (multiple platform) implemetations are based on UDP datagrams, while the WINDOWS (XP SP2) one uses ICMP Echos. The following table summarizes such comparison. A N/A in the option column, means that such option is not configurable for the specific implementation. Niccolini & Tartarelli Expires August 15, 2005 [Page 5] Internet-Draft IPPM Way to store traceroutes February 2005 +---------------------------------------------------------+ | OS |Option| Description | Default | +-------+------+--------------------------------+---------+ | LINUX | -m |Specify the maximum TTL used | 30 | |-------+------|in outgoing probes. |---------| | UNIX | -m | | 30 | |-------+------| |---------| |WINDOWS| -h | | 30 | +-------+------+--------------------------------+---------+ | LINUX | -n |Display hop addresses | - | |-------+------|numerically rather than |---------| | UNIX | -n |simbolically. | - | |-------+------| |---------| |WINDOWS| -d | | - | +-------+------+--------------------------------+---------+ | LINUX | -w |Set the time to wait for a | 3 sec | |-------+------|response to a probe. |---------| | UNIX | -w | | 5 sec | |-------+------| |---------| |WINDOWS| -w | | 4 sec | +-------+------+--------------------------------+---------+ | LINUX | N/A |Specify a loose source route | - | |-------+------|gateway (to direct the |---------| | UNIX | -g |traceroute through routers not | - | |-------+------|necessarily in the path. |---------| |WINDOWS| -g | | - | +-------+------+--------------------------------+---------+ | LINUX | -p |Set the base UDP port number | 33434 | |-------+------|used in probes |---------| | UNIX | -p |(UDP port = base + nhops - 1). | 33434 | |-------+------| |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | -q |Set the number of probes per | 3 | |-------+------|TTL. |---------| | UNIX | -q | | 3 | |-------+------| |---------| |WINDOWS| N/A | | 3 | +-------+------+--------------------------------+---------+ | LINUX | -s |Set the IP source address in |IP | |-------+------|outgoing probes to the specified|address | | UNIX | -s |value. |of the | |-------+------| |out | |WINDOWS| N/A | |interface| +-------+------+--------------------------------+---------+ | LINUX | -t |Set the type-of-service (TOS) | 0 | |-------+------|in the probes to the specified |---------| | UNIX | -t |value. | 0 | Niccolini & Tartarelli Expires August 15, 2005 [Page 6] Internet-Draft IPPM Way to store traceroutes February 2005 |-------+------| |---------| |WINDOWS| N/A | | 0 | +-------+------+--------------------------------+---------+ | LINUX | -v |Verbose output: received ICMP | - | |-------+------|packets other than TIME_EXCEEDED|---------| | UNIX | -v |and UNREACHABLE are listed. | - | |-------+------| |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | -l |Display the TTL value of | - | |-------+------|returned packets. This is useful|---------| | UNIX | N/A |for checking for asymmetric | - | |-------+------|routing. |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | -r |Bypass the normal routing tables| - | |-------+------|and send directly to a host on |---------| | UNIX | -r |attached network. | - | |-------+------| |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | N/A |Set the initial TTL for the | 1 | |-------+------|first probe. |---------| | UNIX | -f | | 1 | |-------+------| |---------| |WINDOWS| N/A | | 1 | +-------+------+--------------------------------+---------+ | LINUX | N/A |Set the "don't fragment" bit. | - | |-------+------| |---------| | UNIX | -F | | - | |-------+------| |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | N/A |Enables socket level debugging. | - | |-------+------| |---------| | UNIX | -d | | - | |-------+------| |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | N/A |Use ICMP ECHO instead of UDP | - | |-------+------|datagrams. |---------| | UNIX | -I | | - | |-------+------| |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | N/A |Specify a network interface to | - | |-------+------|obtain the IP address for |---------| | UNIX | -i |outgoing IP packets (alternative| - | Niccolini & Tartarelli Expires August 15, 2005 [Page 7] Internet-Draft IPPM Way to store traceroutes February 2005 |-------+------|to option -s). |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | N/A |Toggle checksum. | - | |-------+------| |---------| | UNIX | -x | | - | |-------+------| |---------| |WINDOWS| N/A | | - | +-------+------+--------------------------------+---------+ | LINUX | - |As optional last paramater, |Depends | |-------+------|LINUX and UNIX implementations |on | | UNIX | - |allow specifying the probe |implement| |-------+------|datagram length for outgoing |ation. | |WINDOWS| N/A |probes. | | +-------+------+--------------------------------+---------+ Niccolini & Tartarelli Expires August 15, 2005 [Page 8] Internet-Draft IPPM Way to store traceroutes February 2005 3. Known problems with traceroute The widespred use of firewalls might prevent UDP or ICMP based traceroutes to completely trace the path to a destination, since traceroute probes might end up being filtered. In some cases, such limitation might be overcome by sending instead TCP packets to specific ports that hosts located behind the firewall are listening for connections on. TCP based implementations use TCP SYN or FYN probes and listen for TIME_EXCEEDED messages, TCP RESET and other messages from firewalls and gateways on the path. On the other hand, some firewalls filter out TCP SYN packets to prevent denial of service attacks, therefore the actual advantage of using TCP instead of UDP traceroute depends mainly on firewall configurations, which are not known in adavance. A detailed analysis of TCP based traceroutes is outside the scope of this draft, therefore in the sequel, we will restrict our focus to the most commonly implemented UDP based traceroute. Niccolini & Tartarelli Expires August 15, 2005 [Page 9] Internet-Draft IPPM Way to store traceroutes February 2005 4. Reports/results The following list reports the information fields provided by all traceroute implementations considered. The order in which they are reported here is not relevant and it changes in different implementations. For each hop the information reported is: o the hop index; o the host symbolical address, provided that at least one of the probes received a response, the symbolic address could be resolved at the correponding host and that the option to display only numerical addresses was not set; o the host IP address, provided that at least one of the probes received a response; o the RTT for each response to a probe. It might happen that some probes do not receive a response within the configured time-out (for instance if the probe is filtered out by a firewall). In this case, an "*" is displayed in place of the RTT. Besides, for delays below 1 ms, some implementations reports 0 ms (f.i. UNIX and LINUX) while WINDOWS tracert reports "< 1 ms". Niccolini & Tartarelli Expires August 15, 2005 [Page 10] Internet-Draft IPPM Way to store traceroutes February 2005 5. Information model for storing traceroutes measurements This section describes the information model for the traceroute measurements data storing. The information model is composed of information elements; for defining these information elements, a template is used. Such template is specified in the list below: o name - A unique and meaningful name for the information element. The preferred spelling for the name is to use mixed case if the name is compound, with an initial lower case letter, e.g., "sourceIpAddress". o description - The semantics of this information element. o dataType - One of the types listed in Section 5.1 of this document or in an extension of the information model. The type space for attributes is constrained to facilitate implementation. o units - If the element is a measure of some kind, the units identify what the measure is. o default value - The default value for the element (where applicable). 5.1 Data types This section describes the set of valid data types of the information model. o String - The type "String" represents a finite length string of valid characters from the Unicode character encoding set. Unicode allows for ASCII and many other international character sets to be used. It is expected that strings will be encoded in UTF-8 format, which is identical in encoding for USASCII characters, but also accomodates other Unicode multibyte characters. o InetAddressType - The type "InetAddressType" represents a type of Internet address. The allowed values and their syntax are to be intended as imported from [1]. o InetAddress - The type "InetAddress" denotes a generic Internet address. The allowed values and their syntax are to be intended as imported from [1]. o TruthValue - The type "TruthValue" represents a boolean value. The allowed values and their syntax are to be intended as imported from [2]. o Unsigned32 - The type "Unsigned32" represents a value in the range (0..4294967295). o InterfaceIndexOrZero - The type "InterfaceIndexOrZero" is an extension of the InterfaceIndex convention. The latter defines a greater than zero value used to identify an interface or interface sub-layer in the system. This extension permits the additional value of zero. Examples of the usage of zero might include situations where interface was unknown, or when none or all Niccolini & Tartarelli Expires August 15, 2005 [Page 11] Internet-Draft IPPM Way to store traceroutes February 2005 interfaces need to be referenced. The allowed values and their syntax are to be intended as imported from [5]. o ProbesType - The type "ProbesType" represents a way of indicating the protocol used for the traceroute probes. Allowed values are UDP, TCP, ICMP. o DateAndTime - The type "DateAndTime" represents a date-time specification. The allowed values and their syntax are to be intended as imported from [2]. o OperationResponseStatus - The type "OperationResponseStatus" is used to report the result of an operation. The allowed values and their syntax are to be intended as imported from [6] or from its recent update ([7]). 5.2 Information Elements This section describes the elements of the traceroute measurement. The elements are grouped in two groups (Configuration and Results) according to their semantics. 5.2.1 Configuration Information Elements This section describes the elements of the traceroute measurement that are specific to traceroute configuration. 5.2.1.1 traceRouteCtlTestName o name - traceRouteCtlTestName o description - Specifies the name of a traceroute test. This is locally unique. o dataType - String o units - N/A o default value - N/A 5.2.1.2 traceRouteCtlTargetAddressType o name - traceRouteCtlTargetAddressType o description - Specifies the type of host address used in the traceroute command. o dataType - InetAddressType o units - N/A o default value - N/A 5.2.1.3 traceRouteCtlTargetAddress o name - traceRouteCtlTargetAddress o description - Specifies the host address used in the traceroute command. The host address type can be determined by the examining the value of the corresponding traceRouteCtlTargetAddressType. Niccolini & Tartarelli Expires August 15, 2005 [Page 12] Internet-Draft IPPM Way to store traceroutes February 2005 o dataType - InetAddress o units - N/A o default value - N/A 5.2.1.4 traceRouteCtlByPassRouteTable o name - traceRouteCtlByPassRouteTable o description - Specifies if the optional bypassing of the route table was enabled or not. If enabled, the traceroute will bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly-attached network, an error is returned. This option can be used to perform the traceroute operation to a local host through an interface that has no route defined. o dataType - TruthValue o units - N/A o default value - false 5.2.1.5 traceRouteCtlProbeDataSize o name - traceRouteCtlProbeDataSize o description - Specifies the size of the data portion of a traceroute operation in octets. If the RECOMMENDED traceroute method (UDP datagrams as probes) is used, then the value contained in this object is exact. If another traceroute method is used for which the specified size is not appropriate, then the implementation should have used whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms). o dataType - Unsigned32 o units - octects o default value - 0 5.2.1.6 traceRouteCtlTimeOut o name - traceRouteCtlTimeOut o description - Specifies the time-out value, in seconds, for the traceroute operation. o dataType - Unsigned32 o units - seconds o default value - 3 Niccolini & Tartarelli Expires August 15, 2005 [Page 13] Internet-Draft IPPM Way to store traceroutes February 2005 5.2.1.7 traceRouteCtlProbesPerHop o name - traceRouteCtlProbesPerHop o description - Specifies the number of times to reissue a traceroute request with the same time-to-live (TTL) value. o dataType - Unsigned32 o units - probes o default value - 3 5.2.1.8 traceRouteCtlPort o name - traceRouteCtlPort o description - Specifies the base UDP port used by the traceroute operation. Need to specify a port that is not in use at the destination (target) host. The default value for this object is the IANA assigned port, 33434, for the traceroute function. o dataType - Unsigned32 o units - UDP Port o default value - 33434 5.2.1.9 traceRouteCtlMaxTtl o name - traceRouteCtlMaxTtl o description - Specifies the maximum TTL value for the traceroute operation. o dataType - Unsigned32 o units - time-to-live value o default value - 30 5.2.1.10 traceRouteCtlDSField o name - traceRouteCtlDSField o description - Specifies the value that was stored in the Differentiated Services (DS) field in the IP packet used to encapsulate the traceroute probe. The DS Field is defined as the Type of Service (TOS) octet in a IPv4 header or as the Traffic Class octet in a IPv6 header. The value of this object must be a decimal integer in the range from 0 to 255. This option can be used to determine what effect an explicit DS field setting has on a traceroute response. Not all values are legal or meaningful. DS field usage is often not supported by IP implementations. A value of 0 means that the function represented by this option is not supported. Useful TOS octet values are probably '16' (low delay) and '8' (high throughput). Further references can be found in [3] for the definition of the Differentiated Services (DS) field and to [4] Section 5.3.2 for Type of Service (TOS). o dataType - Unsigned32 Niccolini & Tartarelli Expires August 15, 2005 [Page 14] Internet-Draft IPPM Way to store traceroutes February 2005 o units - N/A o default value - 0 5.2.1.11 traceRouteCtlSourceAddressType o name - traceRouteCtlSourceAddressType o description - Specifies the type of the source address, traceRouteCtlSourceAddress, used when performing the traceroute operation. o dataType - InetAddressType o units - N/A o default value - N/A 5.2.1.12 traceRouteCtlSourceAddress o name - traceRouteCtlSourceAddress o description - Specifies the IP address (which had to be given as an IP number, not a hostname) as the source address used in outgoing probe packets. On hosts with more than one IP address, this option can be used to force the source address to be something other than the primary IP address of the interface the probe packet is sent on. A zero length octet string value for this object means that source address specification was disabled. The address type (InetAddressType) that relates to this object is specified by the corresponding value of traceRouteCtlSourceAddressType. o dataType - InetAddress o units - N/A o default value - N/A 5.2.1.13 traceRouteCtlIfIndex o name - traceRouteCtlIfIndex o description - Specifies the inferface index used in the traceroute operation for sending the traceroute probes. A value of zero for this object implies that the interface was unknown. o dataType - InterfaceIndexOrZero o units - N/A o default value - 0 5.2.1.14 traceRouteCtlMiscOptions o name - traceRouteCtlMiscOptions o description - Specifies implementation dependent options. o dataType - String o units - N/A o default value - N/A Niccolini & Tartarelli Expires August 15, 2005 [Page 15] Internet-Draft IPPM Way to store traceroutes February 2005 5.2.1.15 traceRouteCtlMaxFailures o name - traceRouteCtlMaxFailures o description - Specifies the maximum number of consecutive timeouts allowed before terminating a traceroute operation. A value of either 255 (maximum hop count/possible TTL value) or a 0 indicates that the function of terminating a remote traceroute operation when a specific number of consecutive timeouts are detected was disabled. This element is included to give full compatibility with [7]. No known implementation of traceroute currently supports it. o dataType - Unsigned32 o units - timeouts o default value - 5 5.2.1.16 traceRouteCtlDontFragment o name - traceRouteCtlDontFragment o description - Specifies if the don't fragment flag (DF) in the IP header for a probe was enabled or not. The use of the DF flag is intended to be relative to a manual PATH MTU test. o dataType - TruthValue o units - N/A o default value - false 5.2.1.17 traceRouteCtlInitialTtl o name - traceRouteCtlInitialTtl o description - Specifies the initial TTL value uses in a traceroute operation. The use of initial TTL setting is intended to be used when bypassing the initial (often well known) portion of a path is to be achieved. o dataType - Unsigned32 o units - N/A o default value - 1 5.2.1.18 traceRouteCtlDescr o name - traceRouteCtlDescr o description - The purpose of this element is to provide a description of the traceroute test. o dataType - String o units - N/A o default value - N/A 5.2.1.19 traceRouteCtlType Niccolini & Tartarelli Expires August 15, 2005 [Page 16] Internet-Draft IPPM Way to store traceroutes February 2005 o name - traceRouteCtlType o description - Specifies the implementation method used for the traceroute operation. o dataType - ProbesType o units - N/A o default value - UDP 5.2.2 Results Information Elements This section describes the elements of the traceroute measurement that are specific to the results of a traceroute operation. 5.2.2.1 traceRouteResultsStartDateAndTime o name - traceRouteResultsStartDateAndTime o description - Specifies the date and start time of the traceroute operation. This is the time when the first probe was seen at the sending interface. o dataType - DateAndTime o units - N/A o default value - N/A 5.2.2.2 traceRouteResultsIpTgtAddrType o name - traceRouteResultsIpTgtAddrType o description - Specifies the type of address stored in the corresponding traceRouteResultsIpTgtAddr element. o dataType - InetAddressType o units - N/A o default value - N/A 5.2.2.3 traceRouteResultsIpTgtAddr o name - traceRouteResultsIpTgtAddr o description - Specifies the IP address associated with a traceRouteCtlTargetAddress value when the destination address is specified as a DNS name. The value of this object should be a zero length octet string when a DNS name is not specified or when a specified DNS name fails to resolve. o dataType - InetAddress o units - N/A o default value - N/A 5.2.2.4 traceRouteResultsProbeIndex o name - traceRouteResultsProbeIndex o description - Specifies the progressive index of a probe within the traceroute operation. The maximum value here is the number Niccolini & Tartarelli Expires August 15, 2005 [Page 17] Internet-Draft IPPM Way to store traceroutes February 2005 resulting from the operation traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop. o dataType - Unsigned32 o units - N/A o default value - N/A 5.2.2.5 traceRouteResultsProbeHopIndex o name - traceRouteResultsProbeHopIndex o description - Specifies which hop in a traceroute path that the probe's results are for. The value of this element is initially determined by the value of traceRouteCtlInitialTtl. o dataType - Unsigned32 o units - N/A o default value - N/A 5.2.2.6 traceRouteResultsProbeIndexPerHop o name - traceRouteResultsProbeIndexPerHop o description - Specifies the index of a probe for a particular hop in a traceroute path. The number of probes per hop is determined by the value of the corresponding traceRouteCtlProbesPerHop element. o dataType - Unsigned32 o units - N/A o default value - N/A 5.2.2.7 traceRouteResultsProbeHopAddrType o name - traceRouteResultsProbeHopAddrType o description - Specifies the type of address stored in the corresponding traceRouteResultsProbeHopAddr element. o dataType - InetAddressType o units - N/A o default value - N/A 5.2.2.8 traceRouteResultsProbeHopAddr o name - traceRouteResultsProbeHopAddr o description - Specifies the address of a hop in the traceroute path. This object is not allowed to be a DNS name. The value of the corresponding object, traceRouteResultsProbeHopAddrType, indicates this object's IP address type. o dataType - InetAddress o units - N/A o default value - N/A Niccolini & Tartarelli Expires August 15, 2005 [Page 18] Internet-Draft IPPM Way to store traceroutes February 2005 5.2.2.9 traceRouteResultsProbeHopASNumber o name - traceRouteResultsProbeHopASNumber o description - Specifies the AS number of a hop in the traceroute path, when the value of this element is unknown or not relevant it should be set to zero. o dataType - Unsigned32 o units - N/A o default value - 0 5.2.2.10 traceRouteResultsProbeHopGeoLocation o name - traceRouteResultsProbeHopGeoLocation o description - Specifies the geo location of a hop in the traceroute path. o dataType - String o units - N/A o default value - N/A 5.2.2.11 traceRouteResultsProbeRoundTripTime o name - traceRouteResultsProbeRoundTripTime o description - Specifies the amount of time measured in milliseconds from when a probe was seen at the sending interface to when its response was seen at the receiving interface or when it timed out. The value of this element is reported as 0 when it was not possible to transmit a probe. o dataType - Unsigned32 o units - milliseconds o default value - N/A 5.2.2.12 traceRouteResultsProbeResponseStatus o name - traceRouteResultsProbeResponseStatus o description - Specifies the result of a traceroute operation made by the host for a particular probe. o dataType - OperationResponseStatus o units - N/A o default value - N/A 5.2.2.13 traceRouteResultsProbeTime o name - traceRouteResultsProbeTime o description - Specifies the timestamp for when the response to the probe was seen at the receiving interface. o dataType - DateAndTime o units - N/A Niccolini & Tartarelli Expires August 15, 2005 [Page 19] Internet-Draft IPPM Way to store traceroutes February 2005 o default value - N/A 5.2.2.14 traceRouteResultsEndDateAndTime o name - traceRouteResultsEndDateAndTime o description - Specifies the date and end time of the traceroute operation. It is either the time when the response to the last probe of the traceroute operation was seen at the receiving interface or the time when the last probe of the traceroute operation was seen at the sendin interface plus the relative timeout (in case of missing response). o dataType - DateAndTime o units - N/A o default value - N/A Niccolini & Tartarelli Expires August 15, 2005 [Page 20] Internet-Draft IPPM Way to store traceroutes February 2005 6. Data model for storing traceroutes measurements Discussion about the data model to be adopted for the traceroute storing is currently ongoing on the IPPM mailing list. The possibilities would be to define either just a textual representation or both textual and binary representations. Both approaches have pros and cons: the main issue is related to parsing resources associated with the representation itself as a trade-off versus readability. A good textual representation could be XML-based but it requires expensive parsers; that is why if the group would like to have an XML-based text representation we suggest to have also a binary representation that let the user choose how they want to store the measurement. Another possibility could also be to have a textual representation that require little parsing without a binary representation associated. For the data model choice there is the need to agree on the Information model defined in Section 5 and on the metrics defined in Section 7. On such a basis the data model itself will be defined. Niccolini & Tartarelli Expires August 15, 2005 [Page 21] Internet-Draft IPPM Way to store traceroutes February 2005 7. Relevant metrics for traceroute measurements The previous sections of this draft have been dealing with the traceroute tool description, its parameters and the output that is going to be stored; in this section we want to highlight the relevant metrics that are of interest when storing traceroute measurements. Since the traceroute has built-in configurable mechanisms like time-outs and can experience problems related to the crossing of firewalls, some of the packets that traceroute sends out end up being time-out or filtered. Sometimes it is impossible to trace the path to a node or there is not a complete set of probes describing the RTT to reach it. Classical metrics already standardized by the IPPM working group have to be closely examined in order to check for their applicability in the traceroute context. If some metrics are found not to be adequate, the authors will propose new metrics to remove the inconsistencies. The metrics that are currently under investigation by the authors of this draft are: o Round-trip delay metrics o Connectivity metrics o Loss metrics Niccolini & Tartarelli Expires August 15, 2005 [Page 22] Internet-Draft IPPM Way to store traceroutes February 2005 8. Conclusions This draft attempts to define a standard way to store traceroute measurements. The document starts by examining a set of traceroute tools from the most common operatying systems and provides a summary of configurable and default input parameters. This investigation served as base for the definition of an information model and related data model. Furthermore, this draft tackles the issue of metrics resulting from traceroute measurements. Metrics already standardized by the IPPM might indeed not be directly applicable to traceroute results, where it is necessary to take into account, for instance, for missing responses. The detailed analysis of the different metrics and potential proposals to overcome possible inconsistencies will be topic for future work. A number of open issues that still need to be discussed in the IPPM mailing list was also drafted. Niccolini & Tartarelli Expires August 15, 2005 [Page 23] Internet-Draft IPPM Way to store traceroutes February 2005 9. Security considerations Conducting Internet measurements can raise both security and privacy concerns. Traceroute measurements, in which traffic is injected into the network, can be abused for denial-of-service attacks disguised as legitimate measurement activity. This memo does not specify an implementation of the metrics, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns. Since traceroute measurements involve metrics of different types, each of the metric defined for storing traceroute measurments needs separate security considerations that are basically already covedered in the related RFCs published by the IPPM working group. The measurement parameters MUST be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases cause congestion and denial of service. The measurements themselves could be harmed by routers giving measurement traffic a different priority than "normal" traffic, or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss rate will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks. Niccolini & Tartarelli Expires August 15, 2005 [Page 24] Internet-Draft IPPM Way to store traceroutes February 2005 10. Open Issues This section is intended to keep track of the open issues that are to be discussed in the IPPM working group. o Agreement on the Data model for storing traceroute measurements. o Relevant metrics and their applicability to the traceroute case. o Security considerations may be improved. 11. Normative References [1] Daniele et al., M., "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [2] McCloghrie et al., K., "Textual Conventions for SMIv2", RFC 2579, April 1999. [3] Nichols et al., K., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [4] F. Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [5] McCloghrie et al., K., "The Interfaces Group MIB", RFC 2863, June 2000. [6] White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 2925, September 2000. [7] Quittek, J., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", DRAFT draft-ietf-disman-remops-mib-v2-06.txt, December 2004. Authors' Addresses Saverio Niccolini Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 18 Email: saverio.niccolini@netlab.nec.de URI: http://www.netlab.nec.de Niccolini & Tartarelli Expires August 15, 2005 [Page 25] Internet-Draft IPPM Way to store traceroutes February 2005 Sandra Tartarelli Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 32 Email: sandra.tartarelli@netlab.nec.de URI: http://www.netlab.nec.de Niccolini & Tartarelli Expires August 15, 2005 [Page 26] Internet-Draft IPPM Way to store traceroutes February 2005 Appendix A. Acknowledgments The authors would like to thank Juergen Quittek for the useful discussions. Niccolini & Tartarelli Expires August 15, 2005 [Page 27] Internet-Draft IPPM Way to store traceroutes February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Niccolini & Tartarelli Expires August 15, 2005 [Page 28]