Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-shipworm-07.txt

From: Pekka Savola <[email-masked]>
Date: Sat, 7 Sep 2002 23:26:06 +0300 (EEST)

Hi,

A few comments on the first part of the draft (up to sect 4.1.3).

Generic:

==> It would be nice to have proper indentation ...

==> The mechanism has, unfortunately, grown extremely complex :-(

2.2     Teredo Client

A node that has some access to the IPv4 Internet and that wants to
gain access to the IPv6 Internet. This node may behave either as an 
IPv6 host or as an IPv6 router.

==> 'or as an IPv6 router' part has lost it's meaning in the current 
drafts (see addressing change in 4.1.1).

2.7     Teredo bubble

A packet sent over UDP by a Teredo client in order to trigger a side
effect in the NAT.

==> I think "side effect" should be expanded a bit (if it fits in 1-3 
lines that is).

2.8     Teredo service port

The port through which the Teredo client sends Teredo packets. This
port is attached to one of the client's IPv4 interfaces. The IPv4
address may or may not be globally routable, as the client may be
located behind one or several NAT.

==> UDP ports are not attached to interfaces.

3.2.4   Automatic sunset

[...] These systems will start receiving the "router
advertisements"; they will notice that they have IPv6 connectivity,
and will stop using Teredo.

==> I don't believe this ISATAP'isque automatic sunset feature has been 
specified (at least not in 4.x)?

4.1.1   Encoding of Teredo addresses

- XX: a set of (128-L) bits chosen by the client.

==> explain L or reword; looks like (48-length of Teredo service prefix)

          0	  0 0       1
	 |0	  7 8       5
	 +----+----+----+----+
	 |xrcc|ccug|cccc|cccc|
	 +----+----+----+----+

In this format:

-	The bits "ug" should be set to the value "00", indicating a non
global unicast identifier;
-	The bit "d" (determination) should be set to 0 or 1; these values
determine different server behavior during the qualification
procedure, as specified in section 4.1.3;
[...]

==> in the picture, there is no 'd', so I assume 'x' was meant to be 'd'.

4.1.2   Obtaining an address

The packet will have 
the following format:

  +------+-----+-------------------+-------------+
  | IPv4 | UDP | Origin indication | IPv6 RA	 |
  +------+-----+-------------------+-------------+

==> there's some text below, is it supposed to form 'Origin indication' in 
some way?

will document the key identifier in a parameter of the router
solicitation message (by convention, we will use the SLLA option);
the server will insert in the reply one way hash of the client's

==> 'SLLA option' ?

Upon reception of this prefix, the client composes a Teredo address,
which in our example will be:

        PREF:0102:0304::F6FF:FFFE:EFFF

==> You forgot 'XX' (defaults to zero, probably).

The client learns the relevant prefix by sending first an RS from a
source address in which the "d" bit is set to 1. If it receives the
RS sent by the server from a secondary IPv4 address, the client is  
behind a cone NAT and can use a null-based prefix. If after time-out
and retransmission it has not received an RS, the client sets the
"d" bit in its local address to "1", and repeats the procedure; it
will learn a server based prefix.

==> shouldn't the last "1" be "0" ?

(at this point I had to stop reading.)

Purely editorial:

3.1.2   Lifetime of UDP mappings

that want to maintain a mapping open in the NAT will have to send     

s/want/wants/

the mappings will be release when the connection is released, i.e.

s/release/released/

3.3.5   Compatibility with ingress filtering

malfeasant hackers, notably to cover their tracks during denial of

==> 'malfeasant' is not the best adjective to use here.

The Teredo service requires the cooperation of three kinds of
actors: Teredo clients, who want to use IPv6 despite being located
behind a NAT, Teredo servers who will facilitate the service, [...]

==> s/facilitate/provide/ ?

"cone NAT determination".

                                          .-----------------------
                                 	  |  Private network
		.--.	  _		.-----.     .----------.
               (IPv4)  src=9.0.0.1:4096 | NAT |     | Teredo   |

==> there is an extra '_' above src=

advertisements in response to the client's solicitation: if will
send RA advertising a prefix including the server address (e.g. 
PREF:0102:0304/L)

==> s/if/it/
==> s|0304|0304::|

On Thu, 15 Aug 2002, Christian Huitema wrote:

> 
> As mentioned in the announcement, I just published a new version of the
> Teredo draft. This is a very thorough revision, which is meant to
> address and fix the comments from the IESG reviewers, security issues
> raised by other reviewers, and scalability issues that we discovered
> through modeling, i.e. that traffic through the server exploded as the
> proportion of non-Teredo hosts in the Internet increased. The most
> visible changes are the following:
> 
> 1) The anycast address is gone. This was a major contention point in the
> operation area, and also proved to be a major deployment blocker.
> Instead, we change the address format to include four components: the
> Teredo service prefix, the IPv4 address of the server selected by the
> Teredo host, the mapped IPv4 address of the Teredo host, and the mapped
> port. If peers have "established contact" through the bubble mechanism,
> they can send packets directly to the mapped address or mapped port; if
> they have not, they can contact the host through the Teredo server,
> which will relay.
> 
> 2) We include a cone NAT optimization, as it turns out that a very large
> fraction of the residential gateways are cone NAT. The server helps the
> host finding out whether it is behind a cone NAT. In that case, the
> "server IPv4 address" component of the Teredo IPv6 address is replaced
> by a null address. Peers who want to send packet to a host behind a cone
> NAT simply post the packet to the mapped address or mapped port.
> 
> 3) We specify that the server will never carry any actual traffic, i.e.
> will just carry the bubbles used to "establish contact". The actual
> traffic will always flow directly between the peers; if connecting
> between a Teredo host and an IPv6 peer, the traffic will flow through
> the Teredo relay nearest to the peer. This has three kinds of benefits:
> it resolves the server scaling issues; it resolves privacy concerns
> raised by the possibility for the server to observe the hosts' traffic;
> and it helps resolving security concerns that servers could be harnessed
> to enable DOS attacks. A negative side effect of this decision is that
> we cannot use Teredo behind a "symmetric NAT".
> 
> 4) We add an MD5 signature to the address mapping exchanges between
> client and server, preventing server spoofing and thwarting some DOS and
> man-in-the-middle attacks against the client. The scheme is the same as
> proposed for STUN. The presence of the signature would actually allow
> the same code to be used for Teredo and for an UDP-based tunnel broker;
> this part of the design is however only sketched in the draft.
> 
> In short, I believe that the new draft resolves the operational and
> security concerns associated with the initial design. The draft comes
> with an extensive security section, including a detailed threats
> analysis.
> 
> -- Christian Huitema
> 
> 
> 
>  
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords