idnits 2.17.1 draft-denis-icmpv6-generation-for-teredo-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 16, 2009) is 5333 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'METPI' is defined on line 300, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-01 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-01 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave WG T. Savolainen 3 Internet-Draft R. Denis-Courmont 4 Intended status: Standards Track Nokia 5 Expires: March 20, 2010 September 16, 2009 7 Generation of ICMPv6 Echo Replies for Teredo Clients 8 draft-denis-icmpv6-generation-for-teredo-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 20, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Teredo uses return routing to discover the closest Teredo relay 47 corresponding to any given peer. Discovery is achieved by sending an 48 ICMPv6 Echo Request and waiting for the appropriate relay to forward 49 the ICMPv6 Echo Reply back. Unanswered ICMPv6 Echo Requests make 50 Teredo clients assume that the peer is unreachable. This document 51 identifies two scenarios where a stateful middlebox can detect the 52 lack of ICMPv6 Echo Reply and craft one for the Teredo client in 53 order to avoid possibly erroneous peer unreachability assumptions. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 59 2. Behavioral requirements for middleboxes . . . . . . . . . . . . 4 60 2.1. Configuration options . . . . . . . . . . . . . . . . . . . 4 61 2.2. Protocol translators . . . . . . . . . . . . . . . . . . . 4 62 2.3. IPv6 firewalls . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Cryptographically Generated Addresses . . . . . . . . . . . 6 64 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The Teredo protocol [RFC4380] uses return routing to discover the 75 Teredo relay corresponding to any given IPv6 peer. Specifically, a 76 Teredo client sends an ICMPv6 Echo Request to the peer and waits for 77 a Teredo relay to forward the corresponding ICMPv6 Echo Reply back. 78 If this does not happen within a reasonable delay, the Teredo client 79 assumes that the peer cannot be reached via Teredo. In the IPv6 80 Internet, this normally works fine, as all IPv6 nodes implement 81 sending of ICMPv6 Echo Replies in response to ICMPv6 Echo Requests. 82 However, two scenarios have been identified where this Teredo 83 procedure might fail: 85 1) When a NAT-PT [RFC2766], NAT64 86 [I-D.ietf-behave-v6v4-xlate-stateful], or stateless 87 [I-D.ietf-behave-v6v4-xlate] protocol translator is on the data path: 88 the translator translates an IPv6 ICMPv6 Echo Request originating 89 from Teredo client into an IPv4 ICMPv4 Echo Request and forwards it 90 toward the IPv4 peer. However, in the IPv4 realm, ICMPv4 does not 91 always work reliably. If the IPv4 peer does not reply with an ICMPv4 92 Echo Reply for any reason (for example, ICMPv4 Echo Replies are 93 disabled or filtered by an IPv4 firewall), the Teredo client will not 94 get any ICMPv6 Echo Reply response packet back, and thus it will 95 determine that the peer is unreachable. That implies that transport 96 sessions, which otherwise could have succeeded, will not even be 97 initiated. Effectively IPv4 nodes on the other side of protocol 98 translators that do not successfully respond with ICMPv4 Echo Replies 99 cannot be reachable by Teredo clients. 101 2) When an IPv6 firewall blocks ICMPv6 Echo Requests or Replies: If a 102 Teredo client sends an ICMPv6 Echo Request to an IPv6 destination, 103 yet does not receive any ICMPv6 Echo Reply back, because IPv6 104 firewall discards either packet, the Teredo client will determine 105 that the peer cannot be reached. As a consequence, it will not even 106 try to route packets toward the destination. 108 In both cases, Teredo-based IPv6 flows fail. That will either cause 109 delays in transport-layer connection setup, if the host is able to 110 fall back to other source addresses, or complete connection failure 111 in other cases. 113 This document proposes a solution where a stateful middlebox detects 114 the possible problem occurring and helps a Teredo client to proceed 115 by generating an ICMPv6 Echo Reply for it. The proposed solution 116 does not cover scenarios involving stateless middleboxes, and is not 117 generally bulletproof. Namely, the solution may not always be able 118 to detect missing ICMPv6 Echo Reply and also may give false positive 119 indication about peer's reachability. However, the solution is 120 considered as improvement over the current state. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Behavioral requirements for middleboxes 130 A middlebox implementing this specification shall track ICMPv6 Echo 131 Requests originated from Teredo clients. The middlebox shall 132 generate ICMPv6 Echo Replies when determined necessary. By 133 generating the reply, the middlebox allows Teredo clients to go 134 forward with their connectivity establishment procedures. 136 A middlebox can determine the ICMPv6 Echo Request is coming from a 137 Teredo client from the packet's IPv6 source address prefix, 2001: 138 0000::/32, as described in RFC4380 [RFC4380]. However, the middlebox 139 cannot determine whether the ICMPv6 Echo Request is part of the 140 Teredo connectivity test procedure, or just "ping" sent from the 141 Teredo address. 143 2.1. Configuration options 145 The following options related to ICMPv6 Echo Reply generation should 146 be configurable on a middlebox supporting this specification: 148 o Enable/disable: ICMPv6 Echo Reply generation for Teredo clients. 150 o Enable/disable: Forced ICMPv6 Echo Reply generation for Teredo 151 clients. If enabled, the middlebox shall always generate an 152 ICMPv6 Echo Reply when it detects an ICMPv6 Echo Request was 153 originated from a Teredo client. If disabled, the middlebox shall 154 generate ICMPv6 Echo Reply when one has been determined missing. 156 The ICMPv6 Echo Reply generation MUST NOT be used if the middlebox is 157 not known to be on the return data path. Otherwise host-based Teredo 158 client relay feature could fail. 160 2.2. Protocol translators 162 As NAT-PT [RFC2766] or NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] 163 stateful protocol translator entity is always on the return data 164 path, it can detect whether an ICMPv4 Echo Reply is coming from the 165 IPv4 peer and, if not, is able to generate an ICMPv6 Echo Reply 166 toward the Teredo client. The translator must not assume that lack 167 of an ICMPv4 Echo Reply implies unavailability of the IPv4 peer. In 168 the scope of this document, the stateful translator can be considered 169 to be a single entity or a system containing multiple entities that 170 are synchronized with each other. In the case of stateless protocol 171 translation [I-D.ietf-behave-v6v4-xlate] the ICMPv6 Echo Reply 172 generation as presented here is not possible. 174 A protocol translator, if and only if it is on the return path, 175 SHOULD record the state of any translated ICMPv6 Echo Request, and if 176 no ICMPv4 Echo Reply is received within [TBD time], or if a 177 retransmitted ICMPv6 Echo Request is detected, an ICMPv6 Echo Reply 178 SHOULD be generated. The protocol translator should remove the state 179 after the ICMPv4 Echo Reply is received and translated, and the 180 ICMPv6 Echo Reply is generated, or TBD seconds since the last ICMPv6 181 Echo Request reception without retransmission. 183 A protocol translator, if and only if it is on the return path, 184 SHOULD by default have automatic ICMPv6 Echo Reply generation 185 enabled. 187 In case forced ICMPv6 Echo Reply generation is enabled, ICMPv6 Echo 188 Requests shall continue to be translated into ICMPv4 Echo Requests. 189 Also, any received ICMPv4 Echo Reply shall be translated into an 190 ICMPv6 Echo Reply. In that case, the Teredo client may receive 191 duplicate ICMPv6 Echo Replies. 193 2.3. IPv6 firewalls 195 The RFC4890 "Recommendations for Filtering ICMPv6 Messages in 196 Firewalls" [RFC4890] instructs firewalls not to filter ICMPv6 Echo 197 Requests, as those are needed for Teredo connectivity checks. This 198 section discusses how problems for Teredo clients can be mitigated if 199 a firewall nevertheless is configured to filter ICMPv6 Echo Requests 200 and or Replies. 202 By default IPv6 firewall MUST NOT generate ICMPv6 Echo Replies. The 203 lack of ICMPv6 Echo Reply should continue to indicate that the peer 204 is unreachable. Furthermore, the IPv6 firewall might not be on the 205 return data path in which case generated ICMPv6 Echo Replies might 206 break Teredo host-based relay feature. 208 A firewall that allows unsolicited incoming transport sessions 209 through, but is nevertheless filtering ICMPv6 Echo Requests, SHOULD 210 be configured to either let Teredo originated ICMPv6 Echo Requests 211 through, or to generate ICMPv6 Echo Replies for requests originated 212 by Teredo clients. Ultimately, it is up to the network administrator 213 who configures the ICMPv6 filtering in place to decide whether to 214 allow or block communication between Teredo clients and services 215 protected by the firewall. 217 Firewall SHOULD generate ICMPv6 Echo Reply even if the destination 218 IPv6 address of ICMPv6 Echo Request is not in use. This enables 219 Teredo to proceed and does not reveal information pertaining to the 220 existence and liveliness of hosts located behind the firewall. It 221 also saves the firewall from storing extra state. 223 2.4. Cryptographically Generated Addresses 225 Special considerations on both middleboxes and hosts are needed if 226 Crypthographically Generated Addresses (CGA) [RFC3972] are taken into 227 Internet-wide use. Obviously, the middlebox cannot sign the ICMPv6 228 Echo Reply it generates. This may cause issues to other middleboxes 229 and Teredo clients. 231 A CGA supporting Teredo client implementation should wait for 232 reasonable time [TBD?] for a signed ICMPv6 Echo Reply to arrive and 233 continue resending of ICMPv6 Echo Replies, even if it meanwhile 234 receives unsigned ICMPv6 Echo Replies. This helps to counter against 235 spoofed ICMPv6 Echo Reply attacks. However, if signed ICMPv6 Echo 236 Reply never arrives, the host is left with implementation and 237 deployment specific decision whether to fail or continue connection 238 creation procedures. 240 A CGA supporting middlebox, which does filtering (e.g. source address 241 validation) based on IPv6 packet signatures, has to consider whether 242 or not to allow unsigned, but solicited, ICMPv6 Echo Replies through. 243 This is also implementation and deployment specific consideration. 245 3. Acknowledgements 247 The authors would like to acknowledge Dave Thaler for his extensive 248 review and Tim Chown and Erik Kline for their comments. 250 This document was created by using template-bare.xml by Elwyn Davies 251 and xml2rfc tool. 253 4. IANA Considerations 255 This memo includes no request to IANA. 257 5. Security Considerations 259 Scanning for active IPv6 hosts behind a firewall is made useless by 260 firewall replying to all ICMPv6 Echo Requests sourced from Teredo 261 addresses. 263 Security is decreased if Cryptographically Generated Addresses (CGA) 264 [RFC3972] are used and systems choose to trust on unsigned ICMPv6 265 Echo Replies. 267 ICMPv6 Echo Reply generation MAY be rate-limited, especially per each 268 IPv6 address, to counter for denial-of-service attacks against the 269 middlebox itself and also against using middlebox as reflector. The 270 rate-limiting may cause problems for legitimate Teredo-clients' 271 communications and thus should be used only with caution. 273 6. References 275 6.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 281 RFC 3972, March 2005. 283 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 284 Network Address Translations (NATs)", RFC 4380, 285 February 2006. 287 6.2. Informative References 289 [I-D.ietf-behave-v6v4-xlate] 290 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 291 Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in 292 progress), September 2009. 294 [I-D.ietf-behave-v6v4-xlate-stateful] 295 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 296 Address and Protocol Translation from IPv6 Clients to IPv4 297 Servers", draft-ietf-behave-v6v4-xlate-stateful-01 (work 298 in progress), July 2009. 300 [METPI] Medina, A., Allman, M., and S. Floyd, "Measuring the 301 Evolution of Transport Protocols in the Internet", 2005. 303 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 304 Translation - Protocol Translation (NAT-PT)", RFC 2766, 305 February 2000. 307 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 308 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 310 Authors' Addresses 312 Teemu Savolainen 313 Nokia 314 Hermiankatu 12 D 315 TAMPERE, FI-33720 316 FINLAND 318 Email: teemu.savolainen@nokia.com 320 Remi Denis-Courmont 321 Nokia 322 P.O. Box 407 323 NOKIA GROUP, 00045 324 FINLAND 326 Phone: +358 50 487 6315 327 Email: remi.denis-courmont@nokia.com