[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



o By transmitting IPv6 packet with ::ffff:127.0.0.1 in IPv6 source
 address field, applications that assume basic API behavior will be
 tricked to believe that the packet is from the node itself (IPv4
 loopback address, 127.0.0.1).
How is that different from the case of an IPv4 application receiving
a packet with src address = 127.0.0.1?
The kernel should have dropped it before passing it to
the application.(see my last comment in this mail)


o By transmitting IPv6 packet to firewall device, with IPv4 mapped
 address corresponds to address inside the firewall (like
 ::ffff:10.1.1.1) as the IPv6 source address, malicious party could
 bypass IPv4 filtering rules and inject traffic inside the firewall.
This only means that ingress filtering should be smarter...
And anyway, with all the security issues concerning tunneling
and open relays, firewalls needs to be smarter.


o Assume that the victim node is an IPv4/v6 dual stack node.  By
 transmitting IPv6 packet with IPv4 mapped address corresponds to IPv4
 broadcast address (::ffff:10.255.255.255) in IPv6 source address
 field, to TCP/UDP port that swaps IPv6 source and destination address
 (e.g. UDP port 53, DNS), malicious node can trick the victim node to
 generate improper IPv4 broadcast traffic; This is because basic API on
 the victim node will emit transmission requests to destination IPv4
 mapped address, ::ffff:10.255.255.255, into IPv4 traffic.
If a kernel implements 'basic API' semantic, it would/should
drop any packet which src/dst address is v4-mapped.
However, it the kernel implements 'SIIT' semantic,
and passes v6 packets to applications with IPv4-mapped src addresses,
the reserver is also ture, that is, when those applications will answer,
the kernel will output a v6 packet, not a v4 packet...
Then up to the SIIT box to drop directed broadcast.


	- Alain.