Re: mech-v2: decapsulation check updates

["Tom Petch" <nwnetworks@dial.pipex.com>]

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 <pekkas@netcore.fi>
To: v6ops@ops.ietf.org <v6ops@ops.ietf.org>
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.
>
>
>