>I agree with Jim that we shouldn't break how IPv4-mapped addresses are used
>in the basic API spec, nor should we forbid their use on the wire as SIIT
>requires today.
>The security issues Itojun raises look to me to be internal
>implementation-specific issues. Let's look at his examples:
no, this is not an implementation-specific issue.
first I need to be very clear: I have couple of options to solve
this security issue. major routes are:
- change addressing architecutre and forbid native-ipv4-mapped
CONS: application writers are asked to check RFC2553-inbound
cases, which is not that trivial when seeing the spec
CONS: SIIT cannot be used
- change RFC2553 API to disable RFC2553-inbound
PROS: applications gets simplified very well, AF_INET6 is
always IPv6, AF_INET is always IPv4 (good for security)
PROS: RFC2553-inbound case is gone, application writers do not
need to care about RFC2553-inbound cases
CONS: SIIT itself is okay, but now unnatural
- change RFC2553/2292 API to pass protocol version on the wire to the
userland, to allow applications to distinguish between RFC2553-inbound
and native-ipv4-mapped
PROS: no impact to SIIT
CONS: too much complexity is left, bad for security
now we are talking about the first one. taking both 1st and 2nd
one is my favorite, actually.
here i try to define acronym for clarification:
RFC2553-inbound:
inbound IPv4 traffic goes into AF_INET6 wildcard socket
RFC2553-outbound:
outbound AF_INET6 packet with IPv4 mapped address goes to IPv4
native-ipv4-mapped:
IPv6 packet with IPv4 mapped address in src/dst address field
in IPv6 header
>> We have three problems with the specification. First,
>> IPv4 mapped address support complicates IPv4 access
>> control mechanisms. For example, if you would like to
>> reject accesses from IPv4 clients to a certain transport
>> layer service, it is not enough to reject accesses to
>> AF_INET socket. You will need to check AF_INET6 socket
>> for accesses from IPv4 clients (seen as accesses from
>> IPv4 mapped address) as well.
>Isn't this obvious? What's the problem? And how would preventing
>IPv4-mapped addresses on the wire protect against this anyway?
you right, this one does not directly solved by prohibiting
native-ipv4-mapped.
i have seen and made improvements to many ported applications.
almost none of them have the proper access control logic with
consideration to RFC2553-inbound. for security, complexity is a
bad thing.
>> Secondly, malicious party may be able to use IPv6
>> packets with IPv4 mapped address, to bypass access
>> control. Consider the following scenario:
>> o Attacker throws unencapsulated IPv6 packets, with
>> ::ffff:127.0.0.1 as source address.
>> o The access control code in the server thinks that
>> this is from localhost, and grants accesses.
>This is just broken access control code in the host. If you want to protect
>against this, you need similar checks in any decapsulator as well, right?
>Why is this any different?
no, this is not the access control code that is broken.
the problem is, under RFC2553, you have no way to distinguish between
native-ipv4-mapped and RFC2553-inbound packet, in the userland.
both of them have ::ffff:127.0.0.1 as the result of getpeername
(or getsockname), both of them appear on AF_INET6 socket,
if you would like to permit accesses from IPv4 127.0.0.1, and
even if you would like to reject native-ipv4-mapped with
::ffff:127.0.0.1, you can't do that.
In the solutions I listed, I missed one option: extend API to
give application some idea about the IP version (native-ipv4-mapped
or RFC2553-inbound).
>> Lastly, malicious party can make servers generate
>> unexpected IPv4 traffic. This can be accomplished by
>> sending IPv6 packet with IPv4 mapped address as a source
>> (similar to abuse of IPv4 compatible address), or by
>> presenting IPv4 mapped address to servers (like FTP
>> bounce attack [Allman, 1999] from IPv6 to IPv4). The
>> problem is slightly different from the problems with
>> IPv4 compatible addresses and 6to4 addresses, since it
>> does not make use of tunnels. It makes use of
>> certain behavior of userland applications.
>As you note, there are similar problems with IPv4-compatible addresses and
>6to4 addresses. Again, why is adding checks to protect against one any
>different than adding checks to prevent against the other? I'm against
>dropping useful features of the protocol just to ease development of a
>particular implementation.
the problem is that people can inject malicious packets more easily
than before. they can inject malicious IPv6 packet from remote
places (by wrapping it into IPv4 packet). they can let us relay
malicious packets by abusing normal IPv6 routers, auto-tunnel
capable IPv6 routers, and 6to4 relay routers. it will be much harder
to track than normal IP packets we are seeing.
>> The confusion came from the dual use of IPv4 mapped
>> address, for node-internal representation for remote
>> IPv4 destination/source, and for real IPv6
>> destination/source.
>Personally, I consider this to be a feature. To apps, a host with a
>hybrid-stack should look exactly the same as a host that sits behind a
>translator, shouldn't it?
>Hmm, maybe it would be best for an implementation to internally map source
>addresses of incoming IPv4 packets to IPv4-mapped addresses and destination
>addresses to IPv4-translated addresses (and vice-versa on send).
SIIT requires the dual use of IPv4 mapped address (native-ipv4-mapped
and RFC2553-inbound). this is a feature of SIIT, not the other
documents. (see the earliest part of the email for possible other
routers to take)
>> 3.2. Possible solutions
>> o When implementing TCP or UDP stack, explicitly record
>> the wire packet format (IPv4 or IPv6) into connection
>> table. It is unwise to guess the wire packet format,
>> by existence of IPv6 mapped address in the address pair.
>If an implementation decides that it really needs to know whether a packet
>came in as a real IPv4 packet or as an IPv6 packet with
>mapped/translated/compatible addresses, then it could do this. Why is this
>a bad solution? ~~~~
maybe my text is rather unclear, but what part are you referring
to by the underlined "this"?
itojun
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
