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

Pekka Savola <pekkas@netcore.fi> Wed, 12 March 2003 21:25 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 QAA23664 for <ssm-archive@odin.ietf.org>; Wed, 12 Mar 2003 16:25:21 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLdRq17311 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 16:39: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 h2CLdRO17308 for <ssm-web-archive@optimus.ietf.org>; Wed, 12 Mar 2003 16:39: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 QAA23632 for <ssm-web-archive@ietf.org>; Wed, 12 Mar 2003 16:24:50 -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 h2CLdGO17291; Wed, 12 Mar 2003 16:39:16 -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 h2CLc8O17174 for <ssm@optimus.ietf.org>; Wed, 12 Mar 2003 16:38:08 -0500
Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23528 for <ssm@ietf.org>; Wed, 12 Mar 2003 16:23:28 -0500 (EST)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2CLNQQ16561; Wed, 12 Mar 2003 23:23:26 +0200
Date: Wed, 12 Mar 2003 23:23:26 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Brian Haberman <bkhabs@nc.rr.com>
cc: holbrook@cisco.com, ssm@ietf.org
Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...]
In-Reply-To: <3E6F9E10.3010907@nc.rr.com>
Message-ID: <Pine.LNX.4.44.0303122312460.16487-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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>

On Wed, 12 Mar 2003, Brian Haberman wrote:
> >>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.

Different unicast and multicast codepaths? Or..

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

.. not *implementing* scoped address architecture at all while supporting 
SSM?

I certainly don't want to require scoped addrarch for SSM implementation;  
moreover, I don't want to give users the expectation that using e.g.  
(fec0::1, ff3e::1) would just somehow magically get discarded somewhere
near the manually configured site border by SSM routers.

I see a lot of cases.  Most IPv6 routers today, as far as I've looked,
forward site-local source addresses quite nicely anywhere I want..
 
> > 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?

I'd like a mention of why it is a problem better, and leaving the actual 
behaviour undefined or TBD in scoped addrarch.

> >>  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 agree here: it's not likely be allowed, but the *security 
considerations* part of it is that it *does* happen when/if scoped 
addrarch hasn't been implemented in the designated routers etc. -- this 
was a balance between specification status and operational reality.

> > I'd be happy saying just that "scopes should not be
> > used as a security mechanism..."  and leaving it at that.  

If a variation of that where it's explicit that it applies to the source 
address is added, that's ~ok.

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

(For what it's worth, I was referring to unicast S scoped *only*, if it 
makes any difference.)

The point is that I'm having some doubts whether boundaries *are* actually
applied to the source..

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