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

[Jim Hoagland <jim_hoagland@symantec.com>]

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 


On 6/4/07 9:51 AM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

> 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
> fred.l.templin@boeing.com
> 
>> -----Original Message-----
>> From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es]
>> Sent: Saturday, June 02, 2007 2:04 AM
>> To: v6ops@ops.ietf.org
>> Subject: Re: New I-D: Teredo Security Concerns Beyond What Is
>> In RFC 4380
>> 
>> 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 <rdenis@simphalempin.com>
>>> Organización: Remlab.net
>>> Responder a: <owner-v6ops@ops.ietf.org>
>>> Fecha: Sat, 2 Jun 2007 11:48:26 +0300
>>> Para: v6 ops <v6ops@ops.ietf.org>
>>> Asunto: Re: New I-D: Teredo Security Concerns Beyond What
>> Is In RFC 4380
>>> 
>>> 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. 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/
>> 
>> 
>> 
>> 
>> **********************************************
>> 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.
>> 
>> 
>> 
>> 
>> 
>