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]