Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
draft-huitema-v6ops-teredo-05

From: Thomas Narten <narten@cichlid.raleigh.ibm.com>
To: Margaret Wasserman <margaret@thingmagic.com>
cc: "Christian Huitema" <huitema@windows.microsoft.com>
Date: Tue, 15 Feb 2005 10:03:30 -0500
Subject: Re: draft-huitema-v6ops-teredo-04.txt 

> Thomas had raised on issues with this document a while back, and he 
> still isn't showing any position in the tracker.  I've been waiting 
> to hear from him about whether he wants those issue to be resolved 
> before the document is published.

yep, I've been rather delinquent. Looking through my notes, my
comments are mostly editorial.

But there are two substantative issues.

I wonder if it would be worth adding the overview I put together. If
one existed in the past, it's a shame it got removed. All protocol
documents really benefit from a summary/overview section at the
start. This document is hard to read without an overview (other IESG
reviewers said the same).

It would be good to make it _very_ explicit exactly what packets a
toredo server is supposed to relay, and which it is not. That is, for
security purposes, servers should drop all packets other than those
that are explicitely allowed. The document is not clear at all clear
about this. A single paragraph/table would be sufficient to make this
point clear.

ICMP echo requests. I worry that using ICMP echo requests/replies for
signalling will lead to problems. I.e., using echos for a purpose
other than originally intended. The main problem I see is that there
are sites that filter all ICMP for (arguably) bogus security
reasons. Or, they filter ICMP echos when dealing with DDOS attacks and
such. I'm aware of two such instances today. It appears that my
employer filters ICMP echo requests/replies at its border. This didn't
used to be the case, but has been in effect for many months now. Also,
I regularly use accounts within cs.duke.edu. But they do funny things
with ICMP. Some of the internal hosts do not appear to respond to ICMP
echos from outside the site. E.g., try cassatt.cs.duke.edu. You can
ssh into that machine, so it is connected.

Since teredo relies in ICMP for setup, this would seem to be a
problem. Not sure how easy to fix this or if it is fixable. Would it
make sense to not use ICMP echos, but to allocate an alternative Type
value? This at least would make it possible for firewalls to filter
teredo setup messages separately from ICMP (the concern is folks
filtering ICMP echo without having a clue on the impact that will have
on teredo). Another possibility is to use a different code value for
teredo echos, so that firewalls can filter them differntly, but I
suspect that won't be sufficient and I am not sure whether firewalls
understand this degree of granualarity.

Specific comments:

> 2.10 Teredo server address
>    
>    The IPv4 address of the Teredo server selected by a particular user.

s/user/Teredo client/ (users surely don't select servers...)


> 2.13 Teredo node identifier
>    
>    A 64 bit identifier that contains the UDP port and IPv4 address at
>    which a client can be joined through the Teredo service, as well as
>    a flag indicating the type of NAT through which the client accesses
>    the IPv4 Internet.

what does "joined" mean? Do you just mean "reached"?

> 2.16 Teredo secondary port
>    
>    A UDP port used to determine the appropriate value of the refresh
>    interval, but not used to carry any Teredo traffic.

Source port on the client? dest port? Both?

>    Packet transmission only takes places after an exchange of "bubbles"
>    between the parties. This exchange would often fail for clients
>    behind symmetric NAT, because their peer cannot predict the UDP port
>    number that the NAT expect.

what kind of packet transmission? You mean arbitrary IPv6 to IPv6
communication between the client and some random IPv6 host?

>    address. We had to include an "obfuscation" procedure in TCP to
>    avoid this behavior.

Who is "we" and what does this document recommend implementors do? If
there is no action, remove sentence...

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

what kind of servers? I assume teredo servers. Might be good to go
through the document and s/server/teredo server/ throughout for
clarity.

> 3.3.2 Minimal support cost
>    
>    The service requires the support of servers and relays. In order to
>    facilitate the deployment of these servers, the Teredo procedures
>    are designed to minimize the fraction of traffic that has to be
>    routed through the servers.

"routed through the servers"? earlier I thought it was a requirement
that:

   necessary. To achieve this objective, we require only that servers
   enable the packet exchange between clients, but we don't require
   servers to carry the actual data packets: these packets will have to
   be exchanged directly between the Teredo clients, or through a
   destination-selected relay for exchanges between Teredo clients and
   other IPv6 clients.
   
>    Teredo clients have to discover the relay that is closest to each
>    native IPv6 peer. In order to prevent spoofing, the Teredo clients
>    perform a relay discovery procedure by sending an ICMP echo request
>    to the native host, through the Teredo server. The payload of the
>    echo request contains a large random number. The echo reply is
>    forwarded by the relay closest to the native or 6to4 peer, enabling
>    the Teredo client to discover this relay. In order to prevent
>    spoofing, the Teredo client verifies that the payload of the echo
>    reply contains the proper random number.

To be sure I understand (and to clarify):

The above needs to be done whenever one initiates communication with a
new destination? (please say so).

What does "through the teredo server"  mean? What exactly does the
server send to the client (i.e, what addresses are used...)

>    The echo reply is
>    forwarded by the relay closest to the native or 6to4 peer, enabling
>    the Teredo client to discover this relay. 

How does it discover the relay? what info is in the forwarded echo
reply that allows it to do so?

>    In this format, both the "mapped UDP port" and "mapped IPv4 address"
>    of the client are obfuscated. Each bit in the address and port
>    number is reversed; this can be done by an exclusive OR of the 16-
>    bit port number with the hexadecimal value 0xFFFF, and an exclusive
>    OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF.

why? what purpose does this server?

>    - Flags: a set of 16 bits that document type of address and NAT.

I wonder about this. Whether one is behind a certain type  of NAT is a
relative term. What this bit says is what type of nat is between the
client and server. The type of nat between the client and some random
desitination may be different (when multiple nats  are present). Is
this an issue? I.e., is this flag really to indicate the type of nat
relative to the server, or is this supposed to be a global statement
that random destinations take advantage of?

>    The Teredo server is designed to be stateless. It waits for Teredo
>    requests and for IPv6 packets on the Teredo UDP port; it processes
>    the requests by sending a response to the appropriate address and
>    port; it forwards Teredo IPv6 packets to the appropriate IPv4
>    address and UDP port.

for the last sentence, can you say specifically what kind of IPv6
packet a server forwards, since you repeatedly say that data packets
are not?

>    When relaying packets received from third parties, the server may
>    insert an origin indication in the first bytes of the UDP payload:

here is that generic "relaying" text again...

>    When exchanging Router Solicitation and Router Advertisement
>    messages between a client and its server, the packets may include an
>    authentication parameter:
> 

Huh? servers are "routers?

>    Authentication and origin indication encapsulations may sometimes be
>    combined, for example in the RA responses sent by the server. In
>    this case, the authentication encapsulation MUST be the first
>    element in the UDP payload:

Huh? server relays RAs? ???

>    Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of
>    the encapsulating IPv4 header.

Are you really saying "should not perform PMTU discovery"? If so,
better to just say that.

>    A Teredo client expects to exchange IPv6 packets through an UDP

s/an UDP/a UDP/ (occurs more in at least one other place)

>    A Teredo client expects to exchange IPv6 packets through an UDP
>    port, the Teredo service port. To avoid problems when operating
>    behind a "port conserving" NAT, different clients operating behind
>    the same NAT should use different service port numbers. This can be

say "different service source port numbers"?

>    When the client wants to send a packet to an IPv6 node on the IPv6
>    Internet, it should check whether a valid peer entry already exists
>    for the IPv6 address of the destination. If this is not the case,
>    the client will pick a random number (a nonce) and format an ICMPv6

Isn't the above only if the destination is teredo?

>    By default, the routing functions of the Teredo server are limited.
>    Teredo servers are expected to relay Teredo bubbles and ICMPv6
>    messages, but they are not expected to relay other types of IPv6
>    packets. Operators may however decide to combine the functions of

All types of ICMP messages?

>    If the destination address is not a Teredo IPv6 address the packet
>    should be relayed to the IPv6 Internet using regular IPv6 routing.

This seems like asking for trouble. The teredo server should not be
receiving such packets. Why forward them? By doing so, one increases
server load and prevents broken clients from getting fixed.

>    If the address is valid, the Teredo server encapsulates the IPv6
>    packet in a new UDP datagram, in which the following parameters are
>    set:

shouldn't one also verify that the packet is a valid bubble (i.e.,
icmpv6 echo?), and nothing else?

>    IPv6 packets bound to Teredo clients. Teredo relays should be able
>    to receive packets sent over IPv4 and UDP by Teredo clients; they
>    may apply filtering rules, e.g. only accept packets from Teredo
>    clients if they have previously sent traffic to these Teredo
>    clients.

should? Seems like a must, since relays may send packets to arbitrary
servers.

>    bubble, up to three times. If there relay fails to receive a bubble

s/there/the/ ?

>    In cases 2 and 3, the Teredo relay should create a peer entry for
>    the IPv6 address; the entry status is marked as trusted in case 2
>    (cone NAT), not trusted in case 3. In case 3, if the Teredo relay
>    happens to be located behind a non-cone NAT, it should also send a
>    bubble directly to the mapped IPv4 address and mapped port number of
>    the Teredo destination; this will "open the path" for the return
>    bubble from the Teredo client.

I don't believe the above is true. see previous comments about
relative view of type of nat.

NOt accurate to call teredo servers "stateless".


Section 5.2:

read up to security considerations

>    Before sending any packets, the client must perform the Teredo
>    qualification procedure, which determines the Teredo connectivity
>    status, the mapped address and port number, and the Teredo IPv6
>    prefix; it should then perform the cone NAT determination procedure,
>    which determines the cone NAT status and may alter the value of the
>    prefix. If the qualification is successful, the client may use the
>    Teredo service port to transmit and receive IPv6 packets, according
>    to the transmission and reception procedures. These procedures use
>    the "list of recent peers". For each peer, the list contains:

is this just for Teredo destinations, or for all destination?


>    - The status of the mapped address, i.e. trusted or not,

trusted? isn't "verified" or "current" more accurate?

>    If the client has received an RA with the "Cone" bit in the IPv6
>    destination address set to 1, it is behind a cone NAT and is fully
>    qualified. If the RA is received with the Cone bit set to 0, the
>    client does not know whether the local NAT is restricted or
>    symmetric. The client selects a secondary IPv4 server address, and
>    repeats the procedure, the cone bit remaining to the value zero. If
>    the client does not receive a response, it detects that the service
>    is not usable. If the client receives a response, it compares the
>    mapped address and mapped port in this second response to the first
>    received values. If the values are different, the client detects a
>    symmetric NAT: it cannot use the Teredo service. If the values are
>    the same, the client detects a port-restricted or restricted cone
>    NAT: the client is qualified to use the service. (Teredo operates

Where does this secondary address come from? Is this just the
secondary port? Also, later, this is described as an optional
procedure. Is it optional for the client? Is it optional (to
implement?) for the server?

Section 5.3: be more specific about what a server forwards and does
not. There should be explicit tests to prevent forwarding of traffic
that is not appropriate. E.g., what about echo responses?