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

[Alain Durand <Alain.Durand@Sun.COM>]

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