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

[Pekka Savola <[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?

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

...

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

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.

editorial:
----------


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