First, let me point out a property of overloading protocol 41, from my
draft:
--8<--
There is a problem with multiple transition mechanisms if security is
implemented. This may vary a bit from implementation to
implementation.
Consider three mechanisms using automatic tunneling: 6to4, ISATAP
[ISATAP] and Automatic Tunneling using Compatible Addresses [MECH].
All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with,
more or less, a pseudo-interface.
When a router, which has any two of these enabled, receives an IPv4
encapsulated IPv6 packet:
src_v4 = 10.0.0.1
dst_v4 = 20.20.20.20
src = 3ffe:ffff::1
dst = 2002:1010:1010::2
what can it do? How should it decide which transitionary mechanism
this belongs to; there is no "transitionary mechanism number" in IPv6
or IPv4 header to signify this.
Without any kind of security checks (in any of implemented methods)
these often just "work" as the mechanisms aren't differentiated but
handled in "one big lump".
Configured tunneling [MECH] does not suffer from this as it is point-
to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses
it can be deduced which logical tunnel interface is in the question.
Solutions for this include not using more than one automatic
tunneling mechanisms in the same system or binding different
mechanisms to different IPv4 addresses.
--8<--
In this case, consider a node which has configured tunnels, autotunnel and
6to4.
If it receives a packet with:
src=1.1.1.1
dst=2.2.2.2
src6=fe80::1
dst6=fe80::2
it cannot know which mechanism this was intended for.
If configured tunnel was between 1.1.1.1 and 2.2.2.2, it could try to
guess this must be meant for the configured tunnel. (I haven't looked into
6to4 multicast yet, but this kind of link-local assumption might not
hold).
however, if the packet is e.g.:
src6=::1.1.1.1
dst6=fe80::2
is it for configured, autotunnel 6to4 (if the box is a 6to4 relay) or
what?
There are more unclear scenarios like this.
This makes security checks rather difficult to implement.
On Wed, 19 Dec 2001, Tony Hain wrote:
> Pekka Savola wrote:
> > Undeniably, you can input packets with:
> >
> > - link-local source (here: ff80::1)
> > - link-local destination (here: ff80::2)
> > - hop limit 255
> >
> > in the tunnel interface.
>
> Not if the tunnel interface consistency check is applied to prevent it.
> If you don't want to accpet link-local packets over the tunnel you are
> not required to. Accepting packets through a filter needs to be done for
> each of the interfaces. If you are willing to accept packets from any
> IPv4 source, but not any IPv6 source, then you have to recheck the
> packet once it is decapsulated.
Autotunneling has no such checks, and 6to4 just mentions this (in the
context of source addresses). Destination address? By RFC3056, relays
cannot have either or these checks.
Also see above.
> > Now, if the router has 'ff80::2' configured as one of it's
> > pseudo-interface addresses, that address can be reached via tunneling
> with
> > hop limit 255 from anywhere.
> >
> > See the potential problem here?
>
> Yes, the node is reachable using IPv4 from anywhere, and you are trying
> to make believe that adding IPv6 is somehow a bigger problem. What is
> the point?
IPv6 has local-scoped addresses that have a special significance.
Via mechanisms like 6to4 (depending on whether optional security
precautions are taken) one can inject IPv4 packets in the internal network
that would not have passed the IPv4 checks.
> If packets can get there via IPv4, the fact that some of them
> may be encapsulated IPv6 makes no difference. If a node has a policy
> that packets over the global IPv4 interface go through some firewall
> process, then the same policy MUST apply to the tunnel interface. If it
> doesn't the site administrator is brain-dead and deserves what he gets.
The site administrator is braindead because he allows people to use any
(it's all or nothing) IPv6 tunneling mechanism? Note that IPv4 site
administrator cannot know whether it's being used for configured,
automatic or whatever tunnels. Do we want to make these braindead site
operators block protocol 41?
The point is, the checking is de-centralized from IPv4 firewalls to tunnel
endpoints. If every host used 6to4 (the 6to4 host+router scenario), every
6to4 host would have to implement these checks, firewall policies etc.
This is when site operators say: "no thanks! No ipv6 here please!". Is
that what we want?
> If your complaint is that a site administrator can't apply grainular
> policy to a link-local address over a tunnel, you are right and they
> simply need to block all FE80 addresses on that interface.
Insecure by default? Hopefully not for the joe-random-user -orieted
methods like 6to4 or shipworm at least.
--
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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
