Re: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...]
Hugh Holbrook <holbrook@cisco.com> Wed, 12 March 2003 20:21 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20605 for <ssm-archive@odin.ietf.org>; Wed, 12 Mar 2003 15:21:21 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKZRS10975 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 15:35:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKZRO10972 for <ssm-web-archive@optimus.ietf.org>; Wed, 12 Mar 2003 15:35:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20550 for <ssm-web-archive@ietf.org>; Wed, 12 Mar 2003 15:20:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKZ2O10952; Wed, 12 Mar 2003 15:35:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKYfO10925 for <ssm@optimus.ietf.org>; Wed, 12 Mar 2003 15:34:41 -0500
Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20517 for <ssm@ietf.org>; Wed, 12 Mar 2003 15:20:03 -0500 (EST)
Received: from holbrook-laptop.cisco.com (sjc-vpn1-426.cisco.com [10.21.97.170]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2CKM5hs018554; Wed, 12 Mar 2003 12:22:11 -0800 (PST)
Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 6AA9510B7A7; Wed, 12 Mar 2003 12:17:41 -0800 (PST)
From: Hugh Holbrook <holbrook@cisco.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Hugh Holbrook <holbrook@cisco.com>, Brian Haberman <bkhabs@nc.rr.com>, ssm@ietf.org
In-reply-to: <Pine.LNX.4.44.0303122128130.15347-100000@netcore.fi>
Subject: Re: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...]
Reply-To: holbrook@cisco.com
Message-Id: <20030312201741.6AA9510B7A7@holbrook-laptop.cisco.com>
Date: Wed, 12 Mar 2003 12:17:41 -0800
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
> Date: Wed, 12 Mar 2003 21:41:27 +0200 (EET) > From: Pekka Savola <pekkas@netcore.fi> > Cc: Brian Haberman <bkhabs@nc.rr.com>, <ssm@ietf.org> > > On Wed, 12 Mar 2003, Hugh Holbrook wrote: > > > One should note that the use of IPv6 scoped addresses either in S or G may > > > cause significant complexities, for example regarding mismatching scopes > > > between S and G or regarding forwarding decisions for a scoped (S,G). > > > The implications of scoped addresses are described in other documents > > > [REF:SCOPED-ARCH] > > > > Isn't the scoping behavior simply that the most restrictive (smallest) > > scope applies. A packet is forwarded neither across a source-scope > > boundary nor across a destination-scope boundary. Unless I'm missing > > something, this actually sounds rather uncomplicated to me. Is there > > something that makes this tricky? > > At the moment, in practise (=implementation), everything related to > scoping is *undefined*, it seems to me. > > How your SSM-enabled router will/would react now, or in 1-2 years is a > complete question mark. Perhaps I'm not creative enough, but I can't imagine any implementation of scoped addresses that would not apply scope limits to both the source and destination. > > Is there something about this that makes it a Security Considerations > > issue? > > Yes, but only slightly: if people use e.g. site-local addresses as a > security measure, and use SSM with like (<site-local>, global-scope-SSM) > -- for whatever reason, e.g. the use of the same application (and > subsequent G) both site-locally and globally, the forwarding of such > multicasts might *NOT* be limited to your site-local S scope. This is an > uncertainty as the implementation is unclear. I don't dispute that implementations are not complete, but I can't see how the IETF could endorse a scheme in which a join for a site-local address S would allowed to be routed through a scoped boundary for S. S refers to two totally diferent hosts on the two sides of the scope boundary, so it's like sending the join to the wrong host. In fact, I would be ok with putting in text saying that for SSM joins and data, the scope boundaries MUST be applied to the source address in addition to the destination address. > On the hindsight, the text I proposed above seems better fit to some other > section, and something different might be more applicable to security > considerations, like: > > Note that when forwarding or processing SSM, the scope of both S and G > may have to be considered [SCOPED-ARCH]; in particular, if the unicast > scope of S is smaller than respective multicast scope of G, the packets > might end up forwarded outside of the scope of S. Therefore, limited I would prefer not to say this because I think it is not likely to ever be allowed. I'd be happy saying just that "scopes should not be used as a security mechanism..." and leaving it at that. I think it's overkill to say that limited scope addresses must be avoided with SSM, because I think they work fine as long as boundaries are applied to the source as well. -Hugh > scopes should be avoided and must not be used as a security mechanism. > > .. I wonder if that's any better .. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm
- [ssm] another last call for draft-ietf-ssm-arch -… Hugh Holbrook
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: Re: [ssm] another last call for draft-ietf-ss… Hugh Holbrook
- Re: Re: [ssm] another last call for draft-ietf-ss… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: Re: Re: [ssm] another last call for draft-iet… Hugh Holbrook
- [ssm] what to say about scoping for v6 [was ...la… Hugh Holbrook
- [ssm] permanent ipv6 ssm addresses [was ...last c… Hugh Holbrook
- Re: [ssm] permanent ipv6 ssm addresses [was ...la… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: Re: [ssm] permanent ipv6 ssm addresses [was .… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 [was .… Pekka Savola
- Re: Re: [ssm] what to say about scoping for v6 [w… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: Re: [ssm] what to say about scoping for v6 [w… Pekka Savola
- Re: [ssm] what to say about scoping for v6 Hitoshi Asaeda
- Re: Re: Re: [ssm] what to say about scoping for v… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 Pekka Savola
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: [ssm] what to say about scoping for v6 [was .… Pekka Savola
- Re: Re: [ssm] what to say about scoping for v6 [w… Hugh Holbrook
- Re: Re: [ssm] what to say about scoping for v6 [w… Pekka Savola
- Re: Re: [ssm] another last call for draft-ietf-ss… Hugh Holbrook