Behave WG T. Savolainen Internet-Draft R. Denis-Courmont Intended status: Standards Track Nokia Expires: March 20, 2010 September 16, 2009 Generation of ICMPv6 Echo Replies for Teredo Clients draft-denis-icmpv6-generation-for-teredo-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 20, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Teredo uses return routing to discover the closest Teredo relay corresponding to any given peer. Discovery is achieved by sending an ICMPv6 Echo Request and waiting for the appropriate relay to forward Savolainen & Denis-Courmont Expires March 20, 2010 [Page 1] Internet-Draft ICMPv6 Echo Replies for Teredo September 2009 the ICMPv6 Echo Reply back. Unanswered ICMPv6 Echo Requests make Teredo clients assume that the peer is unreachable. This document identifies two scenarios where a stateful middlebox can detect the lack of ICMPv6 Echo Reply and craft one for the Teredo client in order to avoid possibly erroneous peer unreachability assumptions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 2. Behavioral requirements for middleboxes . . . . . . . . . . . . 4 2.1. Configuration options . . . . . . . . . . . . . . . . . . . 4 2.2. Protocol translators . . . . . . . . . . . . . . . . . . . 4 2.3. IPv6 firewalls . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Cryptographically Generated Addresses . . . . . . . . . . . 6 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Savolainen & Denis-Courmont Expires March 20, 2010 [Page 2] Internet-Draft ICMPv6 Echo Replies for Teredo September 2009 1. Introduction The Teredo protocol [RFC4380] uses return routing to discover the Teredo relay corresponding to any given IPv6 peer. Specifically, a Teredo client sends an ICMPv6 Echo Request to the peer and waits for a Teredo relay to forward the corresponding ICMPv6 Echo Reply back. If this does not happen within a reasonable delay, the Teredo client assumes that the peer cannot be reached via Teredo. In the IPv6 Internet, this normally works fine, as all IPv6 nodes implement sending of ICMPv6 Echo Replies in response to ICMPv6 Echo Requests. However, two scenarios have been identified where this Teredo procedure might fail: 1) When a NAT-PT [RFC2766], NAT64 [I-D.ietf-behave-v6v4-xlate-stateful], or stateless [I-D.ietf-behave-v6v4-xlate] protocol translator is on the data path: the translator translates an IPv6 ICMPv6 Echo Request originating from Teredo client into an IPv4 ICMPv4 Echo Request and forwards it toward the IPv4 peer. However, in the IPv4 realm, ICMPv4 does not always work reliably. If the IPv4 peer does not reply with an ICMPv4 Echo Reply for any reason (for example, ICMPv4 Echo Replies are disabled or filtered by an IPv4 firewall), the Teredo client will not get any ICMPv6 Echo Reply response packet back, and thus it will determine that the peer is unreachable. That implies that transport sessions, which otherwise could have succeeded, will not even be initiated. Effectively IPv4 nodes on the other side of protocol translators that do not successfully respond with ICMPv4 Echo Replies cannot be reachable by Teredo clients. 2) When an IPv6 firewall blocks ICMPv6 Echo Requests or Replies: If a Teredo client sends an ICMPv6 Echo Request to an IPv6 destination, yet does not receive any ICMPv6 Echo Reply back, because IPv6 firewall discards either packet, the Teredo client will determine that the peer cannot be reached. As a consequence, it will not even try to route packets toward the destination. In both cases, Teredo-based IPv6 flows fail. That will either cause delays in transport-layer connection setup, if the host is able to fall back to other source addresses, or complete connection failure in other cases. This document proposes a solution where a stateful middlebox detects the possible problem occurring and helps a Teredo client to proceed by generating an ICMPv6 Echo Reply for it. The proposed solution does not cover scenarios involving stateless middleboxes, and is not generally bulletproof. Namely, the solution may not always be able to detect missing ICMPv6 Echo Reply and also may give false positive indication about peer's reachability. However, the solution is Savolainen & Denis-Courmont Expires March 20, 2010 [Page 3] Internet-Draft ICMPv6 Echo Replies for Teredo September 2009 considered as improvement over the current state. 1.1. Requirements Language 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 [RFC2119]. 2. Behavioral requirements for middleboxes A middlebox implementing this specification shall track ICMPv6 Echo Requests originated from Teredo clients. The middlebox shall generate ICMPv6 Echo Replies when determined necessary. By generating the reply, the middlebox allows Teredo clients to go forward with their connectivity establishment procedures. A middlebox can determine the ICMPv6 Echo Request is coming from a Teredo client from the packet's IPv6 source address prefix, 2001: 0000::/32, as described in RFC4380 [RFC4380]. However, the middlebox cannot determine whether the ICMPv6 Echo Request is part of the Teredo connectivity test procedure, or just "ping" sent from the Teredo address. 2.1. Configuration options The following options related to ICMPv6 Echo Reply generation should be configurable on a middlebox supporting this specification: o Enable/disable: ICMPv6 Echo Reply generation for Teredo clients. o Enable/disable: Forced ICMPv6 Echo Reply generation for Teredo clients. If enabled, the middlebox shall always generate an ICMPv6 Echo Reply when it detects an ICMPv6 Echo Request was originated from a Teredo client. If disabled, the middlebox shall generate ICMPv6 Echo Reply when one has been determined missing. The ICMPv6 Echo Reply generation MUST NOT be used if the middlebox is not known to be on the return data path. Otherwise host-based Teredo client relay feature could fail. 2.2. Protocol translators As NAT-PT [RFC2766] or NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] stateful protocol translator entity is always on the return data path, it can detect whether an ICMPv4 Echo Reply is coming from the IPv4 peer and, if not, is able to generate an ICMPv6 Echo Reply toward the Teredo client. The translator must not assume that lack Savolainen & Denis-Courmont Expires March 20, 2010 [Page 4] Internet-Draft ICMPv6 Echo Replies for Teredo September 2009 of an ICMPv4 Echo Reply implies unavailability of the IPv4 peer. In the scope of this document, the stateful translator can be considered to be a single entity or a system containing multiple entities that are synchronized with each other. In the case of stateless protocol translation [I-D.ietf-behave-v6v4-xlate] the ICMPv6 Echo Reply generation as presented here is not possible. A protocol translator, if and only if it is on the return path, SHOULD record the state of any translated ICMPv6 Echo Request, and if no ICMPv4 Echo Reply is received within [TBD time], or if a retransmitted ICMPv6 Echo Request is detected, an ICMPv6 Echo Reply SHOULD be generated. The protocol translator should remove the state after the ICMPv4 Echo Reply is received and translated, and the ICMPv6 Echo Reply is generated, or TBD seconds since the last ICMPv6 Echo Request reception without retransmission. A protocol translator, if and only if it is on the return path, SHOULD by default have automatic ICMPv6 Echo Reply generation enabled. In case forced ICMPv6 Echo Reply generation is enabled, ICMPv6 Echo Requests shall continue to be translated into ICMPv4 Echo Requests. Also, any received ICMPv4 Echo Reply shall be translated into an ICMPv6 Echo Reply. In that case, the Teredo client may receive duplicate ICMPv6 Echo Replies. 2.3. IPv6 firewalls The RFC4890 "Recommendations for Filtering ICMPv6 Messages in Firewalls" [RFC4890] instructs firewalls not to filter ICMPv6 Echo Requests, as those are needed for Teredo connectivity checks. This section discusses how problems for Teredo clients can be mitigated if a firewall nevertheless is configured to filter ICMPv6 Echo Requests and or Replies. By default IPv6 firewall MUST NOT generate ICMPv6 Echo Replies. The lack of ICMPv6 Echo Reply should continue to indicate that the peer is unreachable. Furthermore, the IPv6 firewall might not be on the return data path in which case generated ICMPv6 Echo Replies might break Teredo host-based relay feature. A firewall that allows unsolicited incoming transport sessions through, but is nevertheless filtering ICMPv6 Echo Requests, SHOULD be configured to either let Teredo originated ICMPv6 Echo Requests through, or to generate ICMPv6 Echo Replies for requests originated by Teredo clients. Ultimately, it is up to the network administrator who configures the ICMPv6 filtering in place to decide whether to allow or block communication between Teredo clients and services Savolainen & Denis-Courmont Expires March 20, 2010 [Page 5] Internet-Draft ICMPv6 Echo Replies for Teredo September 2009 protected by the firewall. Firewall SHOULD generate ICMPv6 Echo Reply even if the destination IPv6 address of ICMPv6 Echo Request is not in use. This enables Teredo to proceed and does not reveal information pertaining to the existence and liveliness of hosts located behind the firewall. It also saves the firewall from storing extra state. 2.4. Cryptographically Generated Addresses Special considerations on both middleboxes and hosts are needed if Crypthographically Generated Addresses (CGA) [RFC3972] are taken into Internet-wide use. Obviously, the middlebox cannot sign the ICMPv6 Echo Reply it generates. This may cause issues to other middleboxes and Teredo clients. A CGA supporting Teredo client implementation should wait for reasonable time [TBD?] for a signed ICMPv6 Echo Reply to arrive and continue resending of ICMPv6 Echo Replies, even if it meanwhile receives unsigned ICMPv6 Echo Replies. This helps to counter against spoofed ICMPv6 Echo Reply attacks. However, if signed ICMPv6 Echo Reply never arrives, the host is left with implementation and deployment specific decision whether to fail or continue connection creation procedures. A CGA supporting middlebox, which does filtering (e.g. source address validation) based on IPv6 packet signatures, has to consider whether or not to allow unsigned, but solicited, ICMPv6 Echo Replies through. This is also implementation and deployment specific consideration. 3. Acknowledgements The authors would like to acknowledge Dave Thaler for his extensive review and Tim Chown and Erik Kline for their comments. This document was created by using template-bare.xml by Elwyn Davies and xml2rfc tool. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations Scanning for active IPv6 hosts behind a firewall is made useless by Savolainen & Denis-Courmont Expires March 20, 2010 [Page 6] Internet-Draft ICMPv6 Echo Replies for Teredo September 2009 firewall replying to all ICMPv6 Echo Requests sourced from Teredo addresses. Security is decreased if Cryptographically Generated Addresses (CGA) [RFC3972] are used and systems choose to trust on unsigned ICMPv6 Echo Replies. ICMPv6 Echo Reply generation MAY be rate-limited, especially per each IPv6 address, to counter for denial-of-service attacks against the middlebox itself and also against using middlebox as reflector. The rate-limiting may cause problems for legitimate Teredo-clients' communications and thus should be used only with caution. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. 6.2. Informative References [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in progress), September 2009. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-01 (work in progress), July 2009. [METPI] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", 2005. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. Savolainen & Denis-Courmont Expires March 20, 2010 [Page 7] Internet-Draft ICMPv6 Echo Replies for Teredo September 2009 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007. Authors' Addresses Teemu Savolainen Nokia Hermiankatu 12 D TAMPERE, FI-33720 FINLAND Email: teemu.savolainen@nokia.com Remi Denis-Courmont Nokia P.O. Box 407 NOKIA GROUP, 00045 FINLAND Phone: +358 50 487 6315 Email: remi.denis-courmont@nokia.com Savolainen & Denis-Courmont Expires March 20, 2010 [Page 8]