[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: mech-v2: decapsulation check updates



-----BEGIN PGP SIGNED MESSAGE-----

Tom Petch wrote:

> A thought.  The day before you sent this, I heard an interesting
> presentation at RIPE-47 on tunnel discovery which used  host to router
> tunnels to find out how many tunnels there are in v6 (A: lots!) and
> also flagged some of the dangers, eg of ND packets sent direct from
> host to egress router.  It recommended keeping
> tunnels to network edge and using GRE (didn't grasp why).

I saw the presentation too and he recommended GRE because that
isn't that easy to be spoofed. proto-41 tunnels can easily be
spoofed by just sending your packets with a different source address.
As most tunnelbrokers and other tunneled systems don't do any
egress checks one can find very cheap and untraceable upstreams.
Just start sending those packets with a known IPv4 source address.
Getting to know the IPv4 source address is a bit hard though, he
dug them all from the horribly trashy 6bone database and apparently
about 80% of those tunnels didn't work at all.

The only solution ofcourse is to get those **** ISP's to do
egress filtering, thus them allowing only packets to go outward
that are really assigned to the customer and nothing else.
Many ISP's don't do this, thus this is at a complete loss.
The fact that I see RFC1918 addresses on my adsl gateway tells
enough ofcourse...

btw. from his presentation I can conclude that either GARR or
RIPE's networks allow spoofing of source IP's...

For testing this is ofcourse not that bad, but DDOS anyone?

> I don't see anything in the stronger decapsulation checks 
> that will stop this form of tunnel discovery although have a vague feeling 
> that some would see this as an abuse of the tunnels and would like to stop it.

It certainly is abuse, but how can you check?
The packet gets sent from source A, even though the
real source is Z. This is a ISP security issue.
Only thing one could do about this is add some kind
of password or signature mechanism to defeat this.

For instance with my heartbeat mechanism I know at
least for sure that the source who is sending the
packet also knows the password for the tunnel.
The problem only is that proto-41 packets coming
from that IP don't have any checks. Thus if someone
figures out a source IPv4 + IPv6 then they can
easily spoof that connection, even if it where only
for outgoing packets. Doing proto-41 + a magic signature
wouldn't harm anything except that it isn't deployed.
I guess that is also one of the reasons why Pekka uses
the pptp tunnels in his STEP document as these provide
authentication, thus spoofing gets a bit harder.

Note that we do employ egress filtering and only the
IP's that are routed to the machine itself are allowed
to be used as a source address, anything else is either
admin-icmp'd or silently dropped depending on the POP.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / http://unfix.org/~jeroen

iQA/AwUBQCJqDSmqKFIzPnwjEQLPogCcDbMImCKZsBJVBru+bluBHbkadkQAnj9L
v8re3pjDJ7V09mKeIgvYMmhF
=4MIp
-----END PGP SIGNATURE-----