| INTAREA | R. Bonica |
| Internet-Draft | R. Thomas |
| Updates: 4884 (if approved) | Juniper Networks |
| Intended status: Standards Track | J. Linkova |
| Expires: March 5, 2018 | |
| C. Lenart | |
| Verizon | |
| M. Boucadair | |
| Orange | |
| September 1, 2017 |
PROBE: A Utility For Probing Interfaces
draft-ietf-intarea-probe-05
This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884.
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 5, 2018.
Copyright (c) 2017 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 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.
Network operators use PING to test bidirectional connectivity between two interfaces. For the purposes of this document, we will call these interfaces the probing and probed interfaces. PING sends an ICMP [RFC4443] Echo message from the probing interface to the probed interface. The probing interface resides on a probing node while the probed interface resides on a probed node.
If the probed interface receives the ICMP Echo message, it returns an ICMP Echo Reply. When the probing interface receives the ICMP Echo Reply, it has verified bidirectional connectivity between the probing and probed interfaces. Specifically, it has verified that:
This document describes a network diagnostic tool called PROBE. PROBE is similar to PING, in that it can be used to test the status of a probed interface. It differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Alternatively, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. Section 5 of this document describes scenarios in which this characteristic is useful.
Like PING, PROBE executes on a probing node. It sends an ICMP Extended Echo message from a local interface, called the probing interface, to a proxy interface. The proxy interface resides on a probed node.
The ICMP Extended Echo Request contains an ICMP Extension Structure and the ICMP Extension Structure contains an Interface Identification Object. The Interface Identification Object identifies the probed interface. The probed interface can reside on the probed node or it can be directly connected to the probed node.
When the proxy interface receives the ICMP Extended Echo Request, it executes access control procedures. If access is granted, the probed node determines the status of the probed interface and returns an ICMP Extended Echo Reply Message. The ICMP Extended Echo Reply indicates the status of the probed interface.
If the probed interface resides on the probed node, PROBE determines the status of the probed interface as it would determine its MIB-II ifOperStatus. If ifOperStatus is equal to up (1), PROBE reports that the probed interface is active. Otherwise, PROBE reports that the probed interface is inactive.
If the probed interface resides on a node that is directly connected to the probed node, PROBE reports that the interface is up if it appears in the IPv4 Address Resolution Protocol (ARP) table or the IPv6 Neighbor Cache. Otherwise, it reports that the interface does not exist.
This document uses the following terms:
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 RFC 2119.
The ICMP Extended Echo Request message is defined for both ICMPv4 and ICMPv6. Like any ICMP message, the ICMP Extended Echo Request message is encapsulated in an IP header. The ICMPv4 version of the Extended Echo Request message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header.
Figure 1 depicts the ICMP Extended Echo Request message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |Sequence Number| Reserved |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Extension Structure
Figure 1: ICMP Extended Echo Request Message
IP Header fields:
ICMP fields:
Section 7 of [RFC4884] defines the ICMP Extension Structure. As per RFC 4884, the Extension Structure contains exactly one Extension Header followed by one or more objects. When applied to the ICMP Extended Echo Request message, the ICMP Extension Structure MUST contain one or two instances of the Interface Identification Object.
In most cases, a single instance of the Interface Identification Object identifies the probed interface. However, in some cases, a second instance is required for disambiguation.
If the L-bit is set, the Interface Identification Object identifies the probed interface by name, index or address. It the L-bit is clear, the Interface Identification Object identifies the probed interface by address.
If the Interface Identification Object identifies the probed interface by address, that address can be a member of any address family. For example, an ICMPv4 Extended Echo Request message can carry an Interface Identification Object that identifies the probed interface by IPv4, IPv6 or IEEE 802 address. Likewise, an ICMPv6 Extended Echo Request message can carry an Interface Identification Object that identifies the probed interface by IPv4, IPv6 or IEEE 802 address.
The Interface Identification Object identifies the probed interface by name, index, or address. Like any other ICMP Extension Object, it contains an Object Header and Object Payload. The Object Header contains the following fields:
If the Interface Identification Object identifies the probed interface by name, the object payload MUST be the MIB-II [RFC2863] ifName. If the object payload would not otherwise terminate on a 32-bit boundary, it MUST be padded with ASCII NULL characters.
If the Interface Identification Object identifies the probed interface by index, the length is equal to 8 and the payload contains the MIB-II ifIndex [RFC2863].
If the Interface Identification Object identifies the probed interface by address, the payload is as depicted in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Address Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address ....
Figure 2: Interface Identification Object - C-type 3 Payload
Payload fields are defined as follows:
The ICMP Extended Echo Reply message is defined for both ICMPv4 and ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message is encapsulated in an IP header. The ICMPv4 version of the Extended Echo Reply message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header.
Figure 3 depicts the ICMP Extended Echo Reply message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |Sequence Number| Resvd |A|F|S|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ICMP Extened Echo Reply Message
IP Header fields:
ICMP fields:
When a node receives an ICMP Extended Echo Request message and any of the following conditions apply, the node MUST silently discard the incoming message:
Otherwise, when a node receives an ICMPv4 Extended Echo Request, it MUST format an ICMP Extended Echo Reply as follows:
When a node receives an ICMPv6 Extended Echo Request, it MUST format an ICMPv6 Extended Echo Reply as follows:
In either case, the responding node MUST:
The Code field MUST be set to Malformed Query (1) if any of the following conditions apply:
The Code field MUST be set to No Such Interface (2) if any of the following conditions apply:
The Code field MUST be set to Multiple Interfaces Satisfy Query (3) if any of the following conditions apply:
Otherwise, the Code field MUST be set to No Error (0)
In the scenarios listed below, network operators can use PROBE to determine the status of a probed interface, but cannot use PING for the same purpose. In all scenarios, assume bidirectional connectivity between the probing and proxy interfaces. However, bidirectional connectivity between the probing and probed interfaces is lacking.
Section 4.6 of RFC 4884 provides a list of extensible ICMP messages (i.e., messages that can carry the ICMP Extension Structure). This document adds the ICMP Extended Echo message and the ICMP Extended Echo Reply message to that list.
This document requests the following actions from IANA:
Note to RFC Editor: this section may be removed on publication as an RFC.
The following are legitimate uses of PROBE:
However, malicious parties can use PROBE to obtain additional information. For example, a malicious party can use PROBE to discover interface names. Having discovered an interface name, the malicious party may be able to infer additional information. Additional information may include:
Understanding this risk, network operators establish policies that restrict access to ICMP Extended Echo functionality. In order to enforce these polices, nodes that support ICMP Extended Echo functionality MUST support the following configuration options:
When a node receives an ICMP Extended Echo Request message that it is not configured to support, it MUST silently discard the message. See Section 4 for details.
PROBE MUST NOT leak information about one Virtual Private Network (VPN) into another. Therefore, when a node receives an ICMP Extended Echo Request and the proxy interface is in a different VPN than the probed interface, the node MUST return an ICMP Extended Echo Reply with error code equal to (2) No Such Interface.
In order to protect local resources, implementations SHOULD rate-limit incoming ICMP Extended Echo Request messages.
| [RFC0792] | Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2863] | McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000. |
| [RFC4443] | Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006. |
| [RFC4884] | Bonica, R., Gan, D., Tappan, D. and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007. |
| [RFC2151] | Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, DOI 10.17487/RFC2151, June 1997. |
| [RFC4594] | Babiarz, J., Chan, K. and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006. |
The PROBE application accepts input parameters, sets a counter and enters a loop to be exited when the counter is equal to zero. On each iteration of the loop, PROBE emits an ICMP Extended Echo Request, decrements the counter, sets a timer, waits for the timer to expire. If an expected ICMP Extended Echo Reply arrives while PROBE is waiting for the timer to expire, PROBE relays information returned by that message to its user. However, on each iteration of the loop, PROBE waits for the timer to expire, regardless of whether an Extended Echo Reply message arrives.
PROBE accepts the following parameters:
Count is a positive integer whose default value is 3. Count determines the number of times that PROBE iterates through the above-mentioned loop.
Wait is a positive integer whose minimum and default values are 1. Wait determines the duration of the above-mentioned timer, measured in seconds.
Probing Interface Address specifies the source address of ICMP Extended Echo Request. The Probing Interface Address MUST be a unicast address and MUST identify an interface that is local to the probing node.
The Proxy Interface Address identifies the interface to which the ICMP Extended Echo Request message is sent. It can be an IPv4 or IPv6 address. If it is an IPv4 address, PROBE emits an ICMPv4 message. If it is an IPv6 address, PROBE emits an ICMPv6 message.
Local is a boolean value. It is TRUE if the proxy and probed interfaces both reside on the probed node. It is FALSE if the proxy interface resides on the probed node and the probed interface is directly connected to the probed node.
The probed interface is the interface whose status is being queried. It is identified by one of the following:
If the probed interface identifier is an address, it does not need to be of the same address family as the proxy interface address. For example, PROBE accepts an IPv4 destination interface address and an IPv6 probed interface identifier
Thanks to Sowmini Varadhan, Jeff Haas, Carlos Pignataro, Jonathan Looney, Dave Thaler, Mikio Hara and Joe Touch for their thoughtful review of this document.