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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Mon, 29 Oct 2001 19:29:21 +1100

> > > 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". 
> 
> 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
> 
	=> The only time you should receive this packet is if it
	came from an SIIT router. If it comes from the SIIT router
	it would be tunnelled, the outer src address is the SIIT
	router's address. 

> 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.
> 
	=> This might be a thick question, but isn't it true that 
	any node can send you a packet with src address XYZ
	and you won't really know who sent it unless there is some 
	form of e2e security ?
	Why is this problem specific to this scenario ?
>  
> > > > 	"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. 
> 
> I've not enumerated all the problems here, but there are some which depend
> 
> on the knowledge a kernel implementation does not know, e.g.:
> 
> > 	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. 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.
> 
	=> There are standard checks in kernels on src addresses though. 
	If the src address is multicast, broadcast ....etc then packets 
	are dropped.

> 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.
> 
	=> OK let's get this down to the specific case we're looking 
	at:

	IPv4-node -----------------> SIIT router
---------------------------> IPv6-node
	                                    |------------single
domain--------|
	
	I don't see what the _specific_ dangers here that can only be 
	introduced in this case and not if SIIT was not used ?

> > >  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 ?
> 
> 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; 
> 
	=> I'm interested to know the reason behind this statement. IPv6
	nodes would certainly contain one or more transition mechanism. 
	A single stacked node should implement this because the only
	choices it has to communicate to an IPv4 only node are
	- NAT-PT (nothing to implement)
	- SIIT (implement the necessary parts)

	The first method is transparent and the second isn't, so the 
	IPv6 node will certainly know whether it should use SIIT or not.

> this would lead to all IPv6
> implementations always enabling the processing, I fear, to cope with
> supporting SIIT.
> 
	=> Well this conclusion relies on your statement above though, ie.
	assuming that it is difficult (in practice) to select the mode of
operation.  
	But I don't understand the reason for this difficulty.

	Hesham

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 Oct 2001 14:14:48 +0200 (EET)

Sorry for taking a while..  Hopefully the message isn't too incoherent, as 
it has been written over the course of a few days under various stages of 
insomnia.. :-)

> 	it would be tunnelled, the outer src address is the SIIT

I don't see why tunneling is necessary; SIIT router should sit at the edge
of a site's topology, and there would be IPv6 connectivity set up between
them already (or did you mean IPv6-in-IPv6 tunneling?).  In this scenario
the packet comes from some source upstream, nobody can say which.

> 	Why is this problem specific to this scenario ?

Special addresses are always tricky.

If the destination node is dual stack, it might try to reply to the
packets by reaching the _IPv4_ spoofed address corresponding to mapped
address XYZ.  Or if connecting with IPv4 fails for some reason (e.g.  
firewall), the connectivity could be obtained via IPv6 transport, spoofing
the source, so the destination would believe the packets were received via
IPv4.

> 	introduced in this case and not if SIIT was not used ?

The graph got mangled, but I think I know what you mean.

As far as there are only IPv6-only or IPv4-only nodes in the single
domain, and no DS at all, I don't see how SIIT would cause enermous
trouble as long as the SIIT router can somewhat trust the IPv6 nodes (IPv6
nodes could abuse mapped addresses).

> 	- SIIT (implement the necessary parts)

IPv6-only node is not a big problem.  Dual-stack is.

Consider a dual-stack box acting as a router (not SIIT-router) between
IPv6-only SIIT system and SIIT router.  Consider someone tracerouting from
the outside to IPv6-only SIIT system.  The DS router should send ICMP hop
limit error back to a mapped address in the source address.  Internally,
the source address is already '::ffff:something'.  How does it distinguish
that it should send the packet to that address via SIIT router, and not
interpret is as an interpretation of an IPv4 address, and send it via
IPv4.

One might want to filter all mapped addresses at a firewall, or in kernel 
implementations.  If there could be IPv6-only nodes requiring that 
functionality in the network, it naturally could not be done.

>       IPv6 node will certainly know whether it should use SIIT or not.

I'm not sure what you mean by this.  Kernel implementors surely know
whether they want to implement features or not, true.  But if they do, the
node might or might not know whether the _user_ needs to enable e.g. SIIT.  
And what is also important, neighbouring nodes (e.g. routers, firewalls)
do not know whether the node wants to enable SIIT or not.
 
-- 
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