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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Hi Nathan,

On 2008-10-22 18:59, Nathan Ward wrote:
> 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.

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.

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

    Brian