[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

On 10-08-21 09:03 PM, Fernando Gont wrote:

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



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



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


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




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