Subject: Re

From: [email-masked]
Date: Wed, 18 Dec 2002 02:06:23 -0500 (EST)

> Date: Tue, 17 Dec 2002 15:45:07 -0500 (EST)
> From: [email-masked]
> 
> 
> Comments below.
> 
> I just noted one additional issue:
> 
> Note that
> there is no possibility of address conflict between hosts in different
> administrative domains (or between two hosts of any kind).
> 
> ==> this does not seem to hold if S is of non-global scope, ie. site-local 
> IPv6 address or RFC1918 IPv4 address.  Has this been considered at some 
> point?

I will grant you that this paragaph doesn't really adequately address
IPv6, given that scoping *does* exist for IPv6.  I'll fix that.

In the context of IPv4, I think I was trying to make the following
point with this rather cryptic sentence:

At least one of the reasons to use scoping in ASM doesn't apply to
SSM.  In ASM, one of the benefits of scoped addresses is that they
allow hosts in two different domains to be able to allocate multicast
addresses for local use in their respective domains without talking to
one another (or to Dave Meyer) and without risking that they may
choose conflicting addresses.  But this use of scoping doesn't apply
to SSM because you already get uniqueness of channels by piggybacking
on the uniqueness of source addresses.

I could put a paragraph stating this into the draft, but this argument
isn't really even conclusive, and I'm afraid it would raise as many
questions as it answers:  What other motivations for admin scoping
might apply other than this one?  Do we really need
admin scoping for IPv4?  What applications might use scoping and
what range the addresses would the scoped addresses ranges come from
and so on...  I don't want to go there in this document.

So in the interests of keeping the draft short, and given that the
sentence is confusing and doesn't really add information, how about if
I just strike it.

Here's a proposed change that is pretty close to what you wrote below.

  For IPv6, administratively scoped SSM addresses are created by
  choosing an appropriate scope identifier for the SSM destination
  address.  Normal IPv6 scope boundaries are applied to
  traffic sent to an SSM destination address.
  
  No globally agreed-upon administratively-scoped address range
  [ADMIN-SCOPE] is currently defined for IPv4 source-specific multicast.
  For IPv4, administrative scoping of SSM addresses 
  can be implemented within an administrative domain by filtering
  outgoing SSM traffic sent to a scoped address
  at the domain's boundary routers.

> On Tue, 17 Dec 2002, Hugh Holbrook wrote:
> > > No globally agreed-upon administratively-scoped address range [ADMIN-
> > > SCOPE] is currently defined for source-specific multicast.  Note that 
> > > there is no possibility of address conflict between hosts in different  
> > > administrative domains (or between two hosts of any kind).
> > > Administrative scoping of SSM addresses can be implemented within an
> > > administrative domain by filtering at domain boundary routers.
> > > 
> > > ==> this seems to be an obvious oversight.
> > > Administrative scoping for SSM is very much existant for IPv6.
> > 
> > It's there in v6 because it just falls out of the IPv6 addressing
> > architecture.  I'm not personally convinced that there is a need for
> > an administratively scoped SSM address range.  I'd like to hear
> > arguments, though.
> > 
> > If the working group comes to an agreement that we should provide
> > admin scoping for SSM in IPv4, I'd like to defer the details to a
> > separate draft and not hold this one up.  I think it will be fairly
> > contentious trying to nail down the specific admin-scoped SSM address
> > ranges.
> > 
> > Assuming that we defer admin-scoping to a separate draft, is there any
> > text change you'd like to see in *this* draft?
> 
> I totally agree that we should not try to specify IPv4 admin-scoped SSM
> addresses (I fail to see many uses for these -- perhaps a hesitancy to 
> just pick something from the SSM /8 to use with you S).
> 
> But concerning IPv6 -- perhaps replace:
> 
> No globally agreed-upon administratively-scoped address range [ADMIN-
> SCOPE] is currently defined for source-specific multicast.  Note that
> there is no possibility of address conflict between hosts in different
> administrative domains (or between two hosts of any kind).
> Administrative scoping of SSM addresses can be implemented within an
> administrative domain by filtering at domain boundary routers.
> 
> with:
> 
> No globally agreed-upon administratively-scoped address range [ADMIN-
> SCOPE] is currently defined for source-specific IPv4 multicast. Note that
> there is no possibility of address conflict between hosts in different
> administrative domains (or between two hosts of any kind). Administrative
> scoping of SSM addresses can be implemented within an administrative
> domain by filtering at domain boundary routers. However, as every IPv6
> multicast address includes 4-bit scope value, administrative scoping of
> IPv6 SSM addresses can also be done by choosing an appropriate scope 
> value.
> 
> ...
> 
> Hmm.. I wonder whether this leaves too many assumptions about 
> implementations actually honoring those scope values -- and whether this 
> would have to be reflected in the security considerations, with like:
> 
> If an IPv6 SSM (S,G) channel is administratively scoped using only the 
> scope value, there is a possibility of them leaking outside of the scope, 
> the same as with Any-Source Multicast.

I don't think we need say this -- there are no new security
considerations for scoping and SSM that don't already apply to ASM.

Thanks for the comments and careful reading.

-Hugh