Subject: Re: (ngtrans) practical 6to4 security rulesets

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Sep 2001 12:48:21 +0300 (EEST)

On Fri, 31 Aug 2001, Brian E Carpenter wrote:

Sorry for taking a while, I was chewing on this for a while and otherwise
occupied, besides.

> 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).

Yes, I'll look into this; the diagrams are important.  Any thoughts on the
goal, informational?

A couple of issues:

- Some of the checks presented may be impossible to do because 6to4 is,
after all, on a _pseudo_ - interface.  If the implementation has multiple
mechanisms that each decapsulate ipip packets and expect ipv6 inside, this
could get troublesome because the implementation might sometimes have
problems seeing which transitional mechanism is applicable.  This applies
especially to "martian" (fe80:: etc.) checks in IPv6 addresses.

There are two approaches to this I think:
 * just present "ideal" rules, as if the interface wasn't pseudo
 * try to check what could actually be done by assumptions from a few
implementations, perhaps additionally mention the ideal case too.

- Some of the checks belong more to a packet filter than (probably)
a kernel implementation.  Those should probably be noted like that.

- One assumption I made is that 6to4 routers always tunnel all 6to4
traffic directly, ie. 6to4 address are assumed to be "on-link".  If you
tweak the prefix length somehow, to e.g. limit who you tunnel to and
accept tunnels from, some 2002 -> 2002 traffic would perhaps flow to the
relay.  This would break most assumptions I made, e.g. KAME stf(8) page:

                                              If you would like to restrict
     6to4 peers to be inside certain IPv4 prefix, you may want to configure
     IPv6 prefix length as ``16 + IPv4 prefix length''.  stf interface will
     check the IPv4 source address on packets, if the IPv6 prefix length is
     larger than 16.

Note that relay has to fall within this prefix length, and the checks have
to be symmetric (AFAICS) -- if the other end tries to send directly to
you, packets _will_ get lost.

So this looks like an option that's only applicable in "enterprise-wide"
(more or less centrally coordinateable)  6to4 IPv6 experiments with global
addresses, and that we may not need to care about this.

> 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.

I see no direct conflict, but room for clarification.  The wording in
RFC3056 is so that it just gets you started on thinking about how to
implement the checks, but can't help you much further.

Issues in it I see now:
                                                            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).

There is no need for the exception, assuming that you require the checked
addresses are of the form 2002:V4ADDR and V4ADDR.  Ie: checking for
2001:... and V4ADDR should naturally not be done.

This is because you should never get traffic from the relay to 6to4
router, the source address of which is 2002:V4ADDR, only 2001 and other
native prefixes.  Native routers do get such traffic, but they don't
perform the checks anyway as they know nothing about 6to4 in particular.

Another point is that some implementations may want to check _destination_
addresses for plausibility.  This should only be done on 6to4 routers for
received direct traffic.  There is no sense for this, as above, for doing
in the relays (2001 <-> 2002 case).

 Pekka

>     Brian
>
> Pekka Savola wrote:
> >
> > 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
>
>

-- 
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: Tue, 11 Sep 2001 14:47:12 -0500

> Yes, I'll look into this; the diagrams are important.  Any thoughts on the

Until we have the experience for a BCP, I think Info is best.

> implementations, perhaps additionally mention the ideal case too.

Some implementors will presumably not have this problem - after all,
why should a pseudo-interface not have the same data structures as
a real one? So I would prefer to see the ideal rules listed with
commentary on implementation restrictions.

> a kernel implementation.  Those should probably be noted like that.

Yes
> relay.  This would break most assumptions I made, e.g. KAME stf(8) page:

My idea was always that you would make it look like a completely standard
address except in the sending code.

>      check the IPv4 source address on packets, if the IPv6 prefix length is

That was definitely not the original model.

> addresses, and that we may not need to care about this.

Agreed
> implement the checks, but can't help you much further.

Which was exactly our state of mind when we wrote it.

> 2001:... and V4ADDR should naturally not be done.

Yes, I think we were very slightly confused when writing that sentence :-)
> in the relays (2001 <-> 2002 case).

Yes, this is really a corner case.

So, are you going to write a draft?

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
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.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Sep 2001 15:00:09 +0300 (EEST)

> commentary on implementation restrictions.

The problem of it being "pseudo" can be illustrated from this example:

Assume a 6to4 router has IPv4 address 20.20.20.20.

Also assume that it has other connections that are tunneled; especially
automatic tunneling or ISATAP; on some implementations, regular tunnels
could also be affected.

Router receives ipip packet to IPv4 address 20.20.20.20 via an Ethernet
interface.

Does it belong to 6to4, autotunnel, isatap (or regular tunnel)?

Without looking into the encapsulated IPv6 header, it's impossible to
tell.  However, this invalidates some "basic" IPv6 security checks (e.g.
link-local multicast, unspecified, ...) for those packets that can't be
identified to clearly belong to 6to4 (e.g. destination is 2002::/16).

This is not a show-stopper, but does limit realistic options somewhat,
regardless of the implementation.

Shipworm-like methods, where one communication channel (ipip-tunnel) is
not multiplexed, this is obviously not an issue.

> So, are you going to write a draft?

Yes.  Please elaborate on the diagram part on what you had in mind (sent
you a note in private mail) -- I'm not sure which kind of diagrams etc.
would be best to clarify the scenarios.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Sep 2001 11:58:25 -0400

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:
    Pekka> Without looking into the encapsulated IPv6 header, it's impossible to
    Pekka> tell.  However, this invalidates some "basic" IPv6 security checks (e.g.
    Pekka> link-local multicast, unspecified, ...) for those packets that can't be
    Pekka> identified to clearly belong to 6to4 (e.g. destination is 2002::/16).

  I believe that *BSD (at least NetBSD) does exactly that.
  This is equivalent to IPsec tunnel exit checks, and should not surprise
anyone.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [