Subject: v6mapped-harmful comments [Re: another input to IPv6 addressing architecture]

From: Pekka Savola <[email-masked]>
Date: Sat, 7 Sep 2002 22:31:39 +0300 (EEST)

Hi,

A few comments on the draft.

General:

I agree that v4mapped on the wire is bad for many reasons, but how it 
could be removed / use simplified is a different thing.

Content:

2.  Threats due to the use of IPv4 mapped address on wire

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

==> this would be partially fixed if the implementations were forced (by 
some mechanism) re-inject the packet to ip_input (or equivalent), not 
continue processing it locally.  Then most harmful packets would be 
rejected as bogons.

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 would be a bit more difficult to achieve with above means.

5.1.  Kernel/library developers

o Do not support IPv4 mapped address on AF_INET6 API (RFC2553 section  
  3.7).  By doing so the kernel TCP/UDP code will be greatly simplified,
  and will reduce the likelihood of security-sensitive kernel bugs.

==> I don't think it's nice to advocate (at least, without any warning or 
more detailed text!) non-comliance with the API: many server-side 
dual-stack apps rely on this functionality to operate.  If such support 
would be arbitrarily skipped, the dual-stack application would then 
continue to bind only to :: --> IPv6 and no longer v4.  Smells like a huge 
operational problem.

Editorial:

Some of the translator technologies such as SIIT [Nordmark, 2000] uses

==> s/of the //
==> s/uses/use/

4.  Suggested protocol change

==> s/change/changes/

o Drop any IPv6 native packet with IPv4 mapped address in any of IPv6
  
==> s/native // (or ..?  -- I don't understand what native means there)

o Drop any IPv6 DNS response that contains IPv4 mapped address.

==> "IPv6 DNS response" .. a bit ambiguous. do you mean AAAA response?

On Fri, 30 Aug 2002 [email-masked] wrote:

> 	i have another input to IPv6 addressing architecture, which is
> 	very securty-sensitive.  please review and integrate it before
> 	publishing the next one.
> 	draft-itojun-v6ops-v4mapped-harmful-00.txt
> 
> itojun
> 
> 
> ---
> 4.  Suggested protocol change
> 
> o In IPv4 address architecture document [Hinden, 1998] explicitly state
>   that IPv4 mapped address is for use within basic API [Gilligan, 1999]
>   , and basic API only.  Forbid any other uses.
> 
> o Move any document that suggests the use of IPv4 mapped address on wire
>   to historic, due to security reasons.
> 
> The above change will remove the threat due to the use of IPv4 mapped
> address on wire.
> 
> Another way is to deprecate RFC2553 section 3.7, however, due to the
> wide deployment of applications that use IPv6 basic API, the option is
> not feasible.
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Sep 2002 01:18:08 +0200 (CEST)

> The above change will remove the threat due to the use of IPv4 mapped

From a process perspective this seems to be in the wrong order.
Unless standards track documents which use IPv4-mapped addresses
are moved off the standards track first, then the above first step would
create a conflict between a proposed standard and a draft standard.
That would we bad.
So if you are contemplating doing this, I'd recommend reversing the order of
the steps.

I'll save on technical comments for some other time :-)

  Erik