On Fri, 6 Jun 2008, Eric Gray wrote: > 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
This is a bit strange, as you already reviewed -03 version about a month ago :-). The timing is also a bit difficult as the document was approved yesterday, pending an RFC-editor note. I'm not sure how to deal with these mostly editorial comments. I don't understand the second comment you're making. Wrt the authentication/authorization issue, both are required even if we mention just authorization, but depending on what your assumptions are about the confidentiality, integrity etc. of multicast data, this is not a PIM issue as such. The reason it's even discussed in 3.3 is that if your security model just expects the routing protocols to handle everything for you (instead of using group security etc. extensions provided by e.g. RFC3740), you're going to be surprised. From PIM perspective this is about only accepting PIM signalling from correct nodes -- maybe this is authentication even if it is authentication by IP address, IPsec SA, etc. Pekka > 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
