Internet N. Shen
Internet-Draft C. Pignataro
Intended status: Standards Track R. Asati
Expires: March 16, 2012 E. Chen
Cisco Systems
A. Atlas
Juniper Networks
September 13, 2011
Traceroute and Ping Message Extension
draft-shen-traceroute-ping-ext-02
Abstract
This document specifies extensions to traceroute and ping techniques
to enable their (probes) authentication, and to include requests for
node specific information that the probe sender is interested in
receiving from one or more nodes via the traceroute and ping replies.
These extensions support UDP, TCP and ICMP types of traceroute and
ping probes.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 16, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Shen, et al. Expires March 16, 2012 [Page 1]
Internet-Draft Traceroute Extension September 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Specification of Requirements . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Probe Message Extension . . . . . . . . . . . . . . . . . . . 4
4.1. Probe Structure . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Probe Common Header . . . . . . . . . . . . . . . . . 4
4.1.2. Probe TLV . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2.1. Probe Authentication TLV . . . . . . . . . . . . . 5
4.1.2.2. Probe Information-Request TLV . . . . . . . . . . 7
4.2. Probe Extension Offset Field . . . . . . . . . . . . . . . 7
4.2.1. UDP Messages . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. TCP Messages . . . . . . . . . . . . . . . . . . . . . 8
4.2.3. ICMP Messages . . . . . . . . . . . . . . . . . . . . 8
4.2.4. Implementation Discussion . . . . . . . . . . . . . . 8
5. Implementation and Operation Considerations . . . . . . . . . 9
5.1. Traceroute and Ping Probe Sender . . . . . . . . . . . . . 9
5.2. Traceroute and Ping Probe Receiver . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Shen, et al. Expires March 16, 2012 [Page 2]
Internet-Draft Traceroute Extension September 2011
1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
Traceroute and Ping are two of commonly used tools in the diagnosis
of network problems. This document proposes the mechanism by which
the (traceroute or ping) probe message can be authenticated by the
receiving node(s). This document also specifies the mechanism for
the probe sending node to request specific information from the
receiving node(s). These mechanisms are intended for network
operators to perform more secured network management and
troubleshooting tasks while using traceroute and ping tools. The
changes proposed in this document are backward compatible (with the
existing traceroute and ping tools) and applicable to both IPv4 and
IPv6 networks.
The mechanisms specified in this document apply to to the following
traceroute and ping probe protocols: UDP [RFC0768], TCP [RFC0793],
and ICMP/ICMPv6 [RFC0792] [RFC4443].
This document defines an extension for traceroute and ping probe
messages to optionally include authentication signature. The
intermediate and destination nodes can authenticate the sender of the
traceroute or ping packet before providing the requested information
in the ICMP response. This document also includes an Information-
Request TLV for the traceroute/ping extension. This TLV specifies
the types of information the sender expects to be included in the
traceroute/ping response (i.e., in the ICMP message elicited by the
traceroute/ping packet and generated by the intermediate or
destination node or nodes).
This specification is evolved from the UDP Traceroute Extension
document [I-D.shen-udp-traceroute-ext].
3. Motivation
Although one may employ a rudimentary control mechanism to limit the
trusted senders by defining on every router the access control lists
specifying source addresses of the traceroute and ping message, such
mechanism is deemed configuration intensive, static, and error-prone.
Moreover, such mechanism would be susceptible to address spoofing.
Additionally, such mechanism does not provide the sender with dynamic
Shen, et al. Expires March 16, 2012 [Page 3]
Internet-Draft Traceroute Extension September 2011
control of the different kind of extensions to be requested.
The ICMP reply messages has been extended to support multi-part
message inside ICMP [RFC4884]. Some of the applications [RFC5837]
[RFC4950] [I-D.shen-icmp-routing-inst] are designed mainly for
internal network troubleshooting by network operators. Network
providers may want to limit those applications only to trusted
senders of traceroute/ping probes due to security or policy reasons
by using this mechanism described in this document.
4. Probe Message Extension
This proposed extension is to define a probe data structure which
resides within UDP/TCP/ICMP data field; and to reserve the lowest 4
bits inside a 16-bit field within UDP/TCP/ICMP headers to indicate
the extension structure offset location.
In most of the traceroute implementation, there is some private data
in probe messages used by traceroute applications. With this
"extension offset" defined, the applications can continue to use
those private data while supporting this probe extension in a
deterministic way. This extension applies to both traceroute and
ping applications.
4.1. Probe Structure
The probe structure starts in UDP/TCP/ICMP data field location from 0
to 56 octets specified in the "extension offset", see Section 4.2, in
32-bit boundary. It MUST have exactly one probe common header
followed by zero or more probe TLVs.
4.1.1. Probe Common Header
The Common Header is a 8 octets structure has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number (0x54726163) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the Common Header are defined as follows:
Shen, et al. Expires March 16, 2012 [Page 4]
Internet-Draft Traceroute Extension September 2011
Version: 4 bits. It is defined as 1 in this document.
Length: 12 bits. The total length of the probe data structure
specifying number of 32-bit words (includes the common
header and all the TLVs).
Checksum: 16 bits. The one's complement of the one's complement sum
of the probe data structure, with the checksum field
replaced by zero for the purpose of computing the checksum.
Magic Number: 32 bits. It is defined as Hex value of 0x54726163 in
this document. This is used mainly for structure
identification of this extension version.
4.1.2. Probe TLV
Probe TLVs (Type-Length-Value tuples) have the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 bits.
Length: 16 bits. Length of the Value field in octets.
Value: Depends on the Type. It is zero padded to align to a
4-octet boundary.
This document defines two TLVs below.
4.1.2.1. Probe Authentication TLV
This TLV carries the HMAC authentication related information. It
verifies both the data integrity and the authenticity of the entire
message. This TLV has the following format:
Shen, et al. Expires March 16, 2012 [Page 5]
Internet-Draft Traceroute Extension September 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Authentication) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Auth Data (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type: 16 bits. The following values are proposed:
* Type=0 signifies no authentication.
* Type=1 signifies simple password based authentication.
* Type=2 signifies Cryptographic authentication.
Please note that the above type values are in line with IANA
allocated values for other protocols (e.g., OSPF).
Key ID: 8 bits. This allows multiple secret keys to be active
simultaneously. Using Key IDs makes the key rollover
convenient. Each secret key must be associated with the
hash algorithm. This may be done through provisioning on
each node.
Auth Data Len: 8 bits. This specifies the length of the
authentication data (and allows for the support of current
and future authentication schemes).
Auth Data: Variable length. This field carries the result (e.g.,
HMAC code) of the HMAC algorithm applied over the entire
traceroute/ping IP/IPv6 packet. When the Auth data is
calculated, the shared key is stored in this field, and the
checksum fields in the IP header, UDP/TCP/ICMP header and
probe common header are set to zero. The result of the
algorithm is placed in the Auth Key field. The following
lists algorithms that could be commonly supported:
* HMAC-MD5
* HMAC-SHA1
* HMAC-SHA2 variants (e.g., 224, 256, 384, 512, etc.)
Shen, et al. Expires March 16, 2012 [Page 6]
Internet-Draft Traceroute Extension September 2011
At least HMAC-MD5 and HMAC-SHA1 algorithms should be
supported on all the nodes compliant with this
specification.
4.1.2.2. Probe Information-Request TLV
The Information-Request TLV has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Info-Req) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Info Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Info-Req: 32 bits. This bitflag field lists the request items the
probe sender is interested. The bit number ranges from the
right most bit to the left most bit. Currently defined as
the following:
Bit Number Information Item
0 MPLS label related attributes
1 Interface related attributes
2 IP/IPv6 address related attributes
3 Routing Instance related attributes
4 Nexthop(s) related attributes
5 Device role related attributes
4.2. Probe Extension Offset Field
This probe "extension offset" field is defined as the lowest nibble
within a 16-bit field, and it specifies the position at which the
probe extension data structure begins. The value represents 32-bit
words ranges from 0x0 to 0xF, with value 0xF as reserved. Thus the
position of the probe data structure can start from 0 to 56 octets
inside TCP, UDP or ICMP data field. The probe "extension offset"
field value 0xF indicates there is no probe data structure inside the
message data field.
The probe "extension offset" field is defined as the following:
Shen, et al. Expires March 16, 2012 [Page 7]
Internet-Draft Traceroute Extension September 2011
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Ext-Off|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Off: 4 bits. The value (Ext-Off) represents the probe data
structure start position in 32-bit words. The Ext-Off value
0xF is reserved.
The rest of the 12 bits out of this 16-bit field is not changed by
this proposal. For application usage detail in terms of different
traceroute/ping probe types, see Section 4.2.4.
4.2.1. UDP Messages
In the UDP traceroute/ping probe case, this 16-bit field is the UDP
source port field in UDP header [RFC0768]. The "Ext-Off" specifies
the probe extension structure start location inside UDP data field.
4.2.2. TCP Messages
In the TCP traceroute/ping probe case, this 16-bit field is the TCP
source port field in TCP header [RFC0793]. The "Ext-Off" specifies
the probe extension structure start location inside TCP data field.
4.2.3. ICMP Messages
In the ICMP traceroute/ping probe case, this 16-bit field is the
"Identifier" field of ICMP type 8 structure [RFC0792], The "Ext-Off"
specifies the probe extension structure start location inside ICMP
data field of the type 8(ICMP echo request) message.
4.2.4. Implementation Discussion
In the majority of today's traceroute implementations, the
application process identifier (process-ID) is used as the UDP source
port for UDP type of traceroute probe; in TCP implementation, the
process-ID is used as the TCP source port for traceroute probe; and
the process-ID is also used as the ICMP Identifier of ICMP type 8
message. With this extension, an implementation can use the highest
12-bits of the source port field for UDP/TCP header and ID field for
ICMP type 8 message to encode this process information since the
lowest 4-bits are now reserved for the probe "extension offset".
Ping implementation is similar to traceroute, it either uses the
process-ID or an internally generated number inside the ICMP echo
request ID field and in UDP/TCP source port field. An implementation
Shen, et al. Expires March 16, 2012 [Page 8]
Internet-Draft Traceroute Extension September 2011
now can use the highest 12-bits of the field and leave the lowest
4-bits for the probe extension.
5. Implementation and Operation Considerations
There is no change in this extension for the normal traceroute/ping
implementation and operation except for reserving the lowest 4 bits
in the UDP/TCP source port field and ICMP Id field of type 8 message.
The implementations for the sender can use the same semantics with
this 16-bit field; and it makes no difference to the receivers if
they don't support this extension.
5.1. Traceroute and Ping Probe Sender
The sender supports this extension MAY include the Probe structure in
it's traceroute/ping probe to specify the request types and
authentication key. The sender SHOULD set the "extension offset"
value to 0xF if there is no Probe structure present inside the probe.
The sender MAY request one or multiple types of information defined
in the probe "Info-Req" TLV.
5.2. Traceroute and Ping Probe Receiver
When the traceroute/ping probe receiver, the intermediate and
destination node, processes the incoming probe, it MAY check the
Probe structure to verify if the sender is from an authenticated host
and to see what types of information it requested. This check is
only needed when the receiver tries to authenticate the probe sender,
or when the receiver is formating the ICMP and ICMPv6s that support
multi-part messages and it has certain internal information that can
be included in the ICMP packets.
If the probe "extension offset" value is not 0xF, the probe structure
may be present. The receiver MUST verify the integrity of the data
structure by examining the "version" field, the Magic-Number value,
and the length of the probe structure. It MUST perform the checksum
to verify the probe data structure. If the authentication TLV is
present and the local policy requires it to perform the verification,
the receiver MUST use it's locally stored shared key to validate the
checksum in the TLV. Multiple Authentication Keys can be used which
can be useful in the case the probes are from trusted peer networks.
If the probe "Info-Req" TLV is included, the receiver SHOULD fetch
the related information when formating the ICMP packets, but MUST NOT
include information that has the corresponding bitflag cleared.
Even if the authentication fails, the receiver MAY still send the
Shen, et al. Expires March 16, 2012 [Page 9]
Internet-Draft Traceroute Extension September 2011
regular ICMP echo reply back to the sender, without the requested or
internal information, as if this probe extension is not supported.
6. Security Considerations
This extension enhances the security of traceroute and ping operation
in a backwards-compatible fashion. The mechanism allows the receiver
to verify the sender of the traceroute/ping packet such that certain
sensitive interface and network related information can be supplied
in the internal network or across trusted networks.
The use of Cryptographic authentication (i.e., an Auth Type value of
2) allows for a strong authentication mechanism since the keys cannot
be discerned by intercepting the packets. The proposed Keyed
authentication does not prevent replay attacks. However, in the case
of replay attacks, since the packet source IP/IPv6 address of the
traceroute/ping probe can not be changed, there is no easy way for
the attacker to retrieve the ICMP messages.
A router needs to protect against purposefully-bogus Traceroute
packets with extensions that fail the authentication, as a high rate
of messages can require significant processing time. [RFC1812]
specifies how rate-limiting is applied to the generation of ICMP
messages, and this rate-limiting deters the threat when applied
before checking the Authentication. Additionally, when using
Cryptographic authentication, the HMAC includes the source IP
address, which means the HMAC will not validate if the traceroute/
ping packet is sent over a NAT.
7. IANA Considerations
The Probe Extension contains probe TLVs. IANA should establish a
registry of Probe Extension Types. This document defines Type 1 and
Type 2 for authentication and information-request. Types 3-0xF6 are
allocated through Expert Review [RFC5226]. Types 0xF7 to 0xFF are
reserved for private use.
IANA should also establish a registry for Probe Info-Request Bits.
This document defines bits 0 - 5 in Section 4.1.2.2. Bits 6-29 are
allocated through Expert Review. Bits 30 - 31 are reserved for
private use.
8. Acknowledgements
Many thanks to Dan Wing and Tony Li, for their insightful comments
Shen, et al. Expires March 16, 2012 [Page 10]
Internet-Draft Traceroute Extension September 2011
and valuable suggestions regarding this document.
9. References
9.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.shen-icmp-routing-inst]
Shen, N. and E. Chen, "ICMP Extensions for Routing
Instances", draft-shen-icmp-routing-inst-00 (work in
progress), November 2006.
[I-D.shen-udp-traceroute-ext]
Shen, N., Pignataro, C., Asati, R., and E. Chen, "UDP
Traceroute Message Extension",
draft-shen-udp-traceroute-ext-01 (work in progress),
June 2008.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
Extensions for Multiprotocol Label Switching", RFC 4950,
August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Shen, et al. Expires March 16, 2012 [Page 11]
Internet-Draft Traceroute Extension September 2011
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
Rivers, "Extending ICMP for Interface and Next-Hop
Identification", RFC 5837, April 2010.
Authors' Addresses
Naiming Shen
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
Email: naiming@cisco.com
Carlos Pignataro
Cisco Systems
7200 Kit Creek Road
Research Triangle Park, NC 27709
USA
Email: cpignata@cisco.com
Rajiv Asati
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
USA
Email: rajiva@cisco.com
Enke Chen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: enkechen@cisco.com
Shen, et al. Expires March 16, 2012 [Page 12]
Internet-Draft Traceroute Extension September 2011
Alia K. Atlas
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: akatlas@juniper.net
Shen, et al. Expires March 16, 2012 [Page 13]