(ngtrans) RE: Directed broadcast in IPv6

Pekka Savola <pekkas@netcore.fi> Thu, 13 December 2001 09:26 UTC

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18885 for <ngtrans-archive@odin.ietf.org>; Thu, 13 Dec 2001 04:26:25 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15210; Thu, 13 Dec 2001 02:24:26 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25548; Thu, 13 Dec 2001 01:24:31 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD9NsvU029960 for <ngtrans-dist@sunroof.eng.sun.com>; Thu, 13 Dec 2001 01:23:54 -0800 (PST)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD9NsCZ029959 for ngtrans-dist; Thu, 13 Dec 2001 01:23:54 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD9NpvU029952; Thu, 13 Dec 2001 01:23:52 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24785; Thu, 13 Dec 2001 01:23:52 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14460; Thu, 13 Dec 2001 02:23:51 -0700 (MST)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBD9NWA26988; Thu, 13 Dec 2001 11:23:38 +0200
Date: Thu, 13 Dec 2001 11:23:32 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Tony Hain <alh-ietf@tndh.net>
cc: Sreeram Vankadari <sreeramv@cisco.com>, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com
Subject: (ngtrans) RE: Directed broadcast in IPv6
In-Reply-To: <IEEOIFENFHDKFJFILDAHIELGDIAA.alh-ietf@tndh.net>
Message-ID: <Pine.LNX.4.33.0112131100280.26383-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Pekka Savola <pekkas@netcore.fi>

On Tue, 11 Dec 2001, Tony Hain wrote:
> Pekka Savola wrote:
> > New addrarch draft says ff0e::/16 is global-scope.
> Where? What I see on page 16 is:
>     Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
>                                      ...
>                                       FF0E:0:0:0:0:0:0:0
>                                       FF0F:0:0:0:0:0:0:0
> 
>    The above multicast addresses are reserved and shall never be
>    assigned to any multicast group.

draft-ietf-ipngwg-addr-arch-v3-07.txt

2.7 Multicast Addresses
[...]
	scop is a 4-bit multicast scope value used to limit the scope of
	the multicast group.  The values are:
[...]
             E  global scope

> > I took this as an example of delivering packets to an IPv6
> > node when it
> > might not be possible to do so directly (example: link-local
> > addresses).
>
> I am not seeing your scenario. Could you send a picture?

Consider Target Node T has two interfaces with two addresses, 
respectively: 2002:0102:0304::1 and 3ffe:ffff:1::1.  The first one is 
"public" and the second is "private".  3ffe:ffff:1::/64 is not routed 
except locally.

Target node T has not enabled packet forwarding between interfaces, or it 
is being strictly limited by firewall policies.

If Attacker A pings 2002:0102:0304::1 it works no problems.  If attacker 
pings 3ffe:ffff:1::1, there is no reply as the network is not reachable to 
the Internet on purpose.

Now, attacker A can craft a packet as follows:

ipv4 source=<something>
ipv4 destination=1.2.3.4
protocol=41
 ipv6 source=<something>
 ipv6 destination=3ffe:ffff:1::1
 [payload follows]

Target node T decapsulated the IPv4 packet and delivers the IPv6 packet to 
3ffe:ffff:1::1 without complaints.  This would not have been possible 
without automatic tunneling mechanisms.

This issue is similar to "Routing Header" discussion in:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt

> > Why would a host have any reason to be 6to4 aware?  I sure
> > would like to
> > know more of this.  AFAICS that implementation wouldn't be
> > honouring RFC
> > 3056 definition of 6to4 host:
> >
> >          an IPv6 host which happens to have at least one 6to4 address.
> >          In all other respects it is a standard IPv6 host.
>
> The RFC 3056 context of a 6to4 host is one that receives an RA which
> contains a 6to4 format prefix. It is also possible that the host has no
> IPv6 router, but includes that function within itself. In the strict
> sense the functions are separate, but the fact that they are in the same
> box results in the case where a 6to4 host may have a 6to4
> pseudo-interface.

I wonder why this definition was chosen.  But regardless, the discussion 
applies, just imagine "6to4 host" being "6to4 host which is not 6to4 
router".  

> > That is, site-local and link-locals
> > would not be a
> > problem with tunneling.
>
> Link local is not to be forwarded off link in any case, and I have
> always believed that site-locals don't go out over the global tunnel
> interface, but there doesn't appear to be a specific statement about
> that in the current documents.

Addrarch 2.5.8 says site-locals must not be forwarded outside of site, and 
upon receipt, should be dropped.

A problem is that one does not know how tunneling is implemented.  If one 
receives a packet from a tunnel, does one apply all the same checks one 
would if the packet had come from the wire?  Or does the implementation 
somehow push the packet through in some quicker way?

Site/link locals are just a curiousity that might or might not work,
depending on the implementation; most of these apply to global addresses
as well, but would require more discussion of the topology.  There are
other issues, like being able to inject IPv6 packets with hop limit = 255
from anywhere in the Internet.

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