Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements
RFC 4609

Note: This ballot was opened for revision 04 and is now closed.

(David Kessens) Yes

(Harald Alvestrand) No Objection

Comment (2004-09-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Paragraph 5.4 reviewed by John Loughney, Gen-ART

(Steven Bellovin) No Objection

Comment (2004-06-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Margaret Cullen) No Objection

(Bill Fenner) (was Discuss, No Objection) No Objection

Comment (2004-06-24 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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"?

(Ted Hardie) No Objection

Comment (2004-06-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Scott Hollenbeck) No Objection

Comment (2004-06-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Russ Housley) (was Discuss) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Alex Zinin) No Objection

Comment (2004-06-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
>  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)