Subject: RE: (ngtrans) Security and use of SIIT and NAT-PT [IPv4 and MIPv6 Transition]

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Sat, 27 Oct 2001 20:01:04 +1000

> > 	=> You mean translated addresses as a src address. Mapped 
> > 	addresses are dst addresses. 
> 
> src is mapped, dst is translated it seems (RFC2765 3.1)
> 
	=> OK we must have different ends in mind. In the draft 
	in question, and based on the definition in 2765 (2.1), 
	stating that mapped addresses are used to
	"refer to a node that is not IPv6-capable". 

> > 	"Evil" is a bit difficult to understand.
> 
> Left as excercise for the reader's imagination :-)
> 
> Some problems of mapped addresses (among others) were also discussed in:
> 
> ftp://ftp.itojun.org/pub/paper/draft-itojun-ipv6-transition-abuse-01.txt
> 
	=> From memory this draft got the same comments, 
	and that these problems could be avoided by the careful
	kernel implementations. 
	For example, before you tunnel to the v4 address embedded
	in a 6-to-4 address, make sure the v4 address is useable. 

> > > E.g.: IPv4 firewall would block packets from source 1.2.3.4, but the
> > > packet gets through via IPv6 transport with src address
> ::ffff:1.2.3.4,
> > > 
> > 	=> Err, reconfigure the firewall ! 
> > 	Anyway, I must ask if you've read the draft, because the proposed
> > 	solution is hardly expected to allow these addresses to
> > 	go through firewalls. If I missed something in the draft please
> > 	let me know. 
> 
> We're talking about IPv4(-only) firewall here.  The scenario:
> 
> 
> attacker_dual  ---- INET -+- firewall_v4 --+- victim_dual
>                           |                |
>                           +----------------+  
> 
> I believe this is very common; IPv6 is often considered as "experimental"
> 
> and "those with knowledge of ipv6 know to protect themselves".
> 
> Now, however, by attacking via IPv6 and mapped addresses, the victim could
> 
> be led to believe the packet was from an IPv4 address (which might have 
> been filtered in the firewall).
> 
> Sure, this is not how SIIT should be used -- no sense when "victims" are
> dual-stack,
> 
	=> Exactly.

>  but this is one way how mapped addresses could be abused if
> the processing were to be enabled by any IPv6 node.
> 
> Yes, I've read the draft (though only cursorily).  It may be that you
> expect SIIT and mapped addresses to be used in only well-defined
> circumstances, in well-defined fashion.  I don't.
> 
	=> Well defined circumstances, meaning an IPv6-only
	node communicating with an IPv4-only node. The scenario
	you mention would not occur in this case. Or have I missed 
	something ?

	Cheers,
	Hesham

---

From: Pekka Savola <[email-masked]>
Date: Sun, 28 Oct 2001 00:42:56 +0300 (EEST)

> 	"refer to a node that is not IPv6-capable". 

If one does receive a packet with src=::ffff:1.2.3.4, one cannot know
AFAICS whether the source node is:
 - IPv4-only node (through translation by SIIT)
 - IPv6-only node
 - dual-stack

You see, the first scenario is the only _valid_ one, but the end node 
cannot know that!  Malicious IPv6 only/DS nodes could very well send the 
identical packets too.
 
> 	and that these problems could be avoided by the careful

I've not enumerated all the problems here, but there are some which depend 

> 	in a 6-to-4 address, make sure the v4 address is useable. 

e.g. if IPv4 address would be 1.255.255.255, the kernel implementation 
couldn't know this is a broadcast address which may reach up to.. very 
many nodes.  It only has knowledge of its own configuration.

Some security breach/bouncing attacks (e.g. the router being attacked is
in internal and external network) like, delivering a packet via IPv6 to
the router, which would push it to internal network via IPv4 (or
alternatively, believe it originated from there), could be difficult to
implement.  This would require at least enabled-by-default RPF checks,
which would break RFC1812 I recall.

> 	you mention would not occur in this case. Or have I missed 

It appears so.  But I don't think this can be guaranteed.

One of the main problems is that a node must not enable
mapped-addresses-from-the-wire processing unless it is absolutely
IPv6-only (exception: boxes performing SIIT translation).  In practise, I
think this is not easy to get done; this would lead to all IPv6
implementations always enabling the processing, I fear, to cope with
supporting SIIT.

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