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

[Hugh Holbrook <[e-mail]>]

Thanks again for your comments, Pekka.

It sounds like you're primarily concerned with the scenario where
some router either does not implement scoping as per [SCOPED-ARCH],
or only implements part of it (either for unicast or for dest addrs).

I see how such an implementation can violate scoped boundaries, but
I'm having a hard time coming up with any text that is not a tautology.  I
keep getting writing non-informative sentences like "if source address scoping
is not implemented on domain border routers, then source address
scopes will not be enforced for SSM traffic."  Here's the best I've
been able to come up with so far.  Does this capture you're concerns.

  Neither source nor destination address scoping should not be used as
  a security measure.  In some (many?) currently-deployed IPv6 routers (that 
  do not conform to [SCOPED-ARCH]), scope boundaries are not applied
  to the source address.  Such a router may incorrectly forward an 
  SSM channel (S,G) through a scope boundary for S.

(Of course this is less likely to happen than one might think at first
because, when forwarding a join, a router typically does a destination
lookup on S to figure out the next hop....)

This is slightly less tautological, I guess.  I'd welcome improvements
or any alternative text, though.

-Hugh
----------------------------------------------------------------

> Date: Wed, 12 Mar 2003 23:23:26 +0200 (EET)
> From: Pekka Savola <[e-mail]>
> Cc: [e-mail], <[e-mail]>
> 
> 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 guess I don't consider this "an implementation of scoped addressing."

> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm