IPv4 mapped address considered harmful

draft-itojun-v6ops-v4mapped-harmful-00.txt

Jun-ichiro itojun Hagino, KAME/IIJ research lab

itojun@{kame,iijlab}.net

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Number 1 source of insecurity - ambiguity

	X means A, or X means B - we can't tell which is which

	I grant access to X because I guessed X means A
	but in reality, X meant B!  we are hosed!

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Ambiguity in IPv4 mapped address

	IPv4 mapped address is used in various ways
	Ambiguous -> security issues

	RFC2553 - IPv4 peers on AF_INET6 socket API
	SIIT - traffic from/to IPv4 peers
		native IPv6 packet on wire
	BGP4+ hack - tunnel endpoint

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Security issues

	Applications sees IPv4 mapped address
	it cannot know if:
		it is IPv4 peer (due to RFC2553)
		it is IPv6 peer (IPv6 native packet/SIIT)

	Various attacks possible
		confuse access control (::ffff:127.0.0.1)
		pretend to be insider (::ffff:10.0.0.1)
		traffic reflection/inflation/anonymization
			echo to ::ffff:10.255.255.255 -> 10.255.255.255

	Not just a firewall issue
		Complex combination attack possible
		example - use routing header to bypass packet filters

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

How to solve it?

	Remove ambiguity

	which one to pick?
		RFC2553 API special consideration
		IPv4 mapped address use on the wire
		BGP4+ hack

	Due to the deployed codebase, RFC2553 API use should stay

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Protocol action recommendation

	RFC2373 should declare that IPv4 mapped address is for use within RFC2553, and RFC2553 only
	deprecate any protocol document that use IPv4 mapped address for other uses

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Implementation suggestions (kernel/library)

	Background
		OSes has to be secure by default, take a security stance

	Do not support RFC2553 special consideration for IPv4 mapped addr

	Turn on IPV6_V6ONLY socket option in 2553bis by default
		default in doc - off

	drop any IPv6 packet with IPv4 mapped address

	drop any AAAA DNS response with IPv4 mapped address

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Implementation suggestions (application)

	Every application should check IN6_IS_ADDR_V4MAPPED and take actions
		impossible to enforce this in reality

	Do not rely on RFC2553 special consideration for IPv4 mapped addr
		Always AF_INET if you want IPv4 connection
		More portable, more robust

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Summary

	Ambiguity is an easy way to insecure behavior

	IPv4 mapped address is used in various ways - ambiguous

	Removing ambiguity is critical
		We have to take a security stance

	Recommendation - IPv4 mapped address is only for RFC2553 use

		(from mailing list discussion, there seem to be some implementation differences wrt IPv4 mapped address handling) 

-end