Re: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24

[Pekka Savola <[e-mail]>]

Hi, sorry for delay,

(Brian: sorry for the intrusion, note an issue about IPv6 Scoped Address
Architecture below.)

On Thu, 6 Mar 2003, Hugh Holbrook wrote:
> > ==> should one mention again the fact that IPv4 admin scoping is to be done
> > differently for SSM if it is requested?
> 
> Sure, we could more or less repeat the text from 4.3 again in the
> Security Considerations, although part of why I didn't mention it
> there is that the Security Considerations section of RFC 2365 (The
> admin-scoping RFC) is very clear that they administrative scoping
> should not be used as a security measure.  (Although I think in
> practice people use it that way often enough.)  So I'm having a hard
> time figuring out what the message should be on this point.
> 
>   Perhaps something to the effect of:
> 
>   Admin-Scoping is not a security measure, but in
>   case you are using it as one anyway, remember that SSM doesn't 
>   have an admin-scoped range.
> 
> (obviously not this exact text.)  If you have some specific ideas for
> text, that would help.

Yeah, it is used too much as a rough security mechanism, so I think some
text is would be good.  What you say above looks quite good, perhaps like:

Administrative scoping should not relied upon as a security measure
[ADMIN-SCOPE]; however, in many cases it is at least a part of security
solutions.  It should be noted that no administrative scoping exists for
IPv4 source-specific multicast.  An alternative approach is to configure
manual access-lists to create such scoping if necessary.

> > ==> (also a part of the main doc, but..) one thing I'd maybe like to see is
> > how SSM is treated with non-global IPv6 addresses.  Perhaps it has to say
> > something like that the scoping must also be done based on the rules for
> > unicast addresses of S.  In particular, (S,G) = (fe80::1%eth0, ff3e::1) is
> > clearly invalid outside of the link-local zone where it originated.
> 
> So, today the document says this "Normal IPv6 multicast scope
> boundaries are applied to traffic sent to an SSM destination address."
> 
> I thought this was sufficient -- as I understand it, a router isn't
> allowed to forward an SSM packet across a scope boundary of either the
> source or the destination address.  I think this is exactly how scoped
> unicast works (and how ASM works), so do we really need any special
> rules for SSM?

Perhaps Brian Haberman, as a co-author of scoped address architecture, can 
comment on this.

You're right that this is not really SSM-specific except in one fashion:  
sources indicate interest in (S,G) channels, not just G.  So, what if on a
web page someone publishes a channel with (fe80::1, ff3e::1) -- or the
same for site-local addresses?  This is one area which does seem 
SSM-specific. 
 
> > Another
> > potential issue is whether the unicast scope must at least equal that of the
> > multicast address.  There are also some other unicast scoping issues to
> > consider, but they might make the those are rather complex and maybe not
> > worth the effort.
> 
> I thought about this and looked at the IPv6 default address selection
> document (draft-ietf-ipv6-default-addr-select-09.txt) for guidance
> when I last revved the document.
> 
> My rationale for *not* saying that the unicast scope must be as large
> as the multicast scope is that this restriction does not appear to be
> required (as far as I can tell) for IPv6 unicast or IPv6 ASM, and I
> didn't see a reason for SSM to be special in this regard.  On a host
> with multiple addresses, I suppose we could say that the source
> address selection rules of draft-ietf-ipv6-default-addr-select-09
> probably SHOULD be followed when picking the SSM source, but again, I don't
> really think this is an SSM-specific issue.
> 
> But I'm open to ideas.

The problem as above seems to be that the source address for a channel 
needs to be published in some fashion.  Publication of non-unique (S,G) 
may be a problem.  Of course, one could argue that this is not so much 
different from publisting an admin-scoped ASM G..

I'm not sure what to think of this issue -- so other comments would be 
useful.
 
> > Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses
> > with prefix FF3x:: are reserved for services with wide applicability
> > 
> > ==> the prefix length is FF3x::/32, I think, must state here!
> > 
> > Addresses in the
> > range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM
> > addresses, per [IPV6-UBM].  The treatment of a packet sent to such an
> > invalid address is undefined -- a router or host MAY choose to drop such
> > a packet.
> > 
> > ==> the above seem to be clearly wrong -- I see *nothing* in IPV6-UBM that 
> > says so!?
> 
> Ok, so you're right about this not being stated in IPv6-UBM.  It is
> actually the combination of [IPV6-UBM] and [IPV6-MALLOC] that together
> imply that these are invalid SSM addresses.  The problem is that
> IPV6-MALLOC says that the 0x00000001 to 0x3fffffff must have P=0 and
> T=0, but IPv6-UBM says that all SSM addresses must set P=1 and T=1.
> This is the rationale for calling these invalid addresses.
> 
> So perhaps this needs to be clarified in the document, then.

It seems to me that this would imply that no such reserved range exists 
for SSM?

This seems like an issue that we must be very careful of, so that no one 
could say this document is trying to usurp either Proposed Standard.

Brian as an author for both can probably clarify at least on the intent.
 
> > An incoming datagram destined to an SSM address MUST be delivered by the
> > IP module to all sockets that have indicated (via Subscribe) a desire to
> > receive data that matches the datagram's source address, destination
> > address, and arriving interface.  It MUST NOT be delivered to other
> > sockets.
> > 
> > ==> is arriving interface checked for ASM?  I'm not sure -- if not, I don't
> > see why it should be done for SSM.
> 
> I think it is -- it's part of the service interface specified in
> IGMPv3:
> 
> Here's a quote from RFC3376, section 2, under the "interface" bullet.
> 
>    ... a system's IP service interface must support the following operation:
> 
>       IPMulticastListen ( socket, interface, multicast-address,
>                           filter-mode, source-list )
> 
>    where:
> 
>    ...
> 
>    o "interface" is a local identifier of the network interface on which
>      reception of the specified multicast address is to be enabled or...
>      If reception of the same multicast address is desired on more than one
>      interface, IPMulticastListen is invoked separately for each desired
>      interface.
> 
> I think it's pretty clear from the last sentence that reception is
> specific to the interface on which it is requested.  A scenario where
> this might matter is the one in which a host has two interfaces
> pointing into two private networks, both using site-local addresses
> with potentially overlapping SSM channels.

Agree, no changes etc. needed.

HTH, thanks.

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