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 documentapart 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 anetwork administrator can prevent these protocols passing through theirnetwork. For Teredo this means blocking port 3544/3545. For 6to4 this means blocking protocol 41 (preferably returning ICMPv6 messagesencapsulated in 6to4 so the the application is told about it..). This ismore 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 configurationchanges. Anything else is instilling a false sense of security in theminds of network administrators who perhaps are not as fluent in thesethings 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