Re: [secdir] secdir review of draft-ietf-6man-multicast-scopes-05

Brian Haberman <> Tue, 10 June 2014 12:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B04891A007F; Tue, 10 Jun 2014 05:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aFzVmjJ28Z1m; Tue, 10 Jun 2014 05:20:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE7851A009C; Tue, 10 Jun 2014 05:20:13 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 96B37880E2; Tue, 10 Jun 2014 05:20:13 -0700 (PDT)
Received: from clemson.local ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 1B3C113680F2; Tue, 10 Jun 2014 05:20:13 -0700 (PDT)
Message-ID: <>
Date: Tue, 10 Jun 2014 08:20:04 -0400
From: Brian Haberman <>
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: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7Tw40QAwjFRh8e9vGB5126agqtiW048gL"
Subject: Re: [secdir] secdir review of draft-ietf-6man-multicast-scopes-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jun 2014 12:20:31 -0000

Hi Tom,

On 6/10/14 12:24 AM, Tom Yu wrote:
> Brian Haberman <> writes:
>>      I do think that the rules in RFC 4007 adequately cover the boundary
>> handling for realm-scoped multicast addresses.  The general rule defined
>> 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 to
>> or greater than the scope contained in the multicast packet.
> 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=3, 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=3) 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=3 *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>=3, the packet is dropped.

> Wouldn't forwarding that packet within a larger zone and scope cause the
> packet to possibly leave its intended zone, where its destination
> address might have a meaning unintended by the sender?

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.