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

Brian Haberman <> Mon, 09 June 2014 12:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1BFE31A00EF; Mon, 9 Jun 2014 05:30:30 -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 UpbKtmIX52lr; Mon, 9 Jun 2014 05:30:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4EA61A0095; Mon, 9 Jun 2014 05:30:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 788BA880E2; Mon, 9 Jun 2014 05:30:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id E014371C0002; Mon, 9 Jun 2014 05:30:26 -0700 (PDT)
Message-ID: <>
Date: Mon, 09 Jun 2014 08:30:17 -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="SSoQ3hkrRcjlQfmlLMUdjd3nA5krmgdHq"
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: Mon, 09 Jun 2014 12:30:30 -0000

Hi Tom,
     Thanks for the review.

     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.

     Since scope=3 has not been explicitly defined in another RFC, the
handling is strictly driven by 4007.  This draft is creating a more
tightly controlled use of scope=3 since it allows for the automatic
creation of a scope boundary where before (i.e., RFC 4007) an
administrator had to manually create the scope boundary.

     I am not sure what we would add to this document, but that is my
$0.02 on the issue.  SEC ADs?


On 6/8/14 12:30 PM, Tom Yu wrote:
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
> Summary: ready with minor issues.
> This document defines the previously reserved IPv6 multicast scop value
> 3 to mean "realm-local scope".  The intent appears to be that
> specifications about how to use IPv6 on top of the underlying link layer
> technology define the extent of realm-local scope.  A potential minor
> security issue is whether a router that does not understand scop 3
> addresses (as specified by this draft) and receives a packet with a scop
> 3 destination address will forward the packet more widely than it
> should, or otherwise behave unexpectedly.  This could be a problem for
> some resource-constrained deployment scenarios envisioned for this
> specification.
> The Security Considerations section of this draft states
>    "This document has no security considerations beyond those in RFC
>    4007 [RFC4007] and RFC 4291 [RFC4291]."
> I think this document potentially increases the security consequences of
> behavior that was previously unspecified by RFC 4007 and RFC 4291.  RFC
> 4291 specifies the behavior of a node that receives a packet with a
> multicast destination address with scop values 0 or F, but not for scop
> 3.  Packets with scop 0 destination addresses must be dropped, and
> packets with scope F addresses must be treated as if they had global
> (scop E) multicast addresses.
> I can find no such previous specification for behavior for scop 3
> packets.  This raises the question of how existing implementations would
> behave if they were to receive packets destined to an address of scop 3,
> and whether this poses any security exposure.  A conservative
> implementation might drop the packets, or treat them as if they had scop
> 2 (link-local).  The requirements on scope zone boundaries specified in
> Section 5 of RFC 4007 appear to make this latter behavior safe.
> On the other hand, Section 4 of this draft updates RFC 4007 to resolve
> an ambiguity about whether scope 3 is automatically or administratively
> configured.  Existing text in RFC 4007 implies that scop 3 zone
> boundaries are administratively configured, while RFC 4291 implies that
> scop 4 (admin-local) is the smallest scope whose boundaries are
> administratively configured.  I don't know whether existing
> implementation behavior creates any practical security impact from this
> ambiguity.
> Because one stated use for realm-local scope is for multicast traffic in
> mesh networks, which seem likely to be resource constrained (in power,
> bandwidth, latency, error rate, etc.), I think it would be useful to
> analyze the resource exhaustion or denial of service potential of mixed
> deployments, where some routers understand the newly specified behavior
> for scop 3 addresses and some do not.  I'm willing to believe that the
> consequences are negligible.  It would be helpful to have a summary of
> known or predicted behaviors of existing implementations regarding scop
> 3 addresses, along with some analysis of how acceptable the security
> consequences of these behaviors are.