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