Subject: [Gen-art] Gen-ART Last Call Review of draft-ietf-pim-lasthop-threats-04.txt

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Jun 2008 05:34:33 -0500

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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Pekka Savola <[email-masked]>
Date: Fri, 6 Jun 2008 13:57:10 +0300 (EEST)

> 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

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Jun 2008 06:08:34 -0500

Pekka,

	You're right about a previous review, but this was listed as
a re-review on my queue at -

http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

- see for yourself. 

	I am not sure what is strange about it.  If you think there
are no changes required, then there is nothing to add to the RFC
editor's note that exists already.  This is a "ready to publish"
summary, indicating progress relative to the previous review (an
"almost ready to publish" review).  As for the timing, if you look 
at my queue at the above site, you will see that it indicates a 
(re-)review was due yesterday; unfortunately, I did not find that 
out until today. I guess I needed to "refresh" the browser window,
which I did as soon as I saw Mary's E-Mail this morning...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Friday, June 06, 2008 6:57 AM
> To: Eric Gray
> Cc: James Lingard; David Ward; [email-masked]
> Subject: Re: Gen-ART Last Call Review of 
> draft-ietf-pim-lasthop-threats-04.txt
> Importance: High
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 6 Jun 2008 14:30:10 +0300 (EEST)

> which I did as soon as I saw Mary's E-Mail this morning...

By strange I was referring to (1) being chosen to doing a re-review and 
(2) reviewing the whole draft again (instead of just changed parts since 
last review).

To me it would seem that it would be more useful for a reviewer to review 
a new draft rather than to look the same one again in completeness.  But I 
don't know the methology used for reviewer selection in Gen-ART; maybe 
there is a good reason for this.  If you had only been looking at the 
changed parts, that would not have been a surprise (and I believe you 
already did that after the previous revision).

Pekka

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 6 Jun 2008 09:15:59 -0500

I think there's a misunderstanding about the spreadsheet information.
This doc was on the Telechat for June 5th, so the re-review was in
anticipation of the telechat, per the assignments:
http://www.alvestrand.no/ietf/gen/art/reviewers-080605.html
In looking at columns in the spreadsheet, which has evolved overtime to
cover last call reviews, I should rename the current "Status" field to
read "Past Review" and change the default from "New" to "None" to avoid
this sort of confusion going forward.

I will make those changes when I'm back in the office next week.  Sorry
for the confusion this caused.

Thanks,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Gray
Sent: Friday, June 06, 2008 6:09 AM
To: Pekka Savola
Cc: [email-masked]; James Lingard; David Ward
Subject: Re: [Gen-art] Gen-ART Last Call Review of
draft-ietf-pim-lasthop-threats-04.txt

Pekka,

	You're right about a previous review, but this was listed as a
re-review on my queue at -

- see for yourself. 

	I am not sure what is strange about it.  If you think there are
no changes required, then there is nothing to add to the RFC editor's
note that exists already.  This is a "ready to publish"
summary, indicating progress relative to the previous review (an "almost
ready to publish" review).  As for the timing, if you look at my queue
at the above site, you will see that it indicates a (re-)review was due
yesterday; unfortunately, I did not find that out until today. I guess I
needed to "refresh" the browser window, which I did as soon as I saw
Mary's E-Mail this morning...

--
Eric Gray
Principal Engineer
Ericsson