...just to put your mind at ease, no, that's not me. I'm all about the boxers not briefs. Now you know since you've all been wondering, I'm sure...
I really do appreciate it when people dedicate time, energy and expertise to making sure we're all as informed as we can be about the potential for bad things to happen. Case in point, hat tip to Mitchell for pointing us to just such a helpful tip from a couple of guys submitting a draft to the IETF regarding the evils of tunneled traffic.
Specifically, the authors are commenting on the "feature" called Teredo in which IPv6 is tunneled in UDP IPv4 datagrams.
Here's the shocking revelation, sure to come as a complete surprise to anyone it IT/Security today...if you only look at SrcIP, DstIP, SrcPort, DstPort and Protocol, you'll miss the fact that nasty bits are traversing your networks in a tunneled/encapsulated death ray!
Seriously, welcome to 1995. If your security infrastructure relies upon technology that doesn't inspect "deeper" than the 5-tupule above, you're surely already aware of this problem as 90% of the traffic entering and leaving your network is probably "tunneled" within port 80/443.
Here's a practical example. I stuck a Palo Alto Networks box in front of my home network as part of an evaluation for a client I'm doing. Check out the application profile of the traffic leaving my network via my FIOS connection:
Check out that list of applications above. Care to tell me how many of them are tunneled over/via/through port 80/443? True, they're not IPv6 in IPv4, but it's really the same problem; obfuscating applications and protocols means you need to have much more precise fidelity and resolution in detecting what's going through your firewalls colander.
By the way, I've got stuff going through SSH port forwarding, in ICMP payloads, via SSL VPN, via IPSec VPN...can't wait to see what happens when I shove 'em out using Fragrouter.
I'm all for raising awareness, but does this really require an IETF draft to update the Teredo specification?
/Hoff
2. Teredo Bypasses Security
2.1. Teredo Bypasses Network Security
2.1.1. Problem
IPv6 traffic tunneled with Teredo will not receive the intended level
of inspection or policy application by network-based security
devices, unless the devices are specifically Teredo aware and
capable. This reduces defense in depth and may cause security gaps.
This applies to all network-located devices and to end-host based
firewalls whose existing hooking mechanism(s) would not show them the
IP packet stream after the Teredo client does decapsulation.
2.1.2. Discussion
Evasion by tunneling is often a problem for network-based security
devices such as firewalls, intrusion detection and prevention
systems, and router controls. The vendor of such devices must add
support for detunneling for each new protocol. There is typically a
significant lag between when the vendor recognizes that a tunnel will
be used (or will be remotely usable) to a significant degree and when
the detunneling can be implemented in a product update, the update
tested and released, and the customer begins using the update. Late
changes in the protocol specification or in the way it is implemented
can cause additional delays. This becomes a significant security
concern when a delay in applied coverage is occurring frequently.
Specifically for Teredo, a Teredo-unaware network security device
would inspect or regulate the IPv4 and the IPv4-based UDP layer as
normal for IPv4, but it would not recognize that there is an
additional IP layer contained inside the UDP payload that it needs to
apply the same controls as it would to a native packet. (Of course,
if device discards the packet due to something in the IPv4 or UDP
header, such as referring to an unknown protocol, the Teredo packet
is no longer a concern.) Teredo also only recently reached RFC
status (February 2006), is widely applicable, requires no support
from the local or organizational network, and looks ready to be
widely used. Furthermore the tunnel created by the Teredo client is
open-ended and allows bidirectional traffic.
Network security controls being not applied must be a concern to
those that set them up, since those controls are supposed to
adequately regulate all traffic. If network controls are being
bypassed due to the use of IPv6 via Teredo, the burden of controls
shifts to the Teredo client host. Since security administrators may
not have full control over all the nodes on their network, they
sometimes prefer to implement security controls on the network.
One implication of the security control bypass is that defense in
depth has been reduced, perhaps down to zero unless a 'local
firewall' is in use, as recommended as a mitigation in RFC 4380.
However, even if there are host-based security controls that
recognize Teredo, security administrators may not have configured
them with full security control parity, even if all controls that
were maintained by the network are available on the host. Thus there
may be gaps in desired coverage.
Compounding this is that, unlike what would be the case for native
IPv6, some network administrators will not even be aware that their
hosts are globally addressable; for example, they may not be
expecting this for hosts with RFC-1918 [RFC1918] addresses behind a
NAT. In addition, Section 3.2 discusses how it may not be efficient
to find all Teredo traffic for network devices to examine.
2.1.3. Recommendations
Of course security administrators should disable Teredo functionality
unless their network-based security controls adequately recognize the
tunneled traffic (unless they consider it an acceptable risk).
However, there may be an awareness gap. Thus, due to the possible
negative security consequences, we recommend that explicit user
action be required to enable a Teredo client for the first time, at
least for the time being. When Teredo is being enabled or when it is
going to be used for the first time, perhaps there should be a
descriptive warning about the possible evasion that will occur. In
addition, Teredo client functionality should be easy to disable on
the host and through a central management facility if one is
provided.
RFC 4380 requires that Teredo be an IPv6 provider of last resort. To
minimize security exposure due to Teredo, we recommend that Teredo
also be an IP provider of last resort. Specifically, we suggest that
when both IPv4- and IPv6-based access to a remote host is available,
that the IPv4-based access be used in preference to IPv6 access that
needs to use Teredo. This should also promote greater efficiency and
reliability.
We specifically note that we could find no pre-existing mechanism for
Teredo to use that could automate its functionality being disabled
unless all network-based security controls were aware of it. A
separate type of consent request packet would be needed. (Such a
consent request service could have application beyond Teredo.)