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

Brian Haberman <brian@innovationslab.net> Mon, 09 June 2014 12:30 UTC

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 1BFE31A00EF; Mon, 9 Jun 2014 05:30:30 -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 UpbKtmIX52lr; Mon, 9 Jun 2014 05:30: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 C4EA61A0095; Mon, 9 Jun 2014 05:30:27 -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 788BA880E2; Mon, 9 Jun 2014 05:30:27 -0700 (PDT)
Received: from 102523917.rudm2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E014371C0002; Mon, 9 Jun 2014 05:30:26 -0700 (PDT)
Message-ID: <5395A8D9.2070006@innovationslab.net>
Date: Mon, 09 Jun 2014 08:30:17 -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>, iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-multicast-scopes.all@tools.ietf.org
References: <ldvlht7weh2.fsf@sarnath.mit.edu>
In-Reply-To: <ldvlht7weh2.fsf@sarnath.mit.edu>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SSoQ3hkrRcjlQfmlLMUdjd3nA5krmgdHq"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/q0d_7kh2_Uy7Qs3WeL8okxcjt_A
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: 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?

Regards,
Brian

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