I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-pim-lasthop-threats-04.txt
Reviewer: Eric Gray
Review Date: 6/6/2008
IETF LC End Date: 6/5/2008
IESG Telechat date: Unknown

Summary:

This draft is essentially ready for publishing as an Informational
RFC.  There are minor comments and NITs below which may result in
minor editorial changes which could be handled as RFC Editor notes.

Comments:

This draft was exceptionally easy to read and understand.
_____________________________________________________________________

In the introduction, instead of "host acting as an illegitmate
router", perhaps it should read "any device acting as an ..."?

Later (in the very next section, for example), you say things
like -

"The attacking node may be either a malicious host or an 
 illegitimate router."

- pointing out that (the second occurence of) "host" in the 3rd
paragraph is problematic (since it may be something other than
a host).
_____________________________________________________________________

In the second paragraph of section 2.1, "[RFC3704]" should be
"(see, for example, [RFC3704])" - I am fairly certain there are
other ways to prevent address spoofing (for instance, this RFC
updates, but does not replace, RFC 2827 - which actually is a
more generic reference).  In fact, you may wish to replace RFC
3704 with RFC 2827 (even as an example) simply because it is a
more generic example, but that is your call (especially given 
there are other points at which you also refer to RFC 3704).

NITs:
====

In the abstract, "connecting hosts" -> "connecting to hosts"?
_____________________________________________________________________

In the 1st paragraph of the introduction, should "authorization"
be "authentication"?  Since you also use the same terminology in
section 3.3 (and possibly elsewhere), this may not actually be a
NIT (it may be somewhat more than an editing issue).

I believe the potential for confusion comes up in section 3.3 -
where it is pointed out that there are deployment models where
authorization and authentication are tied together (assuming I
correctly understand the issue raised in the 5th paragraph) for
paid services (presumably something like IPTV).  It is not clear
in what way "authorization" is a legitimate concern with the PIM
protocol (or its associated security vulnerabilities) - opposed 
to a concern for the application of PIM.  I am reasonably sure
that - if you separate authorization and authentication - it is
authentication that needs to be a PIM concern.
_____________________________________________________________________
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to