Rational Survivability

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