Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 18 Dec 2002 16:36:41 -0800

Christian Huitema wrote:
> With a defense like the one I propose, it becomes about as hard to spoof
> a v6 address using 6to4 as it is to spoof a v4 address (or a v6 address)
> in the first place, which implies that 6to4 would have a neutral effect
> on Internet security.

This is the part I was missing. To paraphrase, without your proposed
mechanism a v6 source address using 6to4 can be spoofed more easily
than a v4 source address since the 6to4 router strips off the v4
source. With your proposed mechanism, a v6 source address using 6to4
can be spoofed IFF the v4 source can be spoofed, i.e., v6 using 6to4
and v4 are equally (in)secure.

I don't have a strong opinion on whether/not this is good enough.
But, I do I see a difference in the two models: in the v4 case, the
v4 destination receives the log of v4 source addresses. In the v6
case (and using your mechanism) the *true* v6 source receives the
log of v4 source addresses.

Thanks,

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Dec 2002 08:28:03 +0200 (EET)

> log of v4 source addresses.

Hmm.. your use of the word "true" seem ambiguous?

The proposed solution (which seems like a nice idea to me) is that the 
_attacked node_ (ipv6 source address in the spoofed packets) receives 
these reports -- seems the same as the case in v4 (with the exception that 
reports are received from the internet, not from received packets 
themselves).

But this is by no means simple as that; you have to consider things like 
the attacker sending false reports to the target directly to "water down" 
the report results.

As such this is very much like iTrace, and if implemented, I guess this
should be just an extension (or simplification) of it, for this specific
purpose.

-- 
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: "Christian Huitema" <[email-masked]>
Date: Wed, 18 Dec 2002 15:54:58 -0800

> Maybe I missed something, but could it not be the case that the
> attacker is randomly varying his source address? In which case,
> the log collected at S6 may contain uncorrelated (and
> untraceable) S4's?

The specific problem we are addressing is that of an attacker that
cannot change her source address, e.g. because the ISP imposes ingress
filtering. Such an attacker cannot mount an attack against an IPv4 site
without identifying herself; yet it could use servers behind 6to4
routers as a prop in an anonymous reflection attack against an IPv6
target.

-- Christian Huitema

> Alain Durand wrote:
> > This could be a very good deterent.
> >
> >    - Alain.
> >
> >
> > Christian Huitema wrote:
> >
> >> Which is why we need some sort of mitigation. One way to make the
> attack
> >> risky for the attacker is to send back a tracing message, as
follow:
> >>
> >> Upon reception of a 6to4 packet from IPv4 source S4, IPv4
destination
> >> D4, IPv6 source S6 and IPv6 destination D6, the 6to4 router
performs
> >> ingress checks. If S6 is a "native" (non 6to4) IPv6 address, the
router
> >> checks that D6 is a local destination, i.e. a 6to4 address whose
header
> >> embeds the destination D4; if that it not the case, it drops the
> packet.
> >> (This is as specified today.) If D4 and D6 have the right value,
the
> >> 6to4 router picks a random boolean value, true x% of the time; if
the
> >> value is true, the router formats and send an IPv6 packet, such as:
> >>     IPv6 source: the router's 6to4 address;
> >>     IPv6 destination: S6
> >>     Payload type and format: TBD
> >>     Content: includes notation of S4
> >> In a situation of attack, these packets can be retrieved by S6 (the
> >> attacked party) to identify S4 (the IPv4 attacker.) It does not
matter
> >> that the attack is spread to a large number of relays: x% of the
> >> attacker's packet will provide a sufficient signature, they will
all
> >> contain the address S4.
> >> -- Christian Huitema