Subject: [magma] WG Last Call: draft-holbrook-idmr-igmpv3-ssm-04.txt

From: Brian Haberman <[email-masked]>
Date: Mon, 28 Apr 2003 07:53:47 -0400

All,
      This is the official start of the MAGMA WG Last Call
to advance draft-holbrook-idmr-igmpv3-ssm-04.txt as a
Proposed Standard.  The Last Call will end on May 12, 2003.
Substantive comments should be directed to the mailing list
and editorial comments to the authors.

Regards,
Brian & Isidor

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Apr 2003 18:35:00 +0300 (EEST)

> and editorial comments to the authors.

A few comments; I'm not well-versed in IGMPv3/MLDv2 so tread with care.
There seem to a be a few rather small issues to be worked out still, but
nothing major.

Substantial:
------------

The GMP module on a host or router SHOULD have a configuration mechanism
to set the SSM address range(s).  If this configuration option exists,
it MUST default to the IANA-allocated SSM range.  The mechanism for
setting this configuration option MUST at least allow for manual
configuration.  Protocol mechanisms to set this option may be defined in
the future.

==> the intent of "The mechanism for setting.." should be made clearer.  
I assume it meants "if a hour or router has a configuration mechanism, it
MUST at least allow manual configuration" -- ie. the MUST is conditional
to the SHOULD, right?

==> note that this seems to be bit in conflict with router reqs in section 
3 (a MAY)

==> IMHO, I question this a bit.  Are there real cases when other SSM 
ranges are really necessary? I can't think of any, and "MAY" would seem 
appropriate.

A host with such a configuration option is described as an "SSM-aware"
host. 

==> so, if a host only supports the default SSM range, it is not 
"SSM-aware"?  This definition seems weird to me.  Perhaps the intention 
was to say it a bit differently.

If the host IP module receives a non source-specific request to receive
multicast traffic to an SSM destination address, the host IP module of
an SSM-aware host SHOULD return an error to the application.

==> "an error"?  Which error in particular?

If an IGMPv1, IGMPv2, or MLDv1 query is received, the SFGMP protocol
specifications require the host to revert to the older (IGMPv1, IGMPv2,
or MLDv1) mode of operation for that destination address.  If this
occurs, the host will stop reporting source-specific subscriptions for
that destination address and will start using IGMPv1, IGMPv2, or MLDv1
to report interest in the SSM destination address, unqualified by a
source address.  As a result, SSM semantics will no longer be applied to
G by the router.

A router compliant with this document would never generate an IGMPv1,
IGMPv2, or MLDv1 query for an address in the SSM range, thus this
situation only occurs if either the router is not compliant with this
document or if the host and the router disagree about the SSM address
range.

==> note that this could also happen if a host on a link sent a query (for 
example, for debugging purposes) to an address.  This would be a DoS 
attack against a host (against the router already mentioned in the sec 
cons).  Not mentioned in security considerations or in [SSM].

In order to mitigate this problem, it MUST be administratively assured
that all routers on a given shared-medium network are compliant with
this document and are in agreement about the SSM address range.

==> s/MUST/must/? (an operational procedure, nothing related to the 
protocol so RFC2119 keyword doesn't fit well).

Editorial:
----------

Holbrook/Cain/Haberman                                          [Page 1]
=0C
INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                2 Mar 2003

==> '=0C' is not a page break,

Abstract

==> should be on the first page if possible (seems like the common 
convention)

of IGMPv3 and MLDv2 to accomodate source-specific multicast.

==> s/accomodate/accommodate/

an SSM-aware host SHOULD return an error to the application.  On a non-
SSM-aware host, an application that use the wrong API (e.g., "join(G)",

==> s/use/uses/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Apr 2003 18:35:00 +0300 (EEST)

Substantial:
------------

Editorial:
----------

Abstract

==> s/use/uses/

---

From: Hugh Holbrook <[email-masked]>
Date: Mon, 28 Apr 2003 09:38:49 -0700 (PDT)

Hi, Pekka.

Thanks for the review.  My comments inline.

> Date: Mon, 28 Apr 2003 18:35:00 +0300 (EEST)
> From: Pekka Savola <[email-masked]>
> Cc: MAGMA Mailing List <[email-masked]>
> 

Thanks.  The intention is to say suggest that a configuration option
should exist.  If a configuration option exists, manual configuration
must be supported (and it must default to the 232/8 range).  A host
may furthermore choose to support some other mechanism that isn't
manual (like listening to the SSM range option in MRD packets).

I'll clarify this and send the text to the mailing list.

The draft explicitly does not state how the manual config and the
protocol mechanism interoperate.  I think the manual config could be
either in addition to or instead of the protocol mechanism depending
on how it is configured.

> ranges are really necessary? I can't think of any, and "MAY" would seem 

I have heard of customres that want to support *only* SSM and do so by
configuring essentially the whole of 224/4 for SSM.  I admit that I
don't see this as strictly necessary.  One could also, for example,
configure security acls for the rest of 224/4 (presumably with special
handling for 224/24).  A more valid use is that I have heard of
customers configuring SSM to operate within the admin-scoped 239/8
range.  As the jury stills seems to be out about admin-scoped SSM in
IPv4, I think "SHOULD support a configuration option" is probably the
right router requirement.

Agree?

> was to say it a bit differently.

How about this:

  A host with such a configuration option or that is otherwise aware of
  the SSM address range is described as an "SSM-aware" host.

> ==> "an error"?  Which error in particular?

I agree -- we should specify this.  My reading of the msf-api draft
leads me to think that EINVAL is the right error code.

Here's a snippet from draft-ietf-magma-msf-api-04:

  When the option itself is not legal on the group (i.e., when
  trying a Source-Specific option on a group after doing
  IP_ADD_MEMBERSHIP, or when trying an Any-Source option without
  doing IP_ADD_MEMBERSHIP) the error generated is EINVAL.

Another possibility might be EPERM.  I'm hoping someone closer to the
msf-api issues or someone with some POSIX API experience can comment
on this.

> cons).  Not mentioned in security considerations or in [SSM].

Sure.  I think it's fair to qualify this with "under normal operating
circumstances" and mention the DoS possibility as well.  I'll come
up with some text.

> protocol so RFC2119 keyword doesn't fit well).

Yep, I'll change it.

I'll fix all the editorial comments in the next revision.  I think the
=0C garbage was some MUA interference when I submitted the draft.

Thanks again for your careful review.

-Hugh

---

From: Hugh Holbrook <[email-masked]>
Date: Mon, 28 Apr 2003 09:38:49 -0700 (PDT)

Hi, Pekka.

Agree?

How about this:

Yep, I'll change it.

-Hugh

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Apr 2003 22:34:09 +0300 (EEST)

Responding to the remaining two issues only.

On Mon, 28 Apr 2003, Hugh Holbrook wrote:
> handling for 224/24).

Does 224/4 handling really work?  It seems to me that'd break with 224/24 
and require special casing too.

To me, this seems like a completely wrong approach, a dirty hack of 
providing a quick failure for ASM apps.

.. because providing SSM under the ASM space is just inviting confusion, 
except ..

> A more valid use is that I have heard of
> IPv4, 

.. in admin-scoped addresses, it *might* be acceptable.  But really, I see 
little need for it even there.  That is because you can build the borders 
easily based on the source, and invent anything from 232/8 for the G.  

However, in the case of a large number of source addresses, handling the 
filtering could be a bit easier done with an admin-scoped G.  So, I can 
see a use here, but not really a necessity.

> I think "SHOULD support a configuration option" is probably the

First of all, note that the router requirement (in section 3) seems to be 
"MAY", and req for both hosts and routers (in section 2) a SHOULD.

I prefer MAY, but due to the the admin-scoped reasoning, I could 
live with a should. 
 
But it would be interesting to hear what others think.

>   the SSM address range is described as an "SSM-aware" host.

Sounds good.
 
> msf-api issues or someone with some POSIX API experience can comment

A possibility is to specify it in the msf-api and add a (normative?) 
reference to it in the igmpv3-ssm draft (and not specify it in this 
document).

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Apr 2003 22:34:09 +0300 (EEST)

Sounds good.

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 30 Apr 2003 15:08:00 -0700 (PDT)

> "MAY", and req for both hosts and routers (in section 2) a SHOULD.

Yep... we need to make the document internally consistent.

> But it would be interesting to hear what others think.

.... So far, total radio silence.... 

Does anyone else out there have an opinion?

> reference to it in the igmpv3-ssm draft (and not specify it in this 

I would also be fine with this.  Any thoughts from the msf-api
authors?

-Hugh

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 30 Apr 2003 15:08:00 -0700 (PDT)

-Hugh

---

From: Pavlin Radoslavov <[email-masked]>
Date: Wed, 30 Apr 2003 17:05:22 -0700

> Does anyone else out there have an opinion?

If the question is whether to use MAY or SHOULD regarding allowing
configuration of other SSM ranges, it seems to me that the only
argument so far in support of SHOULD is if the admin-scoped ranges
for SSM are going to be within the existing admin-scoped 239/8.
Otherwise, I would prefer MAY.

Now, on the question whether the admin-scoped range for SSM should
be within the SSM range of 232/8 or within the existing admin-scoped
range of 239/8.
RFC 2365 already defines 224.0.1.0-238.255.255.255 as
"global scope", but this was before SSM (i.e., when 232/8 was
allocated for VMTP transient groups :)
Hence, it seems to me that you can go either way, by shifting the
configuration compexity between extra SSM-range configuration and
extra admin-scope configuration.

My preference would be that the SSM admin-scope range is within the
original SSM range (232/8), because of the substantial difference
between ASM and SSM (compared to the difference between "scoped" and
"non-scoped" multicast), and because it keeps things cleaner. In
that case, you may need to add additional scope zone configuration
only for your border routers; otherwise you may have to reconfigure
all your routers AND hosts to support SSM within some subrange of
239/8.

Thanks,
Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Wed, 30 Apr 2003 17:05:22 -0700

Thanks,
Pavlin