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

[Hugh Holbrook <[e-mail]>]

Thanks for your comments, Pekka.  My responses inline.

> Date: Thu, 6 Mar 2003 12:31:55 +0200 (EET)
> From: Pekka Savola <[e-mail]>
> Cc: [e-mail]
> 
> On Sun, 2 Mar 2003, Hugh Holbrook wrote:
> > I've just submitted draft-ietf-ssm-arch-02.txt to the internet draft
> > repository.  Until it shows up, you can retrieve it from
> > 
> >     http://sith.maoz.com/SSM/draft-ietf-ssm-arch-02.txt
> > 
> > There were enough changes to the draft that I'd like to do one more
> > working group last call.  I've included below the list of changes from
> > my last mail.  The only other change was that I changed a SHOULD (for
> > ignoring non-source-specific requests) in section 8 to a MUST, to be
> > consistent with Section 5.2.
> > 
> > I would particularly appreciate any comments on the Security
> > Considerations section, as this has seen the least review.
> 
> I've reviewed the draft.  It looks mainly good, but unless I 
> misunderstand, there are still a few issues.
> 
> One particularly big issue is how to deal with IPv6's non-globally scoped 
> addresses (sigh!).  You asked for sec cons review, so here's some.. :-)
> 
> substantial
> -----------
> 
> Security Considerations
> 
> ==> 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.

> ==> (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?

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

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

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

> editorial:
> ----------

I will look at the editorial comments and respond in a separate email.
They all look helpful.

Thanks again, Pekka.

-Hugh


> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119 [RFC 2119].
> 
> ==> I believe this should be at the end of Introduction, but not sure..?
> 
> designated as source-specific multicast (SSM) destination addresses and
> are reserved for use by source-specific applications and protocols.  For
> IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for
> Source-Specific Multicast use.  It defines an extension to the Internet
> 
> ==> source-specific multicast vs Source-Specific Multicast -- pick one for
> consistancy
> 
> Using the terminology of [IPv6-UBM], this means that P=1, T=1, and
> plen=0 for any SSM address.
> 
> ==> "means that x=y for any address", is ok but could be a bit better,
> maybe:
> 
> Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and
> plen=0.
> 
> within the FF3x::/96 range, but a system should treat all of FF3x::/32
> as an SSM address, to allow for compatibility with possible future uses
> 
> ==> s/an SSM address/SSM addresses/
> 
> referred to as a "channel."  In contrast to the ASM model of RFC 1112,
> 
> ==> s/."/"./ ?
> 
>   Identifier:           G                   S,G
>   Receiver Operations:  join, leave         subscribe, unsubscribe
> 
> ==> s/subscribe/Subscribe/, s/unsubscribe/Unsubscribe/
> 
> host IP module sends an unsubscription request for that channel out
> interface I.
> 
> ==> s/interface/the interface/, or "on interface".
> 
> address range for IPv4).  For IPv6, the randomization should apply to
> the lower 32 bits of the address.
> 
> ==> s/lower/lowest/ ?
> 
> subscriber would be delivered to another's IP module, which would then
> have to reject the datagram.
> 
> ==> perhaps s/reject/discard/ would be slightly better?
> 
> specify the required  modifications to those protocols to support SSM.
> 
> ==> s/required  /required / (extra space)
> 
> 7.  Security Considerations
> 
> ==> add a 1-2 line summary of the subsections here.
> 
> To reduce the damage from such an attack, a router MAY have
> configuration options to limit the following items:
> 
> ==> s/limit/limit, for example,/ ?  the list is not meant to be exclusive,
> and it's a MAY after all..
> 
> risks unduly burdening the network infrastructure by deliver (S,G)
> 
> ==> s/deliver/delivering/
> 
> -- 
> 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
_______________________________________________
ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm