Re: [secdir] secdir review of draft-ietf-6man-multicast-scopes-05
Tom Yu <tlyu@MIT.EDU> Tue, 10 June 2014 04:24 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 BC6C51A0396; Mon, 9 Jun 2014 21:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level:
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oVS-W9oyR2EN; Mon, 9 Jun 2014 21:24:24 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091DB1A0398; Mon, 9 Jun 2014 21:24:23 -0700 (PDT)
X-AuditID: 1209190e-f79946d000000c39-d7-53968876d6f8
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.7C.03129.67886935; Tue, 10 Jun 2014 00:24:23 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s5A4OLf8025995; Tue, 10 Jun 2014 00:24:22 -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 s5A4OIVd001227; Tue, 10 Jun 2014 00:24:19 -0400
From: Tom Yu <tlyu@MIT.EDU>
To: Brian Haberman <brian@innovationslab.net>
References: <ldvlht7weh2.fsf@sarnath.mit.edu> <5395A8D9.2070006@innovationslab.net>
Date: Tue, 10 Jun 2014 00:24:18 -0400
In-Reply-To: <5395A8D9.2070006@innovationslab.net> (Brian Haberman's message of "Mon, 9 Jun 2014 08:30:17 -0400")
Message-ID: <ldvwqcpv1cd.fsf@sarnath.mit.edu>
Lines: 20
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nolveMS3YYHE7s8XMnn+MFlPuzWW1 mPFnIrPFh4UPWRxYPJYs+cnkMfP4FxaPL5c/swUwR3HZpKTmZJalFunbJXBlHDiXXfCKo6Kj p4mtgXE6excjJ4eEgInEtYYdjBC2mMSFe+vZuhi5OIQEZjNJbOnaxgLhbGSUuHHlLyOE84ZR 4s2HJUBlHBxsAtISRxeXgXSLCOhKNHasYAGxmQXSJO6d3MwMYgsLOEpMXLQRbIOQQKjEhS3X weIsAqoSRzv7weKcAsUSzc03mEFG8gLNmT0xAiTMI8Apsej3PDYQm1dAUOLkzCdQ47Ukbvx7 yTSBUWAWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxgkKVU5Jv B+PXg0qHGAU4GJV4eC0OTA0WYk0sK67MPcQoycGkJMqbVDYtWIgvKT+lMiOxOCO+qDQntfgQ owQHs5IIL+tHoHLelMTKqtSifJiUNAeLkjjvW2urYCGB9MSS1OzU1ILUIpisDAeHkgSvcTvQ UMGi1PTUirTMnBKENBMHJ8hwHqDhvm1ANbzFBYm5xZnpEPlTjIpS4rx7QRICIImM0jy4Xlgq ecUoDvSKMK8byAoeYBqC634FNJgJaLBoBMjVxSWJCCmpBsb8+10rWSLaoyw3Tue+3LfviOH+ xn2uejX+R/jvsa9La9lqyqD42HxdbclKuQOehyucJlgtiXo9x+eq5wk+nlkeXx8uyJ7DO8Fh JesFje64xNPTvrzfFZX0f/O35mcRTkY9pq7fZxhPvfTB/ua5F/nCrDbSp1nCymZtjXphY74z +PX8FraFgo+VWIozEg21mIuKEwFqeU4XAAMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xuvY8CrQkclV5WRHuQeKBNG_PQo
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 04:24:25 -0000
Brian Haberman <brian@innovationslab.net> 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)? 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?