idnits 2.17.1 draft-jacquin-opsawg-icmp-blackhole-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 9, 2012) is 4302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Jacquin 3 Internet-Draft V. Roca 4 Intended status: Informational M. Kaafar 5 Expires: January 10, 2013 INRIA 6 July 9, 2012 8 ICMP black hole: problem position 9 draft-jacquin-opsawg-icmp-blackhole-problem-00 11 Abstract 13 ICMP is a key protocol to exchange control and error messages over 14 the Internet. Unfortunately it is frequent that some routers along a 15 given path do not correctly process this protocol. This document 16 provides a taxonomy of the problem in order to help an end user who 17 suspects ICMP-related problems to better understand the situation, 18 and possibly identify the faulty router(s). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 10, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 56 3. Problem position . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Path definitions . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Router behavior taxonomy . . . . . . . . . . . . . . . . . 4 59 3.3. Note on the use of traffic destined to R itself . . . . . . 6 60 3.4. Path characterization with respect to ICMP . . . . . . . . 6 61 4. A simple example . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Addressing complex situations: the need for dedicated tools . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 ICMP is the key protocol to exchange control and error messages over 73 the Internet. ICMP is also implied in several functionalities, like 74 the "Path Maximum Transmission Unit Discovery" (PMTUD) mechanism 75 [RFC1191]. For instance, in IPv4, the sender sets the "don't 76 fragment bit" (this is useless in IPv6 since fragmentation is not 77 authorized). If a router cannot transmit the packet because of its 78 size, it must send back to the source an ICMP "Too Big" (type 3, code 79 4 with IPv4 and type 2, code 0 with IPv6) packet. Iteratively, the 80 source will lower the packet size until it matches the lowest MTU on 81 the path. 83 An appropriate ICMP's processing throughout a path is therefore a key 84 requirement both for troubleshooting operations (e.g., debugging 85 routing problems) and for several functionalities (e.g., PMTUD). 86 Unfortunately certain routers of the Internet do not handle ICMP as 87 one would expect. For instance, some of them will not forward ICMP 88 packets on a given path, while others will not generate and send ICMP 89 packets in response to errors or solicitations (e.g., an ICMP "echo 90 request"). Note that the presence of ICMP black holes has been the 91 motivation for the design of ICMP-free alternatives to PMTUD, namely 92 the Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821]. In 93 the present document we take the opposite approach and try to improve 94 ICMP-related problem debugging in the Internet. 96 The present document is essentially a problem position document. 97 More precisely, the contributions are twofold: 99 o we provide a taxonomy of router behavior with respect to ICMP; 101 o we provide examples taken from real world experiments, using 102 existing tools to illustrate the previous discussion and taxonomy; 104 2. Requirements notation 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Problem position 112 3.1. Path definitions 114 Let us consider a path from a source S to a destination D, and a 115 router R along this path (there are typically several such routers 116 and R is one of them). We assume that the packet flow generated by S 117 and destined to D uses protocol PP. More specifically in this work 118 we consider either ICMP/IP, UDP/IP, or TCP/IP, where IP denotes 119 either IPv4 or IPv6. 121 ICMP packet 122 +---------------------------+ 123 | ICMP return path | 124 v | 125 +--------+ initial packet +--------+ initial packet +-------------+ 126 |Source S|----------------->|Router R|--------------->|Destination D| 127 +--------+ initial forward +--------+ final forward +-------------+ 128 path path 130 Figure 1 132 We can define three different paths (Figure 1): 134 o the initial forward path: this is the path between S and R; 136 o the final forward path: this is the path between R and D; 138 o the ICMP return path: This is the path taken by ICMP packets 139 destined to S and generated either by R, or by a router on the 140 final forward path, or by D itself, and that go through R (this is 141 not necessarily the case); 143 It is important to note that the initial forward path up to R and the 144 return ICMP path from R are not necessarily identical since routers 145 often have different forwarding rules for each direction. The 146 forward initial or final paths also potentially depend on the nature 147 of the initial packet protocol, since routers often use protocol 148 dependent forwarding rules. Finally, it is important to note that 149 there are potentially as many ICMP return paths as there are routers 150 on the forwarding path. 152 3.2. Router behavior taxonomy 154 First of all, it is important to note that ICMP handling is not a 155 global property of a router. Said differently, two interfaces of a 156 given router may behave differently with respect to ICMP processing 157 (e.g., per interface firewall configuration can explain this 158 situation). Therefore we need to work at the interface level. 159 Moreover, for each interface we also differentiate incoming and 160 outcoming traffic. Said differently, a router behavior from S to D 161 may differ when considering the reverse direction, D to S. 163 Let us consider traffic from a source S to a destination D, and a 164 router R along this path. We first identify an ability, which is not 165 directly related to ICMP, but which has impacts on ICMP: 167 1. Ability A0: "correct IP processing of an incoming packet (not 168 necessarily an ICMP packet) on the initial forward path": even if 169 this is not an ICMP packet, it may have consequences on ICMP 170 behavior. For instance, if R does not decrement the IPv4 TTL/ 171 IPv6 Hop Limit field, R will not generate an ICMP packet if this 172 field equals 1 upon being received by R. 174 We then distinguish three ICMP-related abilities for traffic from S 175 to D: 177 1. Ability A1: "R forwards ICMP packets destined to D on the final 178 forward path when appropriate": upon receiving an ICMP packet 179 from S, after A0 processing, when appropriate, does R forward it 180 to D? 182 2. Ability A2: "ICMP packet generation at R": if an event requiring 183 the generation of an ICMP packet occurs, does R forge an ICMP 184 packet and does R return it to S, regardless of whether this 185 packet arrives to S or not? For instance this ICMP packet can 186 result from an IPv4 TTL/IPv6 Hop Limit field that decrements to 0 187 during the forwarding of a packet received on the incoming 188 forward path; 190 3. Ability A3: "correct ICMP return path from R": when an ICMP 191 packet is sent back to S from R (when it is generated by R) or 192 through R (when it is generated by a router on the final forward 193 path, D included), does this packet reach S? It not necessarily 194 the case, even if R can generate ICMP packets, e.g., because of 195 ICMP filtering rules; 197 As a particular case, we also need to assess the destination D 198 abilities. These abilities are essentially the same as for router R, 199 with the distinction that: 201 1. Ability A1': "D processes ICMP packets destined to D as required 202 by the upper layers": Forwarding is replaced in that case by the 203 handling of the packet to the upper layers; 205 Those are the four main properties along which we assess R's behavior 206 and D's behavior. As explained, these properties are (S, D) 207 dependent (i.e. they depend on the path and direction), and there is 208 no way to determine for sure all the features of router R with 209 respect to ICMP. For instance, the R's behavior for another 210 interface, that is neither the two ones used for traffic from S to D, 211 may have completely different behavior when considering ICMP. Note 212 that having a full characterization of R is not required, since our 213 goal is to help solving ICMP black holes from S to D, and not to 214 determine R's full configuration policies with respect to ICMP. 216 3.3. Note on the use of traffic destined to R itself 218 It is of common practice to probe each router R directly, e.g., with 219 PING "Echo Request"/"Echo Reply" packets. This case almost 220 corresponds to the previous case where R is the destination (D and R 221 are identical). A limit of this approach is that there is no strong 222 guarantee that the initial forward path to R is identical with a 223 packet destined to R to the initial forward path to R with a packet 224 destined to D. However, this probing method can still be useful to 225 qualify ability A3, no matter whether the initial forward paths are 226 the same or not. Indeed, A3 share in both cases the same ICMP packet 227 source (R), destination (S) and protocol (ICMP). 229 3.4. Path characterization with respect to ICMP 231 Let us consider a path from a source S to a destination D, and let 232 R_0, R_1, .. R_n-1 be routers along this path. Let us assume this 233 path is fixed for the duration of the test (i.e., the list of the n 234 routers will not change). Then the path characterization consists in 235 providing the full list of abilities that could be determined for 236 each router plus the destination. Of course, an ability A may not be 237 determined, i.e., it can be either true or false, which is 238 represented by (A + !A). 240 S: 241 R0: A0.!A1.A2.A3 (R0 does not forward ICMP packets) 242 R1: A0.(A1+!A1).A2.A3 (we cannot assert if R1 forwards ICMP or not) 243 D: A0.(A1'+!A1').A2.A3 245 Figure 2: Simple path characterization example. 247 Let us consider a simple case (Figure 2) with two intermediate 248 routers, R0 and R1, where R0 does not forward ICMP packets on path S 249 to D. In that case there is no way to determine ability A1 on R1 and 250 A1' on D, but other abilities may be determined since they rely on 251 different mechanisms. For example, A0 can be determined by using UDP 252 as a probing protocol, A2 can be determined by using a TTL value that 253 decrements to 0 on R0, R1 or D with UDP or TCP as probing protocol, 254 and since we assume that the ICMP packet returned on the return path 255 arrives to S, A3 is determined too. 257 This examples shows that the determination of abilities for router R 258 can impact our detection of the abilities for router on the final 259 forward path after R. Of course, it does not impact the routers 260 abilities themselves, only our view of their abilities. Going 261 further in the determination of all the router abilities may require 262 additional control of the network, for instance via vintage points 263 (i.e., routers or hosts within the core network that allows us to 264 inject and observe traffic between S and D). 266 4. A simple example 268 Let us consider the following example where the path between S and D 269 crosses three routers: R0, R1 and R2. The user, located behind S, 270 experiments bandwidth problems when using TCP (e.g., through an HTTP 271 or SSH connection), and more precisely small TCP segments reach D but 272 not large ones. In order to investigate the problem, the user will 273 probably ping D and in that case will obtain a reply. Therefore this 274 test is not of significant value to the user. So the user continues 275 investigating the problem and uses the traceroute tool, with either 276 TCP or ICMP as the probing protocols. The results are presented in 277 Figure 3. The user can deduce that R1, whose IP address (iP_R1) is 278 obtained by the traceroute/ICMP test, does not forge any ICMP packet 279 in response to TCP packets whose IPv4 TTL/IPv6 Hop Limit is 280 decremented to 0 on R. Thus the user can deduce that its bandwidth 281 problem is due to an erroneous configuration of R1, which by not 282 forging ICMP packets when handling TCP packets, deprives S from using 283 PMTUD. 285 Router | Traceroute TCP | Traceroute ICMP 286 S: | IP_S | IP_S 287 R0: | IP_R0 | IP_R0 288 R1: | * * * | IP_R1 289 R2: | IP_R2 | IP_R2 290 D: | IP_D | IP_D 292 Figure 3: Traceroute example. 294 5. Addressing complex situations: the need for dedicated tools 296 If the example of Section 4 can relatively easily be characterized, 297 this is not the case with more complex situations. In [Jacquin12] we 298 detail the IBTrack (ICMP Black hole Tracker) tool that provides a 299 general methodology to achieve this kind of analysis. Depending on 300 the assumptions that can be made, different tools can also be used. 301 In particular if vantage points within the core network can be used, 302 a more detailed diagnosis can probably be made by refining the 303 observations, using different observations from different vantage 304 points. Similarly, if the destination D can be involved in the 305 process, some abilities of the routers may be refined, even if some 306 of the ICMP return paths are not functioning. 308 Therefore the present document should be regarded as a problem 309 position document. Practical approaches and tools will be introduced 310 and discussed in separate documents. 312 6. Security Considerations 314 TBD 316 7. Acknowledgements 318 The authors want to thank the other authors of [Jacquin12], namely 319 Fabrice Schuler and Jean-Louis Roch. 321 8. References 323 8.1. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 8.2. Informative References 330 [Jacquin12] 331 Jacquin, L., Roca, V., Kaafar, M., Schuler, F., and J-L. 332 Roch, "IBTrack: an ICMP black holes tracker", IEEE 333 Globecom 2012, http://hal.inria.fr/hal-00695746/en/, 334 December 2012. 336 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 337 November 1990. 339 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 340 Discovery", RFC 4821, March 2007. 342 Authors' Addresses 344 Ludovic Jacquin 345 INRIA 346 655, av. de l'Europe 347 Inovallee; Montbonnot 348 ST ISMIER cedex 38334 349 France 351 Email: ludovic.jacquin@inria.fr 352 URI: http://planete.inrialpes.fr/~jacquin/ 354 Vincent Roca 355 INRIA 356 655, av. de l'Europe 357 Inovallee; Montbonnot 358 ST ISMIER cedex 38334 359 France 361 Email: vincent.roca@inria.fr 362 URI: http://planete.inrialpes.fr/~roca/ 364 Mohamed-Ali Kaafar 365 INRIA 366 655, av. de l'Europe 367 Inovallee; Montbonnot 368 ST ISMIER cedex 38334 369 France 371 Email: mohamed-ali.kaafar@inria.fr 372 URI: http://planete.inrialpes.fr/~kaafar/