ReMIME-Version: 1.0

[pekkas@netcore.fi]

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?

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.
 
> > Source Routing [RFC791] (both Loose and Strict) in combination with
> > source address spoofing may be used to allow an impostor of the true
> > channel source to inject packets onto an SSM channel.  An SSM router
> > MUST have a configuration option to disable source routing to an SSM    
> > destination addresses, and the default value SHOULD be to disable Source
> > Routing to an SSM destination address.  Anti-source spoofing mechanisms
> > like source address filtering at the edges of the network are also
> > strongly encouraged.
> > 
> > ==> this seems overly specificative to me.  IMO, if the default is to 
> > disable source routing to multicast addresses, I believe there is no need 
> > for a knob.  In any case, this is a bit like an implementation
> > issue.
> 
> I think I agree with you, that mandating a configuration option is not
> really the right way to say this.  Trying to translate your comments
> into text:
> 
>   Source Routing [RFC791] (both Loose and Strict) in combination with
>   source address spoofing may be used to allow an impostor of the true
>   channel source to inject packets onto an SSM channel.  An SSM router
>   SHOULD by default disallow source routing to an SSM destination
>   addresses.  A router MAY have a configuration option to allow source
>   routing.  Anti-source spoofing mechanisms such as source address
>   filtering at the edges of the network are also strongly encouraged.
> 
> Comments?

Seems good to me.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords