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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 26 Oct 2001 12:00:32 +1000

> I'll post this primary on ngtrans.  If there are further comments I think 
> mobile-ip can be safely removed.
> 
>  
> > > > There is another draft you can find at:
> > > >
> http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00.txt
> > > > 
> > > > It's a WG draft in NGTRANS but it expired and I'll
> > > > resubmit it after adding some of the comments received. 
> > > 
> > > SIIT is regarded by many to be an abomination (redefining internal 
> > > structure like mapped-addresses) from security point-of-view among
> others.
> > > 
> > > It can probably solve some problems efficiently though, or else it 
> > > wouldn't have been introduced. :-)
> > > 
> > 	=> Well SIIT is a translation algorithm, used by NAT-PT and
> > 	this draft. It certainly does solve problems, like translating
> > 	packets.
> 
> There is a significant difference with SIIT and NAT-PT algorithm.  NAT-PT
> does not use mapped addresses when signifying an IPv4 node.
> 
> Putting mapped addresses as source/destination addresses is evil; think of
> (ab)using these against dual-stacked nodes. 
> 
	=> You mean translated addresses as a src address. Mapped 
	addresses are dst addresses. 
	"Evil" is a bit difficult to understand.

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

> and the destination will falsely believe that it originated from IPv4
> source 1.2.3.4.
> 
	=> I think this is a very straight forward implementation
	issue, unless I'm mising something. If you can check on
	1.2.3.4 you can certainly check on ::ffff:1.2.3.4. 

> > > But it should be kept in mind that it, alone, cannot be relied on to
> be
> > > sufficient for (M)IPv4 -> (M)IPv6 transition.
> > > 
> > 	=> Can you elaborate a bit ? This draft is done for allowing
> > 	IPv4-only nodes to communicate with IPv6-only nodes. 
> > 	MIP is one aspect of this communication. 
> > 	The draft doesn't say that this is the only way to do it, 
> > 	although in fact, for this scenario, it is the only way I know
> > 	of that allows for mobility support. 
> 
> Perhaps I didn't say it clearly; _IMO_, SIIT is not fit to be a
> wide-spread translation mechanism for IPv6-only nodes.  NAT-PT seems much
> better.  I tried to avoid getting MIP mixed into this.
> 
	=> Of course NAT-PT works, but much better for what ?
	Clearly there are different use scenarios here, to name some:

	- How many IPv4 addreses does a domain have ? 
	- Is e2e IP layer encryption needed ?
	- Is mobility support needed ?
	- Redundancy ? 
	- more ....

	I wouldn't say it's better, it depends on the scenario you're
	looking into.

	Cheers,
	Hesham

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Oct 2001 20:11:00 +0300 (EEST)

> 	addresses are dst addresses. 

src is mapped, dst is translated it seems (RFC2765 3.1)

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

These are enhanced by SIIT as (if you want to conform to it), the 
processing cannot be disabled.

> 	go through firewalls. If I missed something in the draft please

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

> 	1.2.3.4 you can certainly check on ::ffff:1.2.3.4. 

For a dual-stack node, before SIIT was defined, these were internally
exactly the same thing.  I'm not sure if these can be decoupled.