Internet DRAFT - draft-jacquin-opsawg-icmp-blackhole-problem
draft-jacquin-opsawg-icmp-blackhole-problem
Network Working Group L. Jacquin
Internet-Draft V. Roca
Intended status: Informational M. Kaafar
Expires: January 10, 2013 INRIA
July 9, 2012
ICMP black hole: problem position
draft-jacquin-opsawg-icmp-blackhole-problem-00
Abstract
ICMP is a key protocol to exchange control and error messages over
the Internet. Unfortunately it is frequent that some routers along a
given path do not correctly process this protocol. This document
provides a taxonomy of the problem in order to help an end user who
suspects ICMP-related problems to better understand the situation,
and possibly identify the faulty router(s).
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 January 10, 2013.
Copyright Notice
Copyright (c) 2012 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
Jacquin, et al. Expires January 10, 2013 [Page 1]
Internet-Draft ICMP black hole: problem position July 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
3. Problem position . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Path definitions . . . . . . . . . . . . . . . . . . . . . 3
3.2. Router behavior taxonomy . . . . . . . . . . . . . . . . . 4
3.3. Note on the use of traffic destined to R itself . . . . . . 6
3.4. Path characterization with respect to ICMP . . . . . . . . 6
4. A simple example . . . . . . . . . . . . . . . . . . . . . . . 7
5. Addressing complex situations: the need for dedicated tools . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Jacquin, et al. Expires January 10, 2013 [Page 2]
Internet-Draft ICMP black hole: problem position July 2012
1. Introduction
ICMP is the key protocol to exchange control and error messages over
the Internet. ICMP is also implied in several functionalities, like
the "Path Maximum Transmission Unit Discovery" (PMTUD) mechanism
[RFC1191]. For instance, in IPv4, the sender sets the "don't
fragment bit" (this is useless in IPv6 since fragmentation is not
authorized). If a router cannot transmit the packet because of its
size, it must send back to the source an ICMP "Too Big" (type 3, code
4 with IPv4 and type 2, code 0 with IPv6) packet. Iteratively, the
source will lower the packet size until it matches the lowest MTU on
the path.
An appropriate ICMP's processing throughout a path is therefore a key
requirement both for troubleshooting operations (e.g., debugging
routing problems) and for several functionalities (e.g., PMTUD).
Unfortunately certain routers of the Internet do not handle ICMP as
one would expect. For instance, some of them will not forward ICMP
packets on a given path, while others will not generate and send ICMP
packets in response to errors or solicitations (e.g., an ICMP "echo
request"). Note that the presence of ICMP black holes has been the
motivation for the design of ICMP-free alternatives to PMTUD, namely
the Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821]. In
the present document we take the opposite approach and try to improve
ICMP-related problem debugging in the Internet.
The present document is essentially a problem position document.
More precisely, the contributions are twofold:
o we provide a taxonomy of router behavior with respect to ICMP;
o we provide examples taken from real world experiments, using
existing tools to illustrate the previous discussion and taxonomy;
2. Requirements notation
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].
3. Problem position
3.1. Path definitions
Let us consider a path from a source S to a destination D, and a
router R along this path (there are typically several such routers
Jacquin, et al. Expires January 10, 2013 [Page 3]
Internet-Draft ICMP black hole: problem position July 2012
and R is one of them). We assume that the packet flow generated by S
and destined to D uses protocol PP. More specifically in this work
we consider either ICMP/IP, UDP/IP, or TCP/IP, where IP denotes
either IPv4 or IPv6.
ICMP packet
+---------------------------+
| ICMP return path |
v |
+--------+ initial packet +--------+ initial packet +-------------+
|Source S|----------------->|Router R|--------------->|Destination D|
+--------+ initial forward +--------+ final forward +-------------+
path path
Figure 1
We can define three different paths (Figure 1):
o the initial forward path: this is the path between S and R;
o the final forward path: this is the path between R and D;
o the ICMP return path: This is the path taken by ICMP packets
destined to S and generated either by R, or by a router on the
final forward path, or by D itself, and that go through R (this is
not necessarily the case);
It is important to note that the initial forward path up to R and the
return ICMP path from R are not necessarily identical since routers
often have different forwarding rules for each direction. The
forward initial or final paths also potentially depend on the nature
of the initial packet protocol, since routers often use protocol
dependent forwarding rules. Finally, it is important to note that
there are potentially as many ICMP return paths as there are routers
on the forwarding path.
3.2. Router behavior taxonomy
First of all, it is important to note that ICMP handling is not a
global property of a router. Said differently, two interfaces of a
given router may behave differently with respect to ICMP processing
(e.g., per interface firewall configuration can explain this
situation). Therefore we need to work at the interface level.
Moreover, for each interface we also differentiate incoming and
outcoming traffic. Said differently, a router behavior from S to D
may differ when considering the reverse direction, D to S.
Let us consider traffic from a source S to a destination D, and a
Jacquin, et al. Expires January 10, 2013 [Page 4]
Internet-Draft ICMP black hole: problem position July 2012
router R along this path. We first identify an ability, which is not
directly related to ICMP, but which has impacts on ICMP:
1. Ability A0: "correct IP processing of an incoming packet (not
necessarily an ICMP packet) on the initial forward path": even if
this is not an ICMP packet, it may have consequences on ICMP
behavior. For instance, if R does not decrement the IPv4 TTL/
IPv6 Hop Limit field, R will not generate an ICMP packet if this
field equals 1 upon being received by R.
We then distinguish three ICMP-related abilities for traffic from S
to D:
1. Ability A1: "R forwards ICMP packets destined to D on the final
forward path when appropriate": upon receiving an ICMP packet
from S, after A0 processing, when appropriate, does R forward it
to D?
2. Ability A2: "ICMP packet generation at R": if an event requiring
the generation of an ICMP packet occurs, does R forge an ICMP
packet and does R return it to S, regardless of whether this
packet arrives to S or not? For instance this ICMP packet can
result from an IPv4 TTL/IPv6 Hop Limit field that decrements to 0
during the forwarding of a packet received on the incoming
forward path;
3. Ability A3: "correct ICMP return path from R": when an ICMP
packet is sent back to S from R (when it is generated by R) or
through R (when it is generated by a router on the final forward
path, D included), does this packet reach S? It not necessarily
the case, even if R can generate ICMP packets, e.g., because of
ICMP filtering rules;
As a particular case, we also need to assess the destination D
abilities. These abilities are essentially the same as for router R,
with the distinction that:
1. Ability A1': "D processes ICMP packets destined to D as required
by the upper layers": Forwarding is replaced in that case by the
handling of the packet to the upper layers;
Those are the four main properties along which we assess R's behavior
and D's behavior. As explained, these properties are (S, D)
dependent (i.e. they depend on the path and direction), and there is
no way to determine for sure all the features of router R with
respect to ICMP. For instance, the R's behavior for another
interface, that is neither the two ones used for traffic from S to D,
may have completely different behavior when considering ICMP. Note
Jacquin, et al. Expires January 10, 2013 [Page 5]
Internet-Draft ICMP black hole: problem position July 2012
that having a full characterization of R is not required, since our
goal is to help solving ICMP black holes from S to D, and not to
determine R's full configuration policies with respect to ICMP.
3.3. Note on the use of traffic destined to R itself
It is of common practice to probe each router R directly, e.g., with
PING "Echo Request"/"Echo Reply" packets. This case almost
corresponds to the previous case where R is the destination (D and R
are identical). A limit of this approach is that there is no strong
guarantee that the initial forward path to R is identical with a
packet destined to R to the initial forward path to R with a packet
destined to D. However, this probing method can still be useful to
qualify ability A3, no matter whether the initial forward paths are
the same or not. Indeed, A3 share in both cases the same ICMP packet
source (R), destination (S) and protocol (ICMP).
3.4. Path characterization with respect to ICMP
Let us consider a path from a source S to a destination D, and let
R_0, R_1, .. R_n-1 be routers along this path. Let us assume this
path is fixed for the duration of the test (i.e., the list of the n
routers will not change). Then the path characterization consists in
providing the full list of abilities that could be determined for
each router plus the destination. Of course, an ability A may not be
determined, i.e., it can be either true or false, which is
represented by (A + !A).
S:
R0: A0.!A1.A2.A3 (R0 does not forward ICMP packets)
R1: A0.(A1+!A1).A2.A3 (we cannot assert if R1 forwards ICMP or not)
D: A0.(A1'+!A1').A2.A3
Figure 2: Simple path characterization example.
Let us consider a simple case (Figure 2) with two intermediate
routers, R0 and R1, where R0 does not forward ICMP packets on path S
to D. In that case there is no way to determine ability A1 on R1 and
A1' on D, but other abilities may be determined since they rely on
different mechanisms. For example, A0 can be determined by using UDP
as a probing protocol, A2 can be determined by using a TTL value that
decrements to 0 on R0, R1 or D with UDP or TCP as probing protocol,
and since we assume that the ICMP packet returned on the return path
arrives to S, A3 is determined too.
This examples shows that the determination of abilities for router R
can impact our detection of the abilities for router on the final
forward path after R. Of course, it does not impact the routers
Jacquin, et al. Expires January 10, 2013 [Page 6]
Internet-Draft ICMP black hole: problem position July 2012
abilities themselves, only our view of their abilities. Going
further in the determination of all the router abilities may require
additional control of the network, for instance via vintage points
(i.e., routers or hosts within the core network that allows us to
inject and observe traffic between S and D).
4. A simple example
Let us consider the following example where the path between S and D
crosses three routers: R0, R1 and R2. The user, located behind S,
experiments bandwidth problems when using TCP (e.g., through an HTTP
or SSH connection), and more precisely small TCP segments reach D but
not large ones. In order to investigate the problem, the user will
probably ping D and in that case will obtain a reply. Therefore this
test is not of significant value to the user. So the user continues
investigating the problem and uses the traceroute tool, with either
TCP or ICMP as the probing protocols. The results are presented in
Figure 3. The user can deduce that R1, whose IP address (iP_R1) is
obtained by the traceroute/ICMP test, does not forge any ICMP packet
in response to TCP packets whose IPv4 TTL/IPv6 Hop Limit is
decremented to 0 on R. Thus the user can deduce that its bandwidth
problem is due to an erroneous configuration of R1, which by not
forging ICMP packets when handling TCP packets, deprives S from using
PMTUD.
Router | Traceroute TCP | Traceroute ICMP
S: | IP_S | IP_S
R0: | IP_R0 | IP_R0
R1: | * * * | IP_R1
R2: | IP_R2 | IP_R2
D: | IP_D | IP_D
Figure 3: Traceroute example.
5. Addressing complex situations: the need for dedicated tools
If the example of Section 4 can relatively easily be characterized,
this is not the case with more complex situations. In [Jacquin12] we
detail the IBTrack (ICMP Black hole Tracker) tool that provides a
general methodology to achieve this kind of analysis. Depending on
the assumptions that can be made, different tools can also be used.
In particular if vantage points within the core network can be used,
a more detailed diagnosis can probably be made by refining the
observations, using different observations from different vantage
points. Similarly, if the destination D can be involved in the
process, some abilities of the routers may be refined, even if some
Jacquin, et al. Expires January 10, 2013 [Page 7]
Internet-Draft ICMP black hole: problem position July 2012
of the ICMP return paths are not functioning.
Therefore the present document should be regarded as a problem
position document. Practical approaches and tools will be introduced
and discussed in separate documents.
6. Security Considerations
TBD
7. Acknowledgements
The authors want to thank the other authors of [Jacquin12], namely
Fabrice Schuler and Jean-Louis Roch.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[Jacquin12]
Jacquin, L., Roca, V., Kaafar, M., Schuler, F., and J-L.
Roch, "IBTrack: an ICMP black holes tracker", IEEE
Globecom 2012, http://hal.inria.fr/hal-00695746/en/,
December 2012.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
Jacquin, et al. Expires January 10, 2013 [Page 8]
Internet-Draft ICMP black hole: problem position July 2012
Authors' Addresses
Ludovic Jacquin
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: ludovic.jacquin@inria.fr
URI: http://planete.inrialpes.fr/~jacquin/
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/~roca/
Mohamed-Ali Kaafar
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
Email: mohamed-ali.kaafar@inria.fr
URI: http://planete.inrialpes.fr/~kaafar/
Jacquin, et al. Expires January 10, 2013 [Page 9]
