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

[Nathan Ward <[e-mail]>]

On 22/10/2008, at 10:15 AM, Brian E Carpenter wrote:

> Suresh,
>
> You wrote to Christian:
>
>> While I agree with you about the possibility of an "arms race" I  
>> really
>> do not see anything we can do about this. What would you recommend
>> instead? I am really open to suggestions.
>
> My feeling is that we need to tell IT managers something like
> "If your users have a need for IPv6 tunnels, here is how to
> make them as safe as possible:
>
> <description of mechanisms, e.g. for detecting DoS,...>
>
> and after that, explain the threats, and state that tunnels
> should be disabled if you are not protected against the threats.
>
> There are also other positive suggestions, like operating
> an on-site 6to4 relay and/or Teredo server, so that those
> mechanisms don't cross the border router.

Operating a Teredo server on site does not help unfortunately.

It helps an administrator filter outbound packets when sent to an IPv6  
address outside 2001::/32. It does not help an administrator filter  
inbound packets, or packets to/from other Teredo hosts.

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

--
Nathan Ward