Subject: Re: New "IP Version 6 Addressing Architecture" draft

From: Tim Hartrick <[email-masked]>
Date: Fri, 21 Jul 2000 17:08:34 -0700 (PDT)

Itojun,

> 
> 	the point i would like to make was that:
> 	- it is much easier to inject malicious packet from remote,
> 	  with bypassing normal access control imposed by normal routers
> 	  inbetween

For the specific example you noted, use of subnet broadcast addresses in
the source address field, I don't see how it would bypass normal router
or firewall checks.  The bogus address will be placed in the destination
address field of the encapsulating IPv4 datagram.  When that datagram
arrives at the ingress point of the target network it would/should be
filtered just like a IPv4 datagram with a UDP payload would be filtered.

Can you elaborate on how an IPv4 datagram encapsulating an IPv6 datagram
is going to be treated differently than a IPv6 datagram encapsulating
a UDP payload?

> 	- it is much harder to track the source down, as malicious party can use
> 	  many relays (6to4 relays, auto-tunnel routers, whatever) to
> 	  anonymize his traffic.  this is just like smtp case: tracking the
> 	  source of spam is very hard due to smtp relays.

That may be but I would need some concrete examples of this that don't
assume that the nodes involved are not filtering the obvious cases like
0.0.0.0, 255.255.255.255, 127.x.y.z, and 224.x.y.z.

> 
> >	If application level access control software like tcp wrappers
> >needs to be updated to understand IPv4 mapped IPv6 addresses then so be it.
> >They will need to be updated for IPv6 anyway and I don't see how adding
> >support for mapped address makes that job substantially more complicated.
> 
> 	there's no way for the current API to recognize IPv4 traffic on top
> 	of AF_INET6 socket (appears as IPv4 mapped address), and native
> 	IPv6 traffic with IPv4 mapped address in the header).  at least
> 	we need to provide the functionality.
> 

Why does there need to be a distinction?  In either case the communication
is with an IPv4 host.  I don't understand why, from a policy point of view,
it matters to the target host whether the packet was routed directly
using IPv4 or translated into IPv6 from IPv4 by a SIIT box.  The initiating
host is an IPv4 host by virtue of the fact that the address is a IPv4 mapped
IPv6 address.

That is not to say that there are not some fairly nasty details to be
worked out from an implementation point of view.  Dealing with both flavors
of mapped address could be interesting.  But from a policy enforcement point
of view, an IPv4 peer is an IPv4 peer regardless of how the datagram arrived
or even what kind of datagram it was (IPv4 or IPv6) that brought the upper
layer protocol payload.

Can you elaborate on why it matters to policy enforcement code like TCP
wrappers or other such application level access filters?  Maybe I am missing
some subtle point of how SIIT is supposed to work.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: [email-masked]
Date: Mon, 24 Jul 2000 21:01:26 +0900

I think most of the items are replied in reply to Brian.

>host is an IPv4 host by virtue of the fact that the address is a IPv4 mapped

	What i'm worrying about is,
	- when we are outside of SIIT cloud and
	- when we got an IPv6 packet with IPv4 mapped address as src/dst.
	This is the third case in the following chart.  Sorry if I was not
	clear enough.

	For the case, I can do nothing but consider the packet as malicious,
	as no specification gives me any interpretation, and the packet
	is indeed usable to inpersonate some IPv4 peer.

	Just to be clear, documents are like below.
	- RFC2373 is silent about this case, RFC2373 only says that
	  the IPv4 mapped address indicates IPv4 peer.  in the third case,
	  however, this does not really indicate IPv4 peer.
	- RFC2553 is also silent about this case, it talks about how
	  real IPv4 peer is presented on AF_INET6 API.
	- SIIT is not the document to look at.

in/out of	IP version/src/dst	what does the		getpeername sees
SIIT cloud	of packet		src represents?
---		---			---			---
inside		IPv6, IPv4 mapped	SIIT-translated		IPv4 mapped
					IPv4 peer		on AF_INET6

inside		IPv4			shouldn't happen	can't accept
								it (IPv6 only)

outside		IPv6, IPv4 mapped	inpersonater		IPv4 mapped on
					(IMHO)			AF_INET6

outside		IPv4			real IPv4 peer		IPv4 mapped
								on AF_INET6
								(2553 behavior)
								or IPv4 on
								AF_INET

itojun