Re: [ssm] what to say about scoping for v6 [was ...last call...]

Brian Haberman <bkhabs@nc.rr.com> Wed, 12 March 2003 20:53 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 PAA21786 for <ssm-archive@odin.ietf.org>; Wed, 12 Mar 2003 15:53:19 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CL7QS14124 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 16:07:26 -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 h2CL7QO14113 for <ssm-web-archive@optimus.ietf.org>; Wed, 12 Mar 2003 16:07:26 -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 PAA21748 for <ssm-web-archive@ietf.org>; Wed, 12 Mar 2003 15:52:48 -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 h2CL78O13683; Wed, 12 Mar 2003 16:07:08 -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 h2CL6VO13425 for <ssm@optimus.ietf.org>; Wed, 12 Mar 2003 16:06:31 -0500
Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21712 for <ssm@ietf.org>; Wed, 12 Mar 2003 15:51:52 -0500 (EST)
Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2CKpRm0002724; Wed, 12 Mar 2003 15:51:27 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 12 Mar 2003 15:50:25 -0500
Message-ID: <3E6F9E10.3010907@nc.rr.com>
Date: Wed, 12 Mar 2003 15:52:32 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: holbrook@cisco.com
CC: Pekka Savola <pekkas@netcore.fi>, ssm@ietf.org
Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...]
References: <20030312201741.6AA9510B7A7@holbrook-laptop.cisco.com>
In-Reply-To: <20030312201741.6AA9510B7A7@holbrook-laptop.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hugh Holbrook wrote:
>>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.
> 

Neither can I.  In fact, that is one of the items in the scoped
addressing architecture that everyone agrees on.  Both S & G have
to be checked when a scoped boundary is encountered.

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

I agree that would be dangerous.  The situation is a little muddled
though, in that the PIM protocol would have to do checking of S &
G within the PIM Join/Prune messages.  Of course, the actual
routing protocols will have to do the same too.  So, it seems that
the scenario is already covered and is much larger than SSM.

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

That is what the scoped addressing architecture already says.
Do we need to repeat it?

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

I agree with Hugh on this point.

Brian

_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm