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

[Pekka Savola <pekkas@netcore.fi>]

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