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

From: Jim Hoagland <[email-masked]>
Date: Fri, 01 Jun 2007 09:01:10 -0700

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" <[email-masked]> 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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 1 Jun 2007 19:17:54 +0300

Le vendredi 1 juin 2007, Jim Hoagland a écrit :
> Does the return routability check ensure that the sender listed in a
> Teredo packet is from the specified side of a network boundry?
>
> 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.

There is something terribly wrong if one tries to use Teredo in a 
typical controlled corporate network. Teredo is not an "internal" 
transition mechanism; IETF has specified ISATAP for that purpose.

Teredo is only suitable for hosts in unmanaged networks. Much of the 
concerns in your draft seems to come from a misunderstanding or a 
disagreement as to where/when Teredo is suitable.

There is something seriously wrong if a corporate network relies on a 
NAT for security purposes, precisely because Teredo or any other hole 
punching system will break it easily.

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

5.2.5.  Maintenance

   The Teredo client must ensure that the mappings that it uses remain
   valid.  It does so by checking that packets are regularly received
   from the Teredo server.

You may argue that it does not strictly require that the client stops 
the tunnel when it receives no response, but this is common sense when 
implementing any NAT traversal and hole punching mechanism. Indeed, all 
of the, err... two publicly available Teredo client implementations do 
that.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: james woodyatt <[email-masked]>
Date: Fri, 1 Jun 2007 11:20:23 -0700

> transition mechanism; IETF has specified ISATAP for that purpose.

Yes.  That's why there is a security concern that Teredo might be  
used to escape policy enforcement at the network perimeter.  This  
draft explains how traffic in Teredo tunnels can be made subject to  
the same policy enforcement as everything else.  That's a good thing,  
isn't it?

> of the, err... two publicly available Teredo client implementations do

I think the worry here is about the Teredo implementations that might  
be integrated into malware for the purpose of escaping network  
perimeter policy enforcement.  In particular, I'd think that  
enterprises interested in controlling Skype would be concerned that  
Teredo might present an otherwise uncontrolled communication vector.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Jun 2007 14:36:45 -0700

> the same policy enforcement as everything else.  That's a good thing,

Frankly, I am not really concerned that someone will use Teredo to
"escape policy enforcement" in managed network. Teredo has a very
visible signature, using a fixed port for its signaling traffic.
Firewalls can very easily control that. If I want to escape the local
policy, I would much rather use some less visible tunnel solution, e.g.
tunneling IP over some random UDP port.

-- Christian Huitema

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sat, 2 Jun 2007 11:48:26 +0300

> Teredo might present an otherwise uncontrolled communication vector.

I respectfully disagree. There is no concern that Teredo might be 
integrated implemented by malware. If there is a concern, it might be 
that it might be enabled by default in Vista^Wsome hosts within a 
managed network. There is something terribly wrong with a managed 
network that:
- allows its users to upgrade to Vista unsupervised and/or without 
ensuring that Teredo is blocked; OR
- relies on NAT for perimeter security.

You are blaming Teredo instead of the poorly managed network here. 
Besides, as you say, it's not like there's not already Skype and other 
P2P protocols that have already broken out of such network perimeters, 
and are much more firewall-unfriendly.

Now back to the malware issue, take a network that can be "broken out 
of" with Teredo today. Disable every single Teredo client, relay and 
server on the whole Internet tomorrow. The only difference for a 
malware in that network tomorrow will be that it cannot contact a 
native IPv6 host directly. Any host that was reachable yesterday, 
including any public IPv4 host, is still reachable without Teredo, and 
any other NATed malware host can still use a similar hole punching 
mechanism. I doubt the native IPv6 reachability is much of a problem 
for malware authors.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 02 Jun 2007 11:04:13 +0200

Fully agree.

It is a matter of properly managing a "managed network". There are hundreds
of alternatives to Teredo that can be used to do bad things if you allow the
users to install whatever they wish, or to upgrade to new versions of OSs
without managing that upgrade, etc. It is not to blame Teredo.

In fact, Teredo will never come up if there is IPv6 support in the managed
network, and that's the right thing to do.

Regards,
Jordi

> De: Rémi Denis-Courmont <[email-masked]>
> Organización: Remlab.net
> Responder a: <[email-masked]>
> Fecha: Sat, 2 Jun 2007 11:48:26 +0300
> Para: v6 ops <[email-masked]>
> Asunto: Re: New I-D: Teredo Security Concerns Beyond What Is In RFC 4380
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Jun 2007 09:51:51 -0700

I agree with this too, and with what Christian Huitema
said about Teredo having a visible signature. I spent
some time on analysis of Teredo in 'draft-templin-ipvlx',
and IMHO malware authors have known for a long time how
to punch holes through NATs - at least for a longer time
than the Teredo specification has been around in either
I-D or RFC form.

Fred
[email-masked] 

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
> Sent: Saturday, June 02, 2007 2:04 AM
> To: [email-masked]
> Subject: Re: New I-D: Teredo Security Concerns Beyond What Is 
> In RFC 4380
> 
> Fully agree.
> 
> This electronic message contains information which may be 
> privileged or confidential. The information is intended to be 
> for the use of the individual(s) named above. If you are not 
> the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, 
> including attached files, is prohibited.
> 
> 
> 
> 
>

---

From: james woodyatt <[email-masked]>
Date: Mon, 4 Jun 2007 11:32:54 -0700

On Jun 4, 2007, at 09:51, Templin, Fred L wrote:
>> From Rémi Denis-Courmont <[email-masked]>
>>> Le vendredi 1 juin 2007, james woodyatt a écrit:
>>>>
>>>> I think the worry here is about the Teredo implementations that  
>>>> might be integrated into malware for the purpose of escaping  
>>>> network perimeter policy enforcement.  In particular, I'd think  
>>>> that enterprises interested in controlling Skype would be  
>>>> concerned that Teredo might present an otherwise uncontrolled   
>>>> communication vector.
>>>
>>> I respectfully disagree. [...] You are blaming Teredo instead of  
>>> the poorly managed network here.
>>
>> Fully agree.  It is a matter of properly managing a "managed  
>> network".
>
> I agree with this too, [...]

I should have mentioned that I didn't think security was a  
particularly important concern here.  As an implementor of security  
capabilities, my objectives are to stay current with best current  
practice.  My impression is that "best" remains an open topic of  
discussion.  I'm getting buffeted from both sides on this topic, and  
I don't want to hold myself out as an expert on security mechanisms.

My main concern with Teredo is trying to keep it from being anything  
more than transition mechanism.  To that end, I'm very sensitive to  
any cases where security perimeter enforcement makes the utility of  
Teredo higher from the perspective of an end user than the use of  
native IPv6, where both are available.  If Teredo is a method for  
bypassing security policies at firewalls, then Teredo becomes more  
than merely a transition mechanism.  No?

---

From: Jim Hoagland <[email-masked]>
Date: Mon, 04 Jun 2007 11:58:30 -0700

In writing the I-D, I was not particularly concerned about Teredo being used
by malware on an internal host.  The inbound direction was more of a
concern, e.g., Teredo opening opportunities for connecting to a client that
exceed what the administrator would want.

-- Jim

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 04 Jun 2007 21:20:47 +0200

For me the point is if you have a managed network and a managed border
firewall, you either block Teredo UDP port, and setup native IPv6, or may be
allow Teredo until you can deploy IPv6.

And if you want to go further, as the network is managed may be you want to
change the policy in all the hosts in order to disable Teredo.

So Teredo it is really used for what is designed, just a transition
mechanism, nothing else.

Regards,
Jordi

> De: james woodyatt <[email-masked]>
> Fecha: Mon, 4 Jun 2007 11:32:54 -0700
> Para: V6OPS WG <[email-masked]>

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 4 Jun 2007 22:43:18 +0300

Le lundi 4 juin 2007, vous avez écrit :
> In writing the I-D, I was not particularly concerned about Teredo
> being used by malware on an internal host.  The inbound direction was
> more of a concern, e.g., Teredo opening opportunities for connecting
> to a client that exceed what the administrator would want.

I note that blocking all INBOUND UDP traffic FROM port 3544 effectively 
prevents from Teredo bubbles from doing hole punching, rendering 
unsolicited inbound through Teredo impossible, unless the host is 
behind a full cone NAPT (in which case it definitely is not in a 
security-sensitive perimiter).

I maintain that any sane administrator of any vaguely sensitive network 
drops everything by default except a few known services, but if (s)he 
does not, blocking outbound packets with destination port 3544 and 
inbound UDP packets with source port 3544 is more than enough to make 
100% sure Teredo will not work. There is zero need for deep packet 
inspection.

Inspection would only make sense if you wanted to partially allow IPv6 
traffic through Teredo, but I think we have consensus that Teredo must 
not be used in managed networks instead of native IPv6 (or ISATAP by 
default), so deep inspection is indeed really useless here, and there 
is no need to upgrade the firewalling software either.

The I-D notes that blocking port 3544 might adversely affect other 
protocols. This has a very low probability, but technically is true 
nevertheless. However port 3544 is only ever used:
- by the Teredo protocol, or
- as a random ephemeral (source) port
If the point of the firewall is to block incoming traffic, the outside 
port should ought to be a well-known one, while the inside port might 
be ephemeral. Hence blocking port 3544 from/to the "outside" is very 
safe.

IMHO, if there is something to worry about w.r.t firewalling, Skype and 
HTTP/CONNECT are more like it.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Jim Hoagland <[email-masked]>
Date: Thu, 14 Jun 2007 08:24:39 -0700

> is no need to upgrade the firewalling software either.

If there is consensus that Teredo should not be used in managed networks
then IMHO that should be stated publicly, since people may not realize the
security implications.  The reasonable use cases for Teredo aren't mentioned
in the RFC at all.

Do people have any comments on other parts of the I-D?

Incidentally, I am going to be talking about Vista networking and Teredo at
the Black Hat security conference on Aug 2.  I'd welcome your thoughts as to
what you think the take-away message should be regarding Teredo security
implications.

-- Jim