Re: comment on unmanaged analysis presentation/doc

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Tue, 24 Sep 2002 12:08:03 +0200 (CEST)
    From:        Erik Nordmark <Erik.Nordmark@sun.com>
    Message-ID:  <Roam.SIMC.2.0.6.1032862083.2043.nordmark@bebop.france>

  | But that means that 6to4 provides the ultimate packet laundering service
  | for source address spoofing that a combination of IPv4 and IPv6 ingress
  | filtering can not prevent.

Not really any more than any other IP tunnel system does.

  | Any IPv4 ingress filtering will happily let such packets through since
  | the IPv4 src is not spoofed.

Ingress filters wouldn't block this anyway - (except in rare cases
where the destination doesn't want to be visible to most of the internet).

It is egress filters that can block spoofed IPv4 addresses (and which
make the mobile IP people upset...).  Whether they should be used at
all is still something that seems to be debated (my mind changes on
this each time I hear the arguments from the other side).

But assuming that they are to be used, first, no-one can count upon
them (ie: this is something other sites, ISPs etc, do, in order to protect
their own good name, to stop attacks coming from their net - it isn't
to protect the target), and second, there's nothing to prohibit such
filters from gazing inside (unencrypted) tunnels and filtering based
upon what is there - so if I was really concerned about preventing spoofed
IPv6 src addrs from escaping my net, then I'd be having my filter
look at the IPv6 src addr inside the tunneled packet (or filtering that
at or before, my 6to4 router, and blocking all 6to4 packets from other
random internal hosts).

  | The 6to4 router at the victim's site will blindly decapsulate and
  | loose all track of the IPv4 source.

yes.   Just as a pure IPv6 router will blindly pass on a native IPv6
packet and loose all track of the IPv6 source (as does IPv4).  The only
filtering that can be done at the destination, is to make sure that the
source address isn't meant to be on the destination link.  A 6to4
decapsulator can do that as well (check that the IPv6 packet it is about
to forward isn't one which really belongs in the local IPv6 net).

  | The victim might be able to insert a probe (after noticing the attack)
  | at its 6to4 router and see the IPv4 source.

Tracing spoofed source addr attacks is hard, however the packets are
transmitted.   The only mitigating factor is that they can't require
any kind of response, so the range of attacks is limited (mostly DoS only,
though there are a couple of other hard to get right ones).

  | An approach for handling native to 6to4 site communication differently
  | would be for the 6to4 site to explicitly establish a bidirectional tunnel

Hmm - isn't that exactly what 6to4 is supposed to be avoiding?
That is, if this was to be required, wouldn't it be easier to just
scrap 6to4, and replace it with TSP instead?   That then also gets
rid of the :lots of /48 prefixes" problem, as the assigned address
would be one from the remote endpoint's address block.

kre