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

Tom Yu <tlyu@MIT.EDU> Sun, 08 June 2014 16:30 UTC

Return-Path: <tlyu@mit.edu>
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 43EB51A0089; Sun, 8 Jun 2014 09:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.352
X-Spam-Level:
X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 7kSDGZuieRWF; Sun, 8 Jun 2014 09:30:55 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1F11A0114; Sun, 8 Jun 2014 09:30:55 -0700 (PDT)
X-AuditID: 1209190c-f79946d000000c3b-9a-53948fbe2ba4
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.9D.03131.EBF84935; Sun, 8 Jun 2014 12:30:54 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s58GUqCT028412; Sun, 8 Jun 2014 12:30:53 -0400
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s58GUnbM025816; Sun, 8 Jun 2014 12:30:50 -0400
From: Tom Yu <tlyu@MIT.EDU>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-multicast-scopes.all@tools.ietf.org
Date: Sun, 08 Jun 2014 12:30:49 -0400
Message-ID: <ldvlht7weh2.fsf@sarnath.mit.edu>
Lines: 59
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUixG6nrruvf0qwQdNiEYsp9+ayWsz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8aMhnPsBe1SFT17ljI3MK4W7WLk 5JAQMJF49/g+K4QtJnHh3nq2LkYuDiGB2UwSr28uZoVwNjBKbPy7ECrzmlHizPnvLF2MHBxs AtISRxeXgXSLCCRIPD+6jwXEFhawlbj+aimYzSKgKjHr7m4mEJtXQFdiRdtjJpBWHgFOiSVL 4yHCghInZz4BK2cW0JK48e8l0wRG3llIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3S NdTLzSzRS00p3cQICihOSZ4djG8OKh1iFOBgVOLhTeieHCzEmlhWXJl7iFGSg0lJlFekakqw EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFelyagHG9KYmVValE+TEqag0VJnPettVWwkEB6Yklq dmpqQWoRTFaGg0NJgndRH1CjYFFqempFWmZOCUKaiYMTZDgP0HBzkBre4oLE3OLMdIj8KUZF KXHeBb1ACQGQREZpHlwvLOJfMYoDvSLMqw7SzgNMFnDdr4AGMwEN/pU5EWRwSSJCSqqBkc2O 1ffVP7slv3duVr9btGrRhW3R5TurnYQDnpxfwL2OZffUDfvYE2bUaGr8b950Z1OW/5xKt7db 8p0rz7qHy7nJpDy6kLipYcuMC3f0lsdtmG8+LV4pjO9Nhf+F+W7c9ffjvtw4WjNl4vF1/zr+ yV19KHDZaoZHrnTXbGO3/fpn9thPuPN660YlluKMREMt5qLiRAAYyLuK0wIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/y0Of3fFOHdw2PUrNm948CgZ3wws
Subject: [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: Sun, 08 Jun 2014 16:30:57 -0000

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.