RE: mech-v2: decapsulation check updates

[Pekka Savola <pekkas@netcore.fi>]

Hi,

It's good to bring this up.  In the current transmech document, the
security-related parts have been rewritten.  This threat has also been
described at some length -- the stronger decapsulation checks help a
lot, but other alternatives are also offered.  I'd be interested in
hearing suggestions if the language e.g. in security considerations
could be strengthened.

On Thu, 5 Feb 2004, Jeroen Massar wrote:
> I saw the presentation too and he recommended GRE because that
> isn't that easy to be spoofed. 

GRE is equally easy to spoof, unless GRE keying is used.  And then you 
have to set up that keying.

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

Indeed, finding the address is the most difficult part.

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

Right.

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

Precisely: you either:

1) have to live with this threat (making it difficult to learn the
source address of the tunnel; remember, that typically people WON'T
put them in a public database, making the guessing very difficult!)

2) do something to stop/mitigate it, e.g.:
 a) run the tunneling only with inter-domain;
 b) perform ingress/egress filtering at the border of your domain
 c) something else
 -- note: a) + b) is a complete solution.

3) use some other mechanisms
 a) GRE with keying
 b) IPsec


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

Actually, STEP uses just plain proto-41 tunnels, and there is no
authentication at all.  But the work is scoped so that it isn't aimed
at crossing ISP boundaries, so the ISP is just shooting himself in the
foot unless he's doing very specific filtering (at least, killing
proto-41 packets to the tunnel server from the upstreams).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings