Return-Path: <brian@innovationslab.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id B04891A007F;
 Tue, 10 Jun 2014 05:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id aFzVmjJ28Z1m; Tue, 10 Jun 2014 05:20:27 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id CE7851A009C;
 Tue, 10 Jun 2014 05:20:13 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com
 [206.197.161.158])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by uillean.fuaim.com (Postfix) with ESMTP id 96B37880E2;
 Tue, 10 Jun 2014 05:20:13 -0700 (PDT)
Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132])
 (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 by clairseach.fuaim.com (Postfix) with ESMTP id 1B3C113680F2;
 Tue, 10 Jun 2014 05:20:13 -0700 (PDT)
Message-ID: <5396F7F4.8030507@innovationslab.net>
Date: Tue, 10 Jun 2014 08:20:04 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Tom Yu <tlyu@MIT.EDU>
References: <ldvlht7weh2.fsf@sarnath.mit.edu>	<5395A8D9.2070006@innovationslab.net>
 <ldvwqcpv1cd.fsf@sarnath.mit.edu>
In-Reply-To: <ldvwqcpv1cd.fsf@sarnath.mit.edu>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="7Tw40QAwjFRh8e9vGB5126agqtiW048gL"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/eDbQCgsK6SrZChHk648fFsnaDCI
Cc: iesg@ietf.org, draft-ietf-6man-multicast-scopes.all@tools.ietf.org,
 secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-6man-multicast-scopes-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>,
 <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>,
 <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jun 2014 12:20:31 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--7Tw40QAwjFRh8e9vGB5126agqtiW048gL
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Tom,

On 6/10/14 12:24 AM, Tom Yu wrote:
> Brian Haberman <brian@innovationslab.net> writes:
>=20
>>      I do think that the rules in RFC 4007 adequately cover the bounda=
ry
>> handling for realm-scoped multicast addresses.  The general rule defin=
ed
>> in 4007 is that a multicast packet is forwarded if there is forwarding=

>> state and a scope boundary is configured on the router that is equal t=
o
>> or greater than the scope contained in the multicast packet.
>=20
> I'm not sure I see where that behavior is defined in RFC 4007, but
> perhaps I lack context or am misreading something.  What happens when a=

> router receives a packet destined for an address having scope=3D3, but =
the
> router doesn't have an explicitly-configured zone boundary for that
> scope and also doesn't understand realm-local scope?  Would it drop the=

> packet (no routing information for the unconfigured zone of scope=3D3) =
or
> restrict it to the largest zone of lower scope (protect inter-zone
> integrity)?

I think the context needed is in the second list in section 5 of 4007.
If a router does not have a boundary instantiated for scope=3D3 *or
larger*, the packet would be forwarded if forwarding state exists for
the multicast address.  If no forwarding state exists for that address
or a boundary exists for scope>=3D3, the packet is dropped.

>=20
> Wouldn't forwarding that packet within a larger zone and scope cause th=
e
> packet to possibly leave its intended zone, where its destination
> address might have a meaning unintended by the sender?
>=20

There are two rules in 4007 that cover this...

   o  Zones of the same scope cannot overlap; i.e., they can have no
      links or interfaces in common.

   o  A zone of a given scope (less than global) falls completely within
      zones of larger scope.  That is, a smaller scope zone cannot
      include more topology than would any larger scope zone with which
      it shares any links or interfaces.

Regards,
Brian


--7Tw40QAwjFRh8e9vGB5126agqtiW048gL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJTlvf7AAoJEBOZRqCi7goqUw4H/1p446pjvUi+0tCmSh7QQ0iO
in7vUzOJ2YemVjXl9pKsjV6Jtba1Lakj1RHfPOt5vgKsSeYwEJuaLX7wRQpzdn/f
Vs0eGUQ0IDldpGKb35Gz+E+vypZXo2g3jevA9VMzmZo2KHeSG9vxENS0OQ8FvRoc
JQITIpUJ0qBB570AfQNiQDfI5fBb6+S4SnKi3pmilCQkjINRu5LLI4ldD6CCNc69
cILEtxTQilC1rPMtJrTOaFvCBmG8In2FVN5tQa+3+vc3DBoHTJdZwzUEhI1ccybb
ZwBpvj7FHzxmmfEJ/b8Kh8VVkKmhVRTHYu7W+lbCGUQY1/DeJGfiio6axhFx/j8=
=3Zew
-----END PGP SIGNATURE-----

--7Tw40QAwjFRh8e9vGB5126agqtiW048gL--

