Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements
draft-ietf-mboned-mroutesec-04

[Note]: 'This document was already reviewed by the IESG. The authors of this document felt
that they could improve the document significantly by adding a single paragraph.
You will only need to review the added paragraph:
''5.4  Passive Mode for PIM'' html diffs are available from:
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-mboned-mroutesec-03-diff.html
&
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-mboned-mroutesec-02-diff.html
(-02 addresses comments raised by ADs)' added by Amy Vezza

[Note]: 'This document was already reviewed by the IESG. The authors of this document felt
that they could improve the document significantly by adding a single paragraph.
You will only need to review the added paragraph:
''5.4  Passive Mode for PIM'' html diffs are available from:
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-mboned-mroutesec-03-diff.html
&
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-mboned-mroutesec-02-diff.html
(-02 addresses comments raised by ADs)' added by Amy Vezza

[Ballot discuss]
Declaring that all issues associated with confidentiality, authentication,
  integrity, and rogue routers to be out of scope is inappropriate for a
  document with this title.  Either cover the material associated with the
  title or change the title to reflect the material that is covered.

  The Abstract needs to reflect the scope of the document.

  The first paragraph of the Security Considerations needs to be rewritten.
  The tone of the paragraph leads the reader to believe that a thorough
  threat analysis was done, and this is not the case.  The introduction
  declares many areas to be out of scope.

[Note]: 'This document was already reviewed by the IESG. The authors of this document felt
that they could improve the document significantly by adding a single paragraph.
You will only need to review the added paragraph:
''5.4  Passive Mode for PIM''

html diffs are available from:
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-mboned-mroutesec-03-diff.html
&
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-mboned-mroutesec-02-diff.html
(-02 addresses comments raised by ADs)' added by David Kessens

[Note]: 'This document was already reviewed by the IESG. The authors of this document felt
that they could improve the document significantly by adding a single paragraph.
You will only need to review the added paragraph:
''5.4  Passive Mode for PIM''' added by David Kessens

[Ballot comment]
I don't understand what the "also" is referring to in the 4th paragraph of section 3.  Is there something that I'm missing that implies a limit to the cases where RPF checks are applicable?

I don't understand section 3.1; the second paragraph says "also note" about something that 3.1.1 is about to describe; perhaps it would better go inside 3.1.1 .  The 3rd paragraph of 3.1 says more or less the same thing as the second half of the 3rd paragraph of 3.1.1, and the one in 3.1.1 is in better context so I'd suggest combining them into the 3.1.1 location.

The 3rd bullet in 3.1.1 says "If the RP does not exist, the join goes to the closest router to the RP" -- the RP does not exist so there is no router closest to it; perhaps it goes to the "closest router to the RP address"?

Section 4.2 consistently uses "unicast-encapsulation" and "unicast-decapsulation" when referring to PIM register encapsulation and decapsulation.  Could it use the term "register" instead of implying it?  (Ideally, I'd like to see "register encapsulation" and "register decapsulation"; if you want to throw the word "unicast" in somewhere I won't object).

In section 5.3, I don't understand any of the descriptions of the token buckets.  They generally follow the form "A rate-limiter which would limit FOO to FOO_MAX per second, with a bucket of FOO_LONG".  The token bucket only limits to FOO_MAX per second once the bucket is emptied, so saying "limit FOO to FOO_MAX per second" is wrong until the bucket is empty.  Perhaps "limit FOO using a token bucket of depth FOO_LONG which refills at FOO_MAX tokens per second"?

[Ballot comment]
>  o draft-ietf-mboned-mroutesec-01.txt
>    PIM-SM Multicast Routing Security Issues and Enhancements
> (Informational) -
>    5 of 6
>    Token: David Kessens
>    REVIEWER: Joel Halpern

This draft is ready for publication as an Informational RFC.

Minor points:

It is a little odd to find the IPR disclosure in the "Status of this Memo"
section, but I suppose it works.

The wording on the second paragraph of 3.2.1 is accurate, but could be
clearer.  In particular, a sentence indicating that many of these threats
are caused by the control interaction that follows from initial data would
go a long way to clarifying this.

Does "The next revisions of this document" text belong in a document
intended for RFC publication?  (The end of section 5.2)

Hey - I didn't hit any "undefer" button - and anyway, there ain't no such beast.
But the doc should have been undeferred automatically after the previous telechat, so the statechange is OK.

[Ballot comment]
Introduction, second paragraph: I don't understand if the author is trying to say that "ensuring confidentiality, authentication and integrity of multicast groups and traffic is out of the scope" of this document and one should refer to [9], or if it's out of scope of [9].  The latter doesn't make much sense, but the text could be worded better to make the point clear.  Something like "ensuring confidentiality, authentication and integrity of multicast groups and traffic is out of scope; please see [9] for details" would be better.

[Ballot comment]
Introduction, second paragraph: I don't undersdtand if the author is trying to say that "ensuring confidentiality, authentication and integrity of multicast groups and traffic is out of the scope" of this document and one should refer to [9], or if it's out of scope of [9].  The latter doesn't make much sense, but the text could be worded better to make the point clear.  Something like "ensuring confidentiality, authentication and integrity of multicast groups and traffic is out of the scope; please see [9] for details" would be better.

[Ballot comment]
2: Expand RP

3: Expand BSR

There should probably be some discussion of adding authentication to the various multicast protocols.  To be sure, that could lead to a CPU DoS -- but that should be discussed, too.

[Ballot comment]
In the summary of threats, I wonder if it might not be better to use "resistant, highly resistant, not resistant, somewhat resistant" instad of good, bad, mediocre, very good and very bad.  As it
stands, the table is pretty easy to misread.