Subject: (ngtrans) 6to4 v4/v6 src/dst security checks

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Jun 2001 11:35:32 +0300 (EEST)

Hi,

In RFC3056, Security chapter, there is:

---
   By default, 6to4 traffic will be accepted and decapsulated from any
   source from which regular IPv4 traffic is accepted.  If this is for
   any reason felt to be a security risk (for example, if IPv6 spoofing
   is felt to be more likely than IPv4 spoofing), then additional source
   address based packet filtering could be applied.

                                                     A possible
   plausibility check is whether the encapsulating IPv4 address is
   consistent with the encapsulated 2002:: address.  If this check is
   applied, exceptions to it must be configured to admit traffic from
   relay routers (Section 5).
---

This appears a bit unclear.  Are we talking about source addresses?  dst
addresses?  Both?

I thought about this a little and as far as I can see, the checks could be
like:

 1) 6to4 border routers can check (when receiving)
   - if v4 source addresses are restricted via e.g. v4 prefix length, 6to4
RR must fall within this OR be excepted.
   - whether v4 dst and v6 dst in the packet have equal common part
   - whether v4 dst and 6to4 address(es) on the pseudointerface have equal
common part

 2) relay routers can check (when receiving)
   - source as above, but RR's should usually have this as 0 unless
restricted
   - whether v4 dst and 6to4 address(es) on the pseudointerface have equal
common part
   - NOT dst's _in the packet_:

  nodeA  --- native ipv6 --- 6to4 relay - - - tunnel - - - 6to4 router
 2001:2::1             2001:1::1 2002:1::1               2002:2::1

When 6to4 router sends a packet to native ipv6 address, the packet is
tunneled to 6to4 RR.

If the tunneling is done with compatible addresses (most usual I think),
there is no problem as there aren't significant checks applied to the
packet.

If the default route is configured using 6to4 RR's 6to4 address, there
may be a problem with ipv6 dst and v4 dst being different.
(in this case: v6 dst: 2001:2::1, v4 dst: 0.0.0.1 [2002:1::1]).

From 6to4 relay to 6to4 is fine (as always when the 6to4 tunneling foreign
endpoint is the final destination).

So, is there a problem in my thinking, or is the security bit a bit fuzzy?

-- 
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: [email-masked]
Date: Thu, 14 Jun 2001 17:43:21 +0900

i guess most of the items are mentioned in 
	draft-itojun-ipv6-transition-abuse-01.txt (which is already expired),
	as well as KAME manpage for stf(4) interface.
	http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/man/man4/stf.4

>there is no problem as there aren't significant checks applied to the

	i don't understand this part of your description.  in which part did
	you use IPv4 compatible address (::x.x.x.x) in the diagram?  could
	you clarify?

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Jun 2001 11:56:37 +0300 (EEST)

> 	draft-itojun-ipv6-transition-abuse-01.txt (which is already expired),

Generally yeah, the possible solutions aren't all applicable though.

> 	you use IPv4 compatible address (::x.x.x.x) in the diagram?  could

This wasn't in the diagram.  To clarify what I meant:

6to4 router has default route to 2000::/3 set to either:

 1) automatic tunnel (::0.0.0.1) [2002:1::1, bad oversimple example]
 2) 6to4 automatic tunnel (2002:1::1)
 3) manual tunnel (non-issue in this scenario..)

I think that 1) is used the most at the moment; or if not most, at least
significant number of people are using it.  It's easier to just 'host
6to4.somewhere.isp.com' and put in ::v4addr to the route.

---

From: [email-masked]
Date: Thu, 14 Jun 2001 18:04:24 +0900

>Generally yeah, the possible solutions aren't all applicable though.

	there's no perfect solution for this problem with "accept packet
	from anyone" tunnelling device, IMHO.

>  nodeA  --- native ipv6 --- 6to4 relay - - - tunnel - - - 6to4 router

	i don't see any difference between the following two:
	# route add -inet6 default ::0.0.0.1
	# route add -inet6 default 2002:1::1

	also, for these cases, the actual packet (from 2002:2::1 to 2001:2::1)
	will be generated like below, and there's no difference in validation
	rules.  the gateway address (::0.0.0.1 or 2002:1::1) does not affect
	anything.

	do I understand your scenario correctly?

itojun

if we do "route add -inet6 default ::0.0.0.1", the packet on tunnel will
be like this:

	IPv4 src: 0.0.0.2
	IPv4 dst: 0.0.0.1
	IPv6 src: 2002:2::1
	IPv6 dst: 2001:2::1

if we do "route add -inet6 default 2002:1::1", the packet on tunnel will
be like this:

	IPv4 src: 0.0.0.2
	IPv4 dst: 0.0.0.1
	IPv6 src: 2002:2::1
	IPv6 dst: 2001:2::1

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Jun 2001 12:47:29 +0300 (EEST)

> 	do I understand your scenario correctly?

Yes.

But depending on the implementation, security checks applied to compatible
and 6to4 tunneling methods might vary a lot, and as such autotunneling was
out of the scope of "6to4" security issues consideration.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 14 Jun 2001 22:11:01 +0900

>out of the scope of "6to4" security issues consideration.

	that is what I mentioned in abuse draft.  implementations/operators
	must be *very* careful considering attacks using holes due to
	complicated configuration with multiple transition technologies.

itojun