Subject: Re: mech-v2: decapsulation check updates

From: "Tom Petch" <[email-masked]>
Date: Thu, 5 Feb 2004 15:22:57 -0000

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

The presentation (433KB) is at

http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-
disco.pdf

Tom Petch

-----Original Message-----
From: Pekka Savola <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 28 January 2004 14:38
Subject: mech-v2: decapsulation check updates

>Hi,
>
>Since the last version of the transmech document, the decapsulation
>checks have become much stronger: MUST check the v4 source of the
>tunnel, MUST check the v6 source addresses for bogus addresses and
>MAY/should use v4/v6 ingress filtering.
>
>Any objections to these changes?  Other thoughts?
>
>=========
>3.6.  Decapsulation
>
>   When an IPv6/IPv4 host or a router receives an IPv4 datagram that is
>   addressed to one of its own IPv4 addresses, and the value of the
>   protocol field is 41, the packet is potentially part of a tunnel and
>   needs to be verified to belong to one of the configured tunnel
>   interfaces (by checking source/destination addresses), reassembled
>   (if fragmented at the IPv4 level), have the IPv4 header removed and
>   the resulting IPv6 datagram be submitted to the IPv6 layer code on
>   the node.
>
>   The decapsulator MUST verify that the tunnel source address is
>   correct before further processing packets, to mitigate the problems
>   with address spoofing (see section 4).  This check also applies to
>   packets which are delivered to transport protocols on the
>   decapsulator.  This is done by verifying that the source address is
>   the IPv4 address of the other end of a tunnel configured on the node.
>   Packets for which the IPv4 source address does not match MUST be
>   discarded; an ICMP message (whether IPv4 or IPv6) SHOULD NOT be
>   generated.
>
>   A side effect of this address verification is that the node will
>   silently discard packets with a wrong source address, and packets
>   which were received by the node but not directly addressed to it
>   (e.g., broadcast addresses).
>
>   In addition, the node MAY perform ingress filtering [RFC2827] on the
>   IPv4 source address, i.e., check that the packet is arriving from the
>   interface in the direction of the route towards the tunnel end-point,
>   similar to a Strict Reverse Path Forwarding (RPF) check [BCP38UPD].
>   If done, it is RECOMMENDED that this check is disabled by default.
>   The packets caught by this check SHOULD be silently discarded.
>
>[[ skip paragraphs about MTU and figures..]
>
>   After the decapsulation the node MUST silently discard a packet with
>   an invalid IPv6 source address.  The list of invalid source addresses
>   SHOULD include at least:
>
>    -   all multicast addresses (FF00::/8)
>
>    -   the loopback address (::1)
>
>    -   all the IPv4-compatible IPv6 addresses [RFC3513] (::/96),
>        excluding the unspecified address for Duplicate Address
>        Detection (::/128)
>
>    -   all the IPv4-mapped IPv6 addresses (::ffff:0:0/96)
>
>   In addition, the node should perform ingress filtering [RFC2827] on
>   the IPv6 source address, as on any of its interfaces, e.g.:
>
>    -   if the tunnel is towards the Internet, check that the site's
>        IPv6 prefixes are not used as the source addresses, or
>
>    -   if the tunnel is towards an edge network, check that the source
>        address belongs to that edge network.
>
>
>

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 5 Feb 2004 17:06:37 +0100

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

Tom Petch wrote:

> 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

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 6 Feb 2004 12:09:16 +0200 (EET)

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

> about 80% of those tunnels didn't work at all.

Indeed, finding the address is the most difficult part.

> The fact that I see RFC1918 addresses on my adsl gateway tells

Right.

> 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

---

From: Gert Doering <[email-masked]>
Date: Fri, 6 Feb 2004 11:29:13 +0100

Hi,

> tunnels to network edge and using GRE (didn't grasp why).

I've been there as well, and spent some time discussing this with the
author.

As far as I can see, the fears about "users could do bad things with
ND and other 'link-local' things that way" are more due to "some fuzzy
feeling that people could do bad things", and not based on hard facts.

On the other hand, address spoofing is a real threat - and as Jeroen said,
the only thing you can do about it is to make sure that IPv4 uRPF is
widely deployed...

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  58081  (57882)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 7 Feb 2004 07:12:35 +0900 (JST)

> I've been there as well, and spent some time discussing this with the

	do you know why the author recommeded GRE?  there's no real difference
	between RFC2893 tunnel and GRE with respect to address spoofs and stuff,
	as far as i understand.

itojun

---

From: Gert Doering <[email-masked]>
Date: Fri, 6 Feb 2004 23:43:27 +0100

Hi,

> > > tunnels to find out how many tunnels
[..]
> 	between RFC2893 tunnel and GRE with respect to address spoofs and stuff,

If I understood him correctly, because GRE can do sequence numbering and
keying.  So you need more information to successfully spoof that.

Gert Doering
        -- NetMaster