Subject: (ngtrans) W.G. Last Call on "Shipworm/Teredo: Tunneling IPv6 over UDP through NATs"

From: Bob Fink <[email-masked]>
Date: Thu, 21 Feb 2002 19:29:09 -0800

This is an ngtrans working group last call for comments on advancing the
following document as a Proposed Standard:

	Title		: Teredo: Tunneling IPv6 over UDP through NATs
	Author(s)	: Christian Huitema <[email-masked]>
	Filename	: draft-ietf-ngtrans-shipworm-05.txt
	Pages		: 49
	Date		: 20-Feb-02

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-05.txt>

SHIPWORM, (now referred to as TEREDO), had a last call in October with
extensive IESG comments conveyed this January. The chairs decided that it
was necessary to do another last call accompanied with the author's
summary of his response to these comments (see below).

Please send substantive comments to the ngtrans mailing list, and minor
editorial comments to the author.  This last call period will end on
March 29, 2002, the week after the upcoming IETF meeting in Minneapolis
to allow for meeting discussion and replies. The chairs believe this is
reasonable timing as the IESG will not be able to process the draft prior
to the Minneapolis meeting, and giving the extra time will allow more
careful consideration before and during the IETF meetings of all the
issues before re-forwarding SHIPWORM/TEREDO.

Alain Durand / Bob Fink/ Tony Hain

=Christian's response to IESG comments on SHIPWORM/TEREDO:

The IESG reviewers raised several big issues, and then quite a few small
ones. I believe that these issues are reasonably addressed by the
revised shipworm/teredo draft, draft-ietf-ngtrans-teredo-05.txt.

The big issues are:

1) The apparent lack of a clear "statement of objectives", explaining
why, when and where to use Teredo/teredo. A related issue is a desire to
have a solution that is as short term as possible and does not interfere
with other transition strategies.

2) The fact that the specification is hard to read, that the document
lacks an easy to understand "model of operation".

3) A concern about routing stability, and specifically how to perform
ingress filtering in the presence of "anycast" addresses.

4) The "UNSAF" aspect of crossing a NAT and obtaining an address without
an explicit interaction with the NAT.

5) A concern that some aspects of the specification might be
problematic, notably shortcut routes between two teredo nodes and
determination of time-out intervals.

6) A security concern about possible attacks against the teredo
infrastructure, and the possibility that this infrastructure be used to
enable attacks against third parties.

Many of these issues where addressed in the mailing discussions, and is
reflected in the minutes of the NGTRANS WG meeting in London
(http://www.ietf.org/proceedings/01aug/51-76.htm), but clearly some of
these discussions did not translate into written paragraphs in the
specification. I believe that the new draft addresses this concerns, for
the reasons stated in this message.

1) Statement of objectives

The first point, "why, where and when," has been debated at length on
this list. In the revised draft, an entire section (3.2) is dedicated to
explaining that we are aiming at providing an "IPv6 provider of last
resort"; this section comes earlier in the document and is much more
explicit that the short paragraph that explained the position in the
previous document. A sub section explains the "sunset" scenario, i.e.
that fact that nodes will cease using the teredo service when they can
get connectivity either natively or through other transition
technologies, e.g. 6to4 in a home router.

It is true that wishing for a technology sunset does not necessarily
cause it to occur. At some point, we have to rely on the good faith of
the implementors. My personal experience is that implementers are
concerned with the performance of their products, and will thus prefer
using native transmission or 6to4 whenever these technologies are
available. In any case, the directions on when to use or not use a
technology belong more in the applicability statement than in the
specification itself.

2) Model of operation

The second point, the lack of an easy to understand "model of
operation", is addressed by reorganizing the document and documenting
the model of operation in a specific section, presenting the interaction
between clients, servers, relays and third parties in the various
scenarios: obtaining an address, communicating between teredo hosts and
native IPv6 hosts, communicating between two teredo hosts at separate
locations, and communicating between two hosts at the same location.

3) Interaction with routing

The interactions with routing are developed in the new draft. The new
requirement section explicitly states a requirement of "compatibility
with ingress filtering". The new draft requires that a server should
only source a packet from an anycast address if it is able and willing
to globally advertise a route to that anycast address. This meets the
address filtering requirement, but poses a constraint on the deployment
of servers.

To alleviate this constraint, the draft specifies how providers can
set-up "local teredo networks", using addresses and prefixes taken from
their normal allocation. The clients will have to be configured with the
local networks parameters, i.e. the prefix value and the specific
anycast address used by the network.

A consequence is that we cannot rely anymore on a single /16 prefix for
Teredo, and that we must accomodate the use of longer prefixes in the
local networks. Various parts of the specification have been rewritten
to allow for these variable length prefix.

4) UNSAF aspects of crossing a NAT

The fourth point, the fact that the specification does not assume any
cooperation from the local or remote NAT, is also a direct consequence
of a design goal; this design goal was clearly approved by the WG. The
list discussions pointed out three possible NAT stances: don't care,
active support, active disapproval. The active disapproval is partially
addressed in section 6.10 about firewalls, which state that "[a] local
administrator can decide to allow or disallow the service by programming
the local firewall to authorize or deny traffic on the Teredo UDP port."

A point made in the UNSAF document is that many UNSAF solutions fail to
recognize the absence of clear "inside" and "outside". This comment does
not apply in our case, since the deployment rules for teredo servers
actually create an "orientation" in the topology. In addition, the
transmission rules are carefully designed to fall back to the safe
relaying of packets through the teredo servers, which works in any
topology.

At a somewhat broader level, we should observe that Teredo has three
properties that make it much more palatable than other "UNSAF hacks."
First, the solution operates at the network level, under the hood; this
implies that the warts of NAT traversal will not have to be hardcoded
into applications. Second, the solution provides a global IPv6 address,
which means that we can use IPSEC to alleviate the potential lack of
security caused by the middleboxes. Finally, the solution has a clear
sunset strategy.

5) Possible instabilities caused by optimisations

The fifth point, the use of various optimizations, is also a consequence
of a design goal, i.e. to minimize cost of running a Teredo server. The
design incorporates hypotheses about NAT behavior that are based on a
study of the existing NAT market. The hypotheses are now clearly
documented in the new draft.

Erik Nordmark made a specific point on the stability of the timer
interval measurement algorithm, showing that the documented algorithm
may be in many cases too optimistic, and thus fragile; this has been
corrected by not allowing teredo clients to "discover" timers that are
shorter than 2 minutes.

6) Security issues

The security consideration section of the previous draft was somewhat
terse. The new draft provides a detailed analysis of the main threats
against the service, as well as the mitigating factors. The threats are
grouped in three categories: security risks of directly connecting a
node to the IPv6 Internet, potential attacks aiming at denying the
Teredo service to a Teredo client, and denial of service attacks against
non-Teredo
participating nodes that would be enabled by the Teredo architecture.

A very brief response to these threats is as follow. For the direct
connection threats, the correction is obviously host security, which can
be enabled by "host firewalls" products, and which can be bolstered by
the use of IPSEC. For the attacks against the service, the best defense
is the service simplicity, which allows for the deployment of a highly
redundant architecture. For the attacks against third parties, the main
mitigating factor is the "regularity" of the Teredo traffic, which
contains highly specific patterns such as the Teredo IPv4 anycast
address, the Teredo UDP port, or the Teredo IPv6 prefix. In case of
attacks, these patterns can be used to quickly install filters and
remove the offending traffic. The long response should indeed be read
from the new draft.

-- Christian Huitema