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

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

Hi, Suresh,

Thanks so much for your response. Please find my comments 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.  

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

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



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

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.




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

This one remains unanswered ;-)



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

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

Yes, but see the small nit above.

Thanks!

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