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

From: Fernando Gont <[email-masked]>
Date: Sat, 21 Aug 2010 22:03:51 -0300

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 23 Aug 2010 00:29:19 -0400

Hi Fernando,
    Thanks for your comments. Please see responses inline.

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

I think it does. Here's why. The cone bit tells the attacker whether a 
bubble is needed to create a connection.  It also has some value in 
terms of profiling to the extent that it reveals the security posture of 
the network.  If the cone bit is set, the attacker may decide that it is 
worthwhile to port  scan the embedded external IPv4 address and others 
associated with the same organization, looking for open ports.

> cone bit to 0 even if they were behind a cone nat).

You are right. The cone bit deprecation was done to conceal the posture 
of the network. The intent was not to increase the search space.

> sent through the corresponding Teredo server before contacting a Teredo

Wouldn't section 5.2.3 of RFC4380 cover this check already?

> valid Teredo address. So this analysis might be a bit misleading.

I am not sure why you think this is misleading. It talks about a 
scenario where the attacker does not know the port (i.e. Not the 
scenario you are considering). The following text in the Security 
Considerations section covers your scenario, doesn't it?

"As a result, even if a malicious user were able to determine the 
external (mapped)
    IPv4 address and port assigned to the Teredo client, the malicious
    user would still need to attack a range of 4,096 IPv6 addresses to
    determine the actual Teredo IPv6 address of the client."

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Aug 2010 02:04:55 -0300

Hi, Suresh,

Thanks so much for your response. Please find my comments inline....

> bubble is needed to create a connection.  

Isn't it trivial to learn this information, anyway? And if it is, does
it make sense to deprecate the cone bit?

> It also has some value in

Please see my earlier comment about this. Regardless the deprecation of
the cone bit, an attacker can nevertheless do this.

No. The relevant piece of RFC 4380 is:

>    3) If the source IPv6 address is a Teredo address, the client
>    compares the mapped IPv4 address and mapped port in the source
>    address with the source IPv4 address and source port of the packet.
>    If the values match, the client MUST create a peer entry for the IPv6
>    source address in the list of peers; it should update the entry if
>    one already existed; the mapped IPv4 address and mapped port in the
>    entry should be set to the value from which the packet was received,
>    and the status should be set to "trusted".

That is, the Teredo client will trust unsolicited packets, instead of
requiring a bubble beforehand.

>> that it is not behind a cone nat).

This one remains unanswered ;-)

> I am not sure why you think this is misleading. 

This would imply that in order to find all Teredo nodes the search space
would be 16+12 bits. In practice, it isn't. Firstly, you'd find open
ports at the NAT, with a search space of 16 bits. Then, *only* for each
open port the search space would be 12 bits.

> It talks about a

Yes, but see the small nit above.

Thanks!

Kin regards,