Re: New I-D: Teredo Security Concerns Beyond What Is In RFC 4380

[Jim Hoagland <jim_hoagland@symantec.com>]

I'm pleased to announce that Suresh Krishnan has agreed to co-author future
versions of this I-D

On 5/31/07 11:27 AM, "Rémi Denis-Courmont" <rdenis@simphalempin.com> wrote:

> Comments specific to some sections:
> 
> 2.2) I do not really understand the problem statement; Teredo tunnel
> perform return routability checks on any incoming non-Teredo address
> (something, say 6to4 does not do at all), and match incoming Teredo
> addresses to the underlying IPv4 address.

Does the return routability check ensure that the sender listed in a Teredo
packet is from the specified side of a network boundry?

Ingress filtering can also be used to filter IPv6 addresses that are
associated with, say, a denial of service attack.

Egress filtering makes sure that (perhaps compromised) hosts inside your
network do not pretend to be somewhere else on the Internet.  A gateway
device would have to look inside the Teredo tunnel to do egress filtering
for Teredo clients.

> 2.3) This is an issue indeed. But there is now strong consensus on the
> ipv6 WG to deprecate RH0, and require that IPv6 nodes do not process
> RH0 by default.

That's good.  However, it will be a while till that is universally deployed
so the concerns remain.  Although at least Windows Vista, by default, will
not forward past the end of the tunnel (or do RH0 forwarding in any other
situation).

I haven't studied Mobile IPv6 enough to know if RH2 is a concern here.
 
> 3.2) Already up Teredo clients will loose Teredo connectivity within the
> Teredo refresh interval + retransmission delay. That is to say
> typically 30+4*3=42 seconds. I feel that is not relevant compared to
> the lifetime of human-made firewall rulesets.

I'm not aware of any RFC 4380 requirement that Teredo clients voluntarily
give up their Teredo qualification when they stop being able to contact the
server.

-- Jim