Subject: (ngtrans) Teredo comment

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 25 Sep 2002 17:45:02 -0700

Hello,

Section 4.1.1 of 'draft-ietf-ngtrans-shipworm-08.txt' defines the
following address format:

>   +-------------+-------------+-------+------+-------------+
>   | Prefix      | Server IPv4 | Flags | Port | Client IPv4 |
>   +-------------+-------------+-------+------+-------------+
> 
> - Prefix: the 32 bit Teredo service prefix.
> - Server IPv4: the IPv4 address of a Teredo server.
> - Flags: a set of 16 bits that document type of address and NAT.
> - Port: the obfuscated "mapped UDP port" of the Teredo service at
> the client
> - Client IPv4: the obfuscated "mapped IPv4 address" of a client

Additionally, the "Flags" field is defined as follows:

>           0       0 0       1
>          |0       7 8       5
>          +----+----+----+----+
>          |Czzz|zzUG|zzzz|zzzz|
>          +----+----+----+----+

Where, the 'z' bits are defined as "must be zero".

I am of the opinion that this format is unnecessarily wasteful in terms
of "hard-coded" bits that could potentially provide beneficial use. In
particular:

   1) I see no reason why the Teredo service prefix needs to be 32 bits;
      I'm thinking that as few as 20 bits is sufficient (24 bits at most)

   2) The 'z's in bits 8 - 15 of the Flags field are unnecessarily
      wasted and could potentially be used for other purposes. (The 'z's
      in bits 0 - 7 could also be reclaimed, but this would eliminate the
      nice advantage of being able to do "pretty-printing")

This would give rise to a slightly modified address format as follows:

        (20)   (12)       (32)       (8)     (8)   (16)       (32)
    +--------+------+-------------+-------+------+------+-------------+
    | Prefix | RSVD | Server IPv4 | Flags | RSVD | Port | Client IPv4 |
    +--------+------+-------------+-------+------+------+-------------+

yeilding (up to) 20 "RSVD" bits that can potentially serve some useful
purpose. I don't have a particular purpose in mind at this moment, but
I believe it possible that one or more uses may identify themselves in
the near future.

Fred
[email-masked]

P.S. See also my previous comment regarding "obfuscated" address format.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 25 Sep 2002 22:33:09 -0700

>      I'm thinking that as few as 20 bits is sufficient (24 bits at most)
 
We could indeed just as well use a /16 prefix, and get 16 extra bits.
But the real question is, what good would that do? In practice,
there are only two interesting design points: a /64 per teredo client,
or a /128 per client.
 
We cannot get a /64 without relying on an anycast address, which has
been ruled out for operational and security reasons. In the absence of
anycast, we need 32 bits to encode the server IP address. In consequence,
it makes sense to just use a /32 prefix, and reserve a minimal fraction
of the IPv6 address space.

>      nice advantage of being able to do "pretty-printing")

The question here is, what other purpose. Specifying a must-be-zero has
the advantage of simplifying "neighbor" cache management, since there
is only one /128 per UDP port + IP address; you end up using the same
neighbor cache management algorithm as neighbor discovery. Also, you
avoid potential confusion, etc.
 
> P.S. See also my previous comment regarding "obfuscated" address format.

Yes, I saw it. But you must realize that the first goal of Teredo is, to work
with the existing NAT, those that are already deployed. I don't want to 
tie Teredo's success to modifying the existing NAT; if we could do that,
we could just as well ask them to support 6to4.
 
-- Christian Huitema

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 26 Sep 2002 12:50:52 -0700

Christian,

 > I certainly agree that these NATs are broken. However, I don't believe
 > that we can realistically hope to have them discarded and replaced
 > overnight. It is better to have a simple mitigation, obfuscate the
 > address, than to have to answer customer calls.

You have avoided addressing the main point of my earlier message:

+ Any piece of equipment that blindly replaces values in the application
+ protocol data just because they match an IP address or port number could
+ potentially do considerable harm to data integrity. Such a NAT box could:
+
+ - alter digital photographs
+ - invalidate business transactions
+ - change the amount of money in my bank account
+ - name your worst-case scenario
+
+ Am I reading this correctly? If so, it would seem that address obfuscation
+ would serve to keep such broken NAT boxes operating when they should instead
+ be identified and dismantled.

The shipworm-08 document asserts that the sole reason address obfuscation is
done is to support NATs that do what I am describing above. Do you really
mean to suggest that such NATs should be supported by Teredo? Do you really
think it a responsible engineering action to go out of ones way (vis-a-vis
address obfuscation) in order to support something that should be thrown
in the garbage?

Fred
[email-masked]

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 26 Sep 2002 13:53:03 -0700

> The shipworm-08 document asserts that the sole reason address
obfuscation
> is

It depends what you mean by "get out one's way". If doing a simple XOR
enables me to support 20% more customers, I believe I have a reasonable
trade-off. Since doing that does not cost me anything significant, I
don't see what I loose. Remember the "be tolerant" part of the
robustness principle?

-- Christian Huitema