Subject: (ngtrans) Shipworm-05 comments

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Mar 2002 15:33:55 +0200 (EET)

Hello,

I finally got around to reading the latest Teredo draft.. somehow the fact 
that the size had doubled from 60K to 120K had made me push it off :-)

Anyway.. main comments first, purely editorial ones at the end.

- I'm not sure how you're supposed to use the new variable length prefix.  
If plen > 16, this would kill stateless autoconfig at least.

- It wasn't clear to me, at least from the above, how Shipworm is
positioned: is it meant for a stand-alone node (like "6to4 host that is
also a 6to4 router"), or can it also be used for a subnet router?  If not,
this would decrease the usability somewhat.  Also see above about
stateless autoconfig for subnet router case.

 - I think we also need a section on what happens if the assumptions 
about NAT's don't hold about Teredo-Teredo shortcuts (like 4.1.4)

 - Has the behaviour described in 4.1.4 been tested in practise?  I'm 
mostly curious about the more restrictive (port restrict, symmetric) 
cases.  I'm having hard time visualizing how the bubbles' ports are being 
mapped in different NAT's.

 - not sure if the refresh intervsal determination procedure makes sense 
or just adds complexity: it can be done to raise the timer from 30 to 
120s.. not a huge win..

 - I'm very worried about different NAT types.. I'd really like to get
more concrete data on the behaviour.

==8<==

1	Introduction

A possible way to solve the problem is to rely on a set of "tunnel 
brokers." There are however limits to any solution that is based on
such brokers: the quality of service is not very good, since the   
traffic follows a "dog leg" route from the source to the broker and
then the destination;

==> s/is not very good/may not be very good/ : if e.g. the ISP does this, 
the quality can be quite ok.

2.9	Teredo UDP port

The UDP port number at which Teredo Servers are waiting for packets.
This port is also used by Teredo relays to send Teredo packets. The 
value of this port is PPPP. (TBD IANA)

==> This is also used for e.g. Local Discovery I think?

2.11	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.

==> One cannot attach ports to an interface, not even all IPv4 addresses 
of an interface (without doing it one-by-one).

==> Does the latter conflict partially with the assumption that Shipworm 
is only used from behind a NAT?

2.14	Teredo IPv6 address

A Teredo IPv6 address obtained by combining a Teredo IPv6 client
prefix and a node identifier.

==> not sure what is meant by node identifier here.  Some form of the last 
64 bits, yes, but not necessarily e.g. EUI64 or anything automatic though, 
especially if a long teredo prefix is used.

2.18	Random link-local address

An IPv6 link-local address chosen at random, as specified in section
5.1.6.

==> I'd suggest adding a definition of Server link-local address, from 
5.1.5.

3.2.1   When to use Teredo?

Nodes that want to connect to the IPv6
Internet SHOULD only use the Teredo service as a "last resort"
option: they SHOULD prefer using direct IPv6 connectivity if it is
locally available or if it is provided by a 6to4 router co-located 
with the local NAT, and they SHOULD prefer using the less onerous 
"6to4" encapsulation if they can use a global IPv4 address.

==> I think "direct connectivity" and "6to4 with the local NAT" cases are 
from the perspective of a potential Teredo client basically the same.

3.2.4   Automatic sunset

Teredo is meant as a short-term solution to the specific problem of 
providing IPv6 service to nodes located behind a NAT. The problem is
expected to be resolved over time by transforming the "IPv4 NAT"
into an "IPv6 router". This can be done in one of two ways:  
upgrading the NAT to provide 6to4 functions, or upgrading the
Internet connection used by the NAT to a native IPv6 service, and
then adding IPv6 router functionality in the NAT. In either case,

==> there are more than two ways, e.g. static tunnels.  This elaboration 
seems to be partially out of scope.

3.3.5   Compatibility with ingress filtering

A more complex filtering may be performed at the boundary between
two "non stub" networks, e.g. at the peering points between two
providers. Contrary to "stub" interfaces, routing at these points is
not symmetric.

==> s/not symmetric/not necessarily symmetric/ (often/symmetric/...) ?

4.1     Model of operation

The primary role of the servers is to enable the NAT traversal. The
service is designed in such a way that, when NAT traversal is 
guaranteed, packets can flow on a direct path between source and
destination, without necessarily involving a relay by a Teredo
server.

==> direct won't work with a few types of NAT's.. perhaps that should be 
mentioned here.

The router sends the router advertisement back over UDP to the
mapped IPv4 address 9.0.0.1:4096. The IPv4 packet is received by the
NAT, which has presumably remembered the mapping between this
external address and the private address and port pair,
10.0.0.2:1234; the NAT forwards the packet to the Teredo client.

==> this doesn't discuss random/server link-layer address, but perhaps 
it's unnecessary for the "overview of the operation" section.

4.1.4   Exchanges between two Teredo nodes

The following diagram shows two Teredo clients, A and B, connected
through the NATs N1 and N2. The exchanges will use the Teredo server
S1, close to A, and S2, close to B. We will assume that the NAT N2
is a "restricted cone" or "port restricted cone" NAT;

==> cone NAT would probably also be ok :-)

4.2.1   Deployment in the Global Teredo Network

Teredo Network servers and relays SHOULD only be deployed in an
autonomous system if the autonomous system is ready to announce a
route to the Global Teredo IPV4 anycast prefix to all its peers.

==> I see zero reason for this requirement.

5.1.3   Maximum Transmission Unit

Teredo implementations SHOULD NOT set the "do not fragment" (DF) bit
of the encapsulating IPv4 header.

==> should a short discussion be helpful here?

5.1.5   Server link local address

The IPv4 address is a specific unicast address of an interface
through at which the server is ready to receive Teredo packets, at
the specified port.

==> note: IPv4 anycast addresses are just special IPv4 _unicast_
addresses.

5.2.1   Qualification procedure

If the response is a valid router advertisement, from a valid Teredo
source address,

==> note: isn't this source the server link-local address?

5.3.1   Processing of Teredo IPv6 packets

Upon reception of a packet on the Teredo port, the Teredo server
will first check that the UDP payload contains a valid IPv6 packet;
if this is not the case, the packet will be silently discarded.

[...]

3)	If the UDP content is not a well formed IPv6 packet, the packet
MUST be silently discarded.

==> there seems to be some duplication in this text.

5.4.1   Difference between Teredo Relays and Teredo Servers

The requirement on relays is that they be able to send packets from
the Teredo IPv4 Anycast address, and that they advertise
reachability of the Teredo IPv6 service prefix. The requirement on
servers is that they have an unencumbered IPv4 connectivity, that
they can receive packet sent to the Teredo IPv4 Anycast address,
that they process these packets according to the Teredo server
specification, that they can send packets from the Teredo IPv4
Anycast address, and that they can forward packets to IPv6.

==> the last line: strictly speaking, that's true; more generally 
speaking, relays also forward IPv6 packets.

6.2     Could we make do with fewer bubbles?

The first client uses the private address and port 10.0.0.2:1234,
which is mapped to 9.0.0.1:4096 by the NAT; the second client uses 
10.0.0.3:1234, mapped to 9.0.0.1:4097. If the first client tries to
send a direct packet to the second client, that packet will be    
routed to the address 9.0.0.1:4097, i.e. to the external IP address
of the local NAT. What happens next is everybody's guess: some NAT
may do the right thing, some may drop the packet.

==> I'm not 100% sure what the problem here is.  Firewall rules that 
prevent "internal traffic" from going throught he upstream interface?  
Could this be avoided with local discovery?

6.8     What about anycast routing and ingress filtering?

In practice, the topological correctness is only achieved if the
servers and relays are ready to receive packets from any destination
to which they also send packets. Since the Teredo clients may send  
packet everywhere in the Internet, the set of destinations include  
the whole Internet. In order to avoid black-hole effects due to     
ingress filtering, the network administrator who establishes Teredo 
servers for the global Teredo network must be ready to advertise the
reachability of the Teredo IPv4 anycast address to the whole IPv4   
Internet. This will be in many cases a reasonable trade-off, since  
in practice the local servers will only receive traffic from the    
closest Teredo clients; the extra amount of traffic from non-local  
sources will be compensated by the increased efficiency of direct   
Teredo routing for the local clients, which will reduce the amount  
of traffic processed by the servers. However, we cannot impose this 
trade-off to all network operators all the time.

A network operator who is not ready to announce the service to the
whole Internet has the option of operating a specific Teredo
networks, using its own set of topologically correct addresses and
prefixes. Some amount of reliability and efficiency can still be  
achieved if each specific network is served by an adequate number of
servers and relays.

==> not so: if RPF is enabled and and you have a Shipworm server in your 
network, the end result always seems to be disastrous no matter what you 
do.  The problem is that packets from the other servers use the same 
anycast address as source as you're using in your own server, and packets 
are thus dropped at the border.  Advertising to the Internet etc. won't 
help.

This requires careful thought...

7       Further work: tunnel service

==> in the case of symmetric NAT's, this seems like a good option.

8.1     Opening a hole in the NAT

The very purpose of the Teredo service is to make a machine
reachable through IPv6. By definition, the machine using the service
will give up whatever "firewall" service was available in the NAT
box; all services declared locally will become potential target of
attacks from the entire IPv6 Internet. This may sound scary, but   
there are three mitigating factors.

==> also, in the beginning _when teredo is to be used_, not all IPv4 
services are often ported to IPv6, which makes the risk smaller in some 
cases.

The first mitigating factor is the possibility to restrict some
services to only accept traffic from one of the limited address     
scopes defined in IPv6, e.g. link-local or site-local. There is no  
support for such scopes in Teredo, 

==> depending what you mean by 'support', this can be true or false.  
Teredo uses link-local RS/RA, which is potentially attackable.

8.2.3   Denial of service by exceeding the number of peers

A Teredo client manages a cache of recently used peers, which makes
it stateful. It is possible to mount an attack against the client by
provoking it to respond to packets that appear to come from a large 
number of Teredo peers, thus trashing the cache and effectively
denying the use of direct communication between peers. The effect
will only last as long as the attack is sustained. During the
attack, the client will still be able to send packets through the
Teredo servers.

==> can be mitigated by intelligent cache management techniques, I think 
(perhaps something like waiting for the node to send something to the node 
first via server?)

8.2.4   Attacks against the local discovery procedure

There is a possible denial of service attack against the local peer
discovery procedure, if attackers can manage to send spoofed local 
discovery bubbles to a Teredo client. The checks described in
section 5.2.7 mitigate this attack. Clients who are more interested
in security than in performance may decide to disable the local
discovery procedure.

==> this opens a big, big, big local security problem; traffic can be
hijacked quite easily.  If IPv6 address isn't verified, traffic outside of
the local network can also be hijacked.  Therefore I think that this 
mechanism should be disabled by default if IPv6 check isn't implemented.

==> note, similar to e.g. draft-kempf-netaccess-threats-00

8.3     Denial of service against non-Teredo nodes

==> the border between subsections seems to be shaky, e.g:

8.3.1   Laundering DOS attacks from IPv4 to IPv4

 The second  
way is to construct a Teredo IPv6 address using the Teredo prefix, 
the IPv4 of the target, an arbitrary UDP port, and an arbitrary node
identifier, and to then send packets bound to that address to the   
Teredo IPv4 anycast address; the packets will be routed to the
nearest Teredo relay, and forwarded from there to the target. 

==> this is either 1) s/relay/Server/, or 2) IPv6 -> 
IPv4 threat, deleting the discussion about IPv4 anycast.

==> additional note: if v4 source address (UDP, easy..) can be assumed to 
be spoofable (yes!), new range of attacks arise which haven't been covered 
in v4 -> v4 case.

The traffic reflected
by the Teredo servers meets this condition: it is clearly
recognizable, since it originates from the Teredo IPv4 anycast
address and from the Teredo UDP port; it can be filtered out safely
if the target itself is not a Teredo user.

==> I've said this before, but I'll say it again: might a restriction on 
the port numbers (e.g. non-privileged) at least mitigate some of these?  
Might break some NAT's though..

8.3.3   DOS attacks from IPv6 to IPv4

A special case occurs if the attack is directed to an echo service.
The service will echo the packets. Since the echo service sees the
request coming from the Teredo IPv4 anycast address, the echo  
replies will be sent to the nearest Teredo server. According to the 
rules specified in 5.3.1, these packets will be discarded by the
Teredo server. This is not an efficient attack against the Teredo
servers - establishing a legitimate session with an actual Teredo
host would create more traffic.

==> this is not efficient, I agree, but the source address has already 
been lost.

==> also, this is a more generic problem with the echo service, not much 
teredo-specific here.

9	IANA Considerations

This memo documents a request to IANA to allocate a Teredo IPv6
service prefix, a Teredo IPv4 anycast prefix, a Teredo IPv4 anycast
address and a Teredo UDP port.

==> update! _Global_ addresses/prefixes.  Which prefixlen should be given 
to service prefix?  Should UDP port be privileged/non-privileged?

Appendix A: Experimental client and server parameterization

==> I don't really understand the record, but I don't know if that's 
necessary..

Purely editorial:

==> quite a few of s/link local/link-local/ [???]

A possible way to solve the problem is to rely on a set of "tunnel 
brokers."

==> s/."/".//

The specification is organized as follow.

==> s/follow/follows//

Section 6 contains
the format of the messages and the specification of the protocol.

==> s/6/5/

Section 7 
present the guideline from some further work, that would be
complementary to the current approach

==> s/present/presents/, s/work,/work//

2.8	Teredo network

A set of clients, servers and relays that are configured to use the
same Teredo IPv6 service prefix and the same Teredo IPv4 anycast   
address.

The Global Teredo Network is composed of the set of Clients, Servers
and Relays that use the Global Teredo IPv6 service [...]

==> move the latter part to a new 2.8.1 as with 2.6.1 and 2.7.1?

2.9	Teredo UDP port

The UDP port number at which Teredo Servers are waiting for packets.
This port is also used by Teredo relays to send Teredo packets. The 
value of this port is PPPP. (TBD IANA)

==> s/used/used as a source port/ (clarification)

2.10	Teredo bubble

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

==> to where? (clarification)

2.11	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.

==> "through which" may not be the clearest way to say packets are sourced 
from a port.

2.12	Teredo mapped address and Teredo mapped port

A global IPv4 address and a UDP port that results from the
translation by one or several NAT of the IPv4 address and UDP port
of a client's Teredo service port. The client learns these values 
through the Teredo protocol described in this memo.

==> The first is a really long sentence, I'd suggest splitting it up a 
bit.

2.16	Teredo Refresh Interval

The interval during which a Teredo IPv6 Address is expected to
remain valid in the absence of "refresh" traffic. For a client
located behind a NAT, the interval depends on configuration   
parameters of the local NAT, or in fact of the combination of NATs
on the path to the Teredo server.

==> perhaps simplify 'the local NAT, or in fact [...]' ?

3       Design goals, requirements, and model of operation

The design of our solution is based on a set of hypotheses and

==> s/our/the/

3.1	Hypotheses about NAT behavior

NAT devices typically incorporate some support for UDP, in order to
enable users in the natted domain to use USP based applications.

==> s/USP/UDP/, s/natted/NATted/
==> this is extremely trivial.  I have never even heard of a NAT box which 
wouldn't support UDP.  Probably could be removed.

NAT will typically allocate a "mapping" when it sees an UDP packet  
coming through for which there is not yet an existing mapping. The  

==> "coming through" from which direction (outgoing).

3.1.1   Types of UDP mappings

3) Instead of keeping just a list of authorized hosts, some NAT
implementations keep a list of authorized host and port pairs. UDP
packets coming from remote addresses are rejected if the internal
host has not yet sent traffic to the outside host and port pair. The 
NATs are often called "port restricted cone NATs"

4) Finally, some NAT map the same internal address and port pair to 
different external address and port pairs, depending on the address
of the remote host. These NATs are usually called "symmetric NATs".

==> the difference wasn't 100% clear when reading this part of the draft, 
only the examples later showed this.  Suggest adding a sentence in 4) 
telling of the practical difference.

3.1.2   Lifetime of UDP mappings
on the specified port for a "lifetime" period. The Teredo client   
that want to maintain a mapping open in the NAT will have to send

==> s/that want/that wants/

In some cases, e.g. NATs that manage ISDN or dial-up connections,
the mappings will be release when the connection is released, i.e.
when no traffic is observed is observed on the connection for a   
period of a few minutes.

==> s/is observed is observed/is observed/

3.2     IPv6 provider of last resort

consequence is that we expect to see a point in time at which the
Teredo technology ceases to be used.

==> s/technology/Service/ ?

3.2.1   When to use Teredo?

Teredo is designed to robustly enable IPv6 traffic through NAT, and
the price of robustness is a reasonable amount of overhead, due to

==> s/,and the/. The/

3.2.1   When to use Teredo?

Nodes that want to connect to the IPv6 
Internet SHOULD only use the Teredo service as a "last resort"
option: they SHOULD prefer using direct IPv6 connectivity if it is
locally available or if it is provided by a 6to4 router co-located
with the local NAT, and they SHOULD prefer using the less onerous 
"6to4" encapsulation if they can use a global IPv4 address.

==> too long: especially the 6to4 part in the middle.

3.2.2   Autonomous deployment

In an IPv6 enabled network

==> IPv6-enabled ?

A  
design objective is to also configure the Teredo service
automatically, without requiring any configuration parameter.

==> s/parameter/parameters/ ?

3.2.3   Minimal load on servers

During the peak of the transition, there will be a requirement to
deploy a large number of servers throughout the Internet.

==> Worth clarifying we're talking about Teredo Servers, not just some 
"servers" ?

and they should also not be required to carry any more traffic than

==> s/should also not/shouldn't/

3.2.4   Automatic sunset

the former NAT can present itself as an IPv6 router to the system
behind it. These systems will start receiving the "router
advertisements"; they will notice that they have IPv6 connectivity,
and will stop using Teredo.

==> s/These systems/Hosts in this system/ ?

3.3.1   Robustness requirement

The Teredo service is designed primarily for robustness: packets are
carried over UDP in order to cross as many NAT implementations as   
possible.

==> the latter part is trivial as above.

3.3.4   Non-requirement of permanent addresses

Our design objective is that any node that has obtained a legitimate
IPv4 connection, even behind a NAT, can obtain a globally reachable 

==> s/Our/The/, s/connection/address/

3.3.5   Compatibility with ingress filtering

The simplest form of ingress filtering is perform at the interface
between a stub network

==> s/perform/performed/

4.1.1   Obtaining an address

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

==> kill the extra _ above src=

The Teredo receives the packet and notes the source address. It uses
it to construct a Teredo IPv6 client prefix:

==> s/the source/the IPv4 source/

- A's "natted" address and port are: 10.0.0.2:1234.
- A's mapped address and port are: 9.0.0.1:4096.
- A's IPv6 address has been set to PREF:0900:0001:1000::A
- The Teredo IPv4 anycast address and port are: t.t.t.t:p
- B's IPv6 address is: 2000::B

==> perhaps it would be best to use x.x.x.y:PPPP as defined in the 
terminology section?

==> better use something like 3ffe:ffff::B than 2000::B

4.1.3   Sending a packet from a regular IPv6 node to a Teredo node

The IPv6 packet is encapsulated by R in a
IPv4/UDP datagram, from source address and port t.t.t.t:p, to source
address and port 9.0.0.1:4096.

==> s/to source/to destination/

The packet is then forwarded in the natted domain, and received by
A. A discards the IPv4 and UDP header, and processes the IPv6
packet.

==> s/natted/NATted/ ?

==> 'A decapsulates the packet, discarding IPv4 and UDP header, and ...' ?
(many places where discarding straight out might not be the best wording)

4.1.4   Exchanges between two Teredo nodes

At the same time it sends the packet to B through the Teredo server,

==> s/it/A/

When B respond to A, the data packet is also sent through the Teredo
server S2, much like the first data packet. B, however, will also   

==> s/respond/responds/, s/,however, //

address (9.0.0.1:4096) and B, the bubble is accepted and the makes  
it way to A.

==> s/it way/its way/

At this point, A knows that it has received a direct packet from B.
A's next packet will be sent on the direct path, and will make it  
through N1 since a mapping has already been establish.

==> s/establish/established/

4.1.5   Exchanges two Teredo nodes on the same link

==> s/Exchanges/Exchanges between/

The following diagram shows two Teredo clients, A and B, connected
to the same link, which is itself connect to the Internet through 
the NATs N1. The exchanges will use the Teredo server S1. We are not
making any assumption about the NAT N1.

==> s/itself connect/itself connected/
==> s/assumption/assumptions/ ?

4.2	Deployment model

The model of operation makes a critical assumption, that all servers

==> s/,that/that/

4.2.1   Deployment in the Global Teredo Network

route to the Global Teredo IPV4 anycast prefix to all its peers.

route to the Global Teredo IPV6 prefix to all its peers.

==> s/IPV6/IPv6/, s/IPV4/IPv4/

5.1.4   Teredo bubble

rewritten the IPv4 source address and the UDP source port to the
Teredo map address and Teredo mapped port of the sender; the

==> s/map address/mapped address/

5.1.7   Teredo local discovery bubbles

- IPv6 destination: the all nodes on link multicast address  

==> is this the "formal" name?  not the shortest, at least.

5.2.1   Qualification procedure

When the interface is initialized, the system first performs the
"start action" by sending a Router Solicitation Message, as defined
in [RFC2461]. The client picks a random link local address and uses
it as the IPv6 source of the message; the IPv6 destination of the RS
is the all-routers multicast address; the packet will be sent over
UDP from the service port to the Teredo anycast address and Teredo
UDP port. The connectivity status moves then to "Starting".

==> IPv4 source address is not mentioned.

5.2.2   Packet reception

the client implements the local client discovery procedure described
in section 5.2.7, the client checks whether there is and entry

==> s/and/an/

5.2.5   Sending Teredo Bubbles

- If the client which implements the local discovery procedure it
SHOULD NOT send a bubble to a local peer;

==> s/which// ?

section 5.1.4. When transmitting the bubble, the client MUST update
the last transmission date and time to that peer, and must also
increment the number of transmitted bubbles.

==> MUST vs must?  

5.2.7   Optional local client discovery procedure

- The Teredo client is located behind a NAT which will

==> something missing there

5.3     Teredo Server specification

The Teredo server is designed to be stateless. The Teredo server   
waits for incoming UDP packets at the Teredo Relay Port. The
incoming packets may be sent to either the Teredo IPv4 Anycast    
Address, or to the specific unicast address of the Teredo Server. 

==> s/Teredo Relay Port/Teredo UDP Port/ ??

5.3.2   Processing of router solicitations

link local server address associated to the local interface. The

==> s/to/with/ ?

address and Teredo Port. Before sending the packet, the Teredo relay
MUST check that the IPv4 destination address is in the format of a  

==> s/Teredo Port/Teredo UDP Port/
==> s/relay/Server/ ?

6.1     Why do we have bubbles and lists of peers?

(apart from the situation shown in 5.2); direct transmission to a  

==> s/5.2/6.2/

6.2	Could we make do with fewer bubbles?

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

==> kill the extra ; there

8.2.2   Timing attack against the address mapping service  

There is a possible denial of service attack against the address  
mapping service, which we discuss in section 5.8.

==> s/5.8/6.6/

8.2.4   Attacks against the local discovery procedure

There is a possible denial of service attack against the local peer
discovery procedure, if attackers can manage to send spoofed local 
discovery bubbles to a Teredo client.

==> s/, if//

(Man, I feel dirty... shower time.)

-- 
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