Subject: (ngtrans) practical 6to4 security rulesets

From: Pekka Savola <[email-masked]>
Date: Tue, 28 Aug 2001 15:31:08 +0300 (EEST)

Hi,

I made some analysis on how you could _practically_ perform
en/decapsulation filtering with 6to4.  This should be pretty much
applicable to shipworm etc. too.

I may have missed a few cases.. but that's what peer review is for :-).
Please send comments.

I'd like to know if there are still any prominent attacks if you were to
protect yourself with these.

--8<--
There are basically four kinds of traffic (by 2001 I mean all "native"
global prefixes):

0) src=2001, dst=2001
1) src=2001, dst=2002
2) src=2002, dst=2001
3) src=2002, dst=2002

Wrt. 6to4, these are used as follows:

Relay: 1) [incoming from native], 2) [outgoing to native]
Router: 1) [tunneled from relay], 2) [tunneled to relay], 3) [tunneled directly]

Ie: we assume that 6to4 routers always send 6to4 traffic directly, and
relays never relay other than native-6to4 traffic.  I think these should be
reasonable assumptions.

Additional worries:
 - ingress filtering (usually not enabled by default).
 - multi-interface routers/relays where 6to4 prefix is not tightly bound to
   the equivalent ipv4 address

Depending how the stack is implemented, 'dst_v4 must be assigned to the
router' may be more or less redundant (designed to keep from sending to
broadcast, and having the packets to arrive to specified address if
"earmarked for 6to4").

I've marked the checks, in addition to the basic sanity checking, I feel are
important with (!!).

Possible sanity checks (note that with these assumptions and separating
de/encapsulation, there is no need to specify whether the system is relay
or regular 6to4 router):

Encapsulating IPv6 into IPv4
----------------------------

 src and dst must pass ipv6-sanity checks **)
 (src_v4 and dst_v4 must pass ipv4-sanity checks *) -- a little redundant)

 if src=2002

	src must match src_v4 (!!)

	[ the scenario: 6to4 router sending traffic from local 6to4 clients
	to native ipv6 through 6to4 relay ]

 	if dst=2002

		dst_v4 must not be assigned to the router (avoid misconfigurations)

		[ the scenario: 6to4 router sending traffic from local 6to4 clients
		to other 6to4 domains over ipv4 tunneling ]
	fi

 elif dst=2002

	(may set src_v4 as anycast_ipv4 if performing 6to4 anycast service)

	src_v4 may have to match one of ipv4 equiv. of 6to4 prefixes masked by a
		user-specified netmask [restricting who can use the relay]

	[ the scenario: 6to4 relay receiving traffic from native, passing to
	6to4 over ipv4 tunneling ]

 else
	drop it

	[ the scenario: we somehow got a native-native ipv6 packet ]
 fi

Decapsulating IPv4 into IPv6
----------------------------

 src_v4 and dst_v4 must pass ipv4-sanity checks *)
 src and dst must pass ipv6-sanity checks **)

 if dst=2002

	dst must match dst_v4 (!!)

	src_v4 may be restricted to be 6to4_ipv4_anycast [not useful for a long time yet]

	[ the scenario: 6to4 router receiving traffic from 6to4 relay to local ipv6
	addresses ]

	if src=2002

		src must match src_v4 (!!)
		dst_v4 must be assigned to the router

		[ the scenario: 6to4 router receiving traffic from 6to4 domains over
		ipv4 tunneling to local 6to4 clients ]
	fi

 elif src=2002

	src must match src_v4 (!!)
	dst_v4 must be assigned to the router

	src_v4 may have to match one of ipv4 equiv. of 6to4 prefixes masked by a
		user-specified netmask [restricting who can use the relay]

	[ the scenario: 6to4 relay receiving traffic from 6to4
	routers to native ipv6 addresses]

  else
	drop it

	[ the scenario: we somehow got a native-native ipv6 packet ]

  fi

*) ipv4 address must not be:
	0.0.0.0/8
	10.0.0.0/8
	127.0.0.0/8
	172.16.0.0/12
	192.168.0.0/16
	169.254.0.0/16
	224.0.0.0/4
	240.0.0.0/4 (or perhaps only 255.0.0.0/8)

	additional checks (XXX: are these useful at all?):

	any broadcast address of the system
	uRPF-like checks (XXX: very chancy..)

**) ipv6 address must not be:
	0::/16	  (compat, mapped addr, loopback, unspecified)
	fe80::/10 (link-local)
	fec0::/10 (site-local -- do we need to allow these?; use ISATAP or whatever)
	ff00::/8  (multicast) [XXX: should this work with 6to4? -- at least
		   ff02 (link-local) could be denied)

	2002:V4ADDR:: equivalent of ipv4 checks

-- 
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: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2001 11:14:52 -0500

Pekka,

I think this is important and probably needs to become an I-D
with scenario diagrams to make it easier to analyse. It looks
basically OK to me but I need diagrams to be sure. Maybe you
could build off the diagrams in RFC 3056 (I have PowerPoint versions
of them if they would help you). 

Do you think there is any conflict with the Security Considerations
of RFC 3056? If there is no conflict you could aim at a separate
RFC for this; otherwise we would need to update 3056.

    Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

"We shall need a number of efficient librarian types 
 to keep us in order." - Alan Turing, 1947.