Re: SECDIR review: draft-ietf-v6ops-tunnel-concerns

[Nathan Ward <[e-mail]>]

On 23/10/2008, at 9:19 AM, Brian E Carpenter wrote:

> As far as I can see, there's a general problem in attempting
> to detect and block Teredo packets (I mean UDP/IPv4 packets
> in Teredo format). But it seems to me that by running an
> internal Teredo server, a site is much better placed to
> track and trace Teredo users. This is important as Teredo
> users really need to be running an IPv6-savvy host firewall.

Nope, as remote Teredo relays and hosts will send traffic directly. I  
do not believe that it is not possible to restrict Teredo to a certain  
domain.

Perhaps if the local Teredo server tells the local Teredo aware  
firewall what UDP ports on each IPv4 /32 are used for an address, then  
the firewall could inspect packets, but there are no such products  
currently.

You also have to force end hosts to use that Teredo server. It's not  
immediately clear to me how you would do that.

If you're in a position to operate a Teredo server in an end site  
organisation, you are better off doing ISATAP. That is what it is  
designed for.

>>> I agree with you that there are real threats (or will be, once
>>> there is enough deployment to make IPv6 tunnels an interesting
>>> target). It's quite appropriate to document them.
>>
>>
>> I need to preface these remarks by say that I haven't read the  
>> document
>> apart from a quick skim read, so sorry if I'm saying something that's
>> already in there, or is not relevant.
>>
>> I think it's important to distinguish between tunnels that end users'
>> systems create automatically (ala 6to4, Teredo in Vista), and tunnels
>> that end users create to work around firewalls.
>>
>> The former is easy to document solutions for, in fact, it seems to me
>> that any tunnelling protocol RFC should include details as to how a
>> network administrator can prevent these protocols passing through  
>> their
>> network. For Teredo this means blocking port 3544/3545. For 6to4 this
>> means blocking protocol 41 (preferably returning ICMPv6 messages
>> encapsulated in 6to4 so the the application is told about it..).  
>> This is
>> more about blocking things that do not work or perform poorly in a
>> certain environment, rather than trying to secure a network.
>>
>> The latter is not so easy, and I think this document should simply  
>> point
>> out that the only way to really do this is to completely control  
>> the end
>> users' machines, and not allow any third party software or  
>> configuration
>> changes. Anything else is instilling a false sense of security in the
>> minds of network administrators who perhaps are not as fluent in  
>> these
>> things as we are.
>
> Yes, but there are plenty of environments where that's impossible,
> and default deny is unacceptable because it blocks legitimate usage.
> I think the document needs to steer between the extremes, and suggest
> scenarios that are reasonably safe.


This is the security trade-off, and is up to the security people of  
each organisation I suppose. I don't think we can say what is or is  
not acceptable.

Most organisations where I have been employed have used default deny,  
and required the use of an HTTP proxy. That worked fine for 99% of  
people, and the few of us who had different requirements had special  
ethernet ports, etc.

I am very concerned about the direction we're heading in with firewall  
type stuff if we're requiring security people in organisations to  
understand (fairly) complex protocols like Teredo. I have a hard  
enough time explaining this to people who have worked in IP networking  
for a long time. An excellent example of this is Brian's comments in  
the first part of this email.

Because of this, I feel that this document should list several  
options, and state that the only way to be sure is the default deny,  
option unless you *really* understand the protocols and can prove it.

--
Nathan Ward