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

Reply via email to