Questions/comments about draft-krishnan-v6ops-teredo-update-10

[Fernando Gont <fernando@gont.com.ar>]

Folks,

I have a few comments/questions about the aforementioned I-D. I realize
that these comments may be late in terms of the IETF-process (the I-D
has been approved by the IESG?), but nevertheless I'm interested in
discussing these issues.

** Meta-question:

It's not very clear to me if it buys anything to deprecate the cone bit.

Let's put the random bits aside for a second (as their use is orthogonal
to the "cone bit" issue). If an attacker knows the address of an
existing Teredo client, he could e.g. send a packet to that Teredo
address from an arbitrary IP address, and wait for a response. If the
NAT e.g. sends an ICMP error message in response to packets for which
there's no corresponding mapping, then the attacker could easily learn
whether that node is behind a cone nat or not.

Alternately, an attacker could scan the mapped IPv4 address through the
corresponding Teredo server (provided all Teredo nodes behind that NAT
use that Teredo server), by sending bubble packets. Then he wouldn't
care about whether the cone bit is set or not, because his packets would
nevertheless get to the Teredo node (as they'd be relayed by the Teredo
server).

Finally, one might argue that by deprecating the "cone bit", you
actually *remove* one bit from the search space (as nodes could set the
cone bit to 0 even if they were behind a cone nat).

So I'm not sure if it buys anything to deprecate the cone bit... And
considering the performance implications, whether this makes sense or not.

Thoughts?


** Also, if the cone bit is deprecated, then I assume that Teredo nodes
implementing this document should probably implement this check:

"If a packet is received from an arbitrary Teredo node, there should be
an entry in the List of recent Teredo peers. This would prevent
attackers from trying to contact a Teredo node directly, despite the
implicit requirement in this document that a Teredo bubble be previously
sent through the corresponding Teredo server before contacting a Teredo
node."


** In Section 3.2, the document states:

>    o  The cone bit in the IPv6 source address of a Router Solicitation
>       (RS) from a client controls what IPv4 source address the server
>       should use when sending a Router Advertisement (RA).  If this
>       behavior is not preserved, legacy clients will conclude that they
>       are behind a cone NAT even when they are not (because the client
>       WILL receive the RA where previously it would not, since cone bit
>       set to 1 requires the server to respond from another IP address).
>       They will then set their cone bit and lose connectivity.

I would expect the Teredo client to not only check whether the RA is
received, but also check the Source Address of the RA. As a result, even
if the cone bit was ignored and thus the server sent an RA with the
"primary address" as the source address, the Teredo client should be
able to detect this (possibly failing on the "safe" side and concluding
that it is not behind a cone nat).


** Appendix B of draft-krishnan-v6ops-teredo-update-10 analyzes
resistance to address prediction. It argues that the search space is
16+12 bits. However, if the target NAT is a cone nat, the attacker would
not try a brute force approach. He'd first find those port numbers for
which there's an existing mapping in the NAT (see above), and *only* for
those ports he'd try to find the right 12 random bits that result in a
valid Teredo address. So this analysis might be a bit misleading.

Please let me know if I'm missing something....

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1