Re: [Gen-art] Gen-ART LC Review of draft-ietf-pim-lasthop-threats-03.txt
"Eric Gray" <eric.gray@ericsson.com> Thu, 08 May 2008 15:43 UTC
Return-Path: <gen-art-bounces@ietf.org>
X-Original-To: gen-art-archive@optimus.ietf.org
Delivered-To: ietfarch-gen-art-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4303A73CA; Thu, 8 May 2008 08:43:43 -0700 (PDT)
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7903A73C8 for <gen-art@core3.amsl.com>; Thu, 8 May 2008 08:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5sjBEEYR4AP for <gen-art@core3.amsl.com>; Thu, 8 May 2008 08:43:37 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6176028D496 for <gen-art@ietf.org>; Thu, 8 May 2008 07:05:06 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m48BjcXq010016; Thu, 8 May 2008 06:45:38 -0500
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 06:45:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 08 May 2008 06:45:36 -0500
Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0303D272@eusrcmw721.eamcs.ericsson.se>
In-Reply-To: <Pine.LNX.4.62.0805081036020.9175@sampo3.csc.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART LC Review of draft-ietf-pim-lasthop-threats-03.txt
Thread-Index: Aciw3uyGMPTevSP7S5iM9NNdVkIIeQAIe68Q
References: <941D5DCD8C42014FAF70FB7424686DCF02BCAEFF@eusrcmw721.eamcs.ericsson.se> <Pine.LNX.4.62.0803311024570.29701@sampo3.csc.fi> <941D5DCD8C42014FAF70FB7424686DCF02BFF1F6@eusrcmw721.eamcs.ericsson.se> <Pine.LNX.4.62.0805081036020.9175@sampo3.csc.fi>
From: Eric Gray <eric.gray@ericsson.com>
To: Pekka Savola <psavola@funet.fi>
X-OriginalArrivalTime: 08 May 2008 11:45:38.0697 (UTC) FILETIME=[092B3790:01C8B101]
Cc: gen-art@ietf.org, James Lingard <jchl@arastra.com>, David Ward <dward@cisco.com>, pim-chairs@tools.ietf.org
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-pim-lasthop-threats-03.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
Pekka, These changes should more than adequately address my concerns. I look forward to seeing the revision. Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Pekka Savola [mailto:psavola@funet.fi] > Sent: Thursday, May 08, 2008 3:41 AM > To: Eric Gray > Cc: James Lingard; David Ward; gen-art@ietf.org; > pim-chairs@tools.ietf.org > Subject: RE: Gen-ART LC Review of > draft-ietf-pim-lasthop-threats-03.txt > Importance: High > > Hi, > > At chairs' suggestion, I used 'illegitimate'. > > Wrt the "outside of the link" issue below, I agree it's not > very crisp, so > I changed the end of that part to say just "Subverting > legitimate routers > is out of scope. Security implications on multicast routing > infrastructure are described in [RFC4609]". What it tried to > point out > was that this doesn't try to describe all the malicious acts > a host could > do (e.g., join a million different multicast groups) as those are > described elsewhere. > > The last sentence is somewhat redundant because it's already > said at the > start of Introduction, so it could be removed completely if it's more > confusing than helpful. > > I'm pushing out a new rev shortly. > > On Mon, 31 Mar 2008, Eric Gray wrote: > > I believe your observations about the use of "unauthorized" > > are essentially correct. Perhaps a better word would be "malign" > > (or "malevolent" or "malicious"?) - but that may actually be less > > well understood. > > > > It is definitely possible that I am being too picky in this > > context, and I could probably live with it as is. I don't think > > anyone who is familiar with the technology is truly going to be > > confused by the current usage - I just found it somewhat jarring > > because it looks like we're touting an unauthorized activity that > > may occur if it is authorized. Not really an exciting observation. > > > > On the first point below, I am not sure that "The impact on > > the outside of the link is described in [RFC4609]" is made much > > clearer by inserting "connecting the host" between "link" and "is" > > - what I am trying to get at is this: what impact do you mean when > > you say impact on the outside of the link (I picture someone taking > > a steak-knife to the insulation). I think what you're saying is > > that you're not considering out-of-band attack vectors - where OOB > > is with respect to the principal "data" connection between a node > > and the network. > > > > In a sense, this relates (I think) to the observation that we > > are not going to address attacks relating to subversion of a valid > > PIM participant (or router) in this document - as one example of an > > attack that might occur by some means other than directly over the > > link from a node to the network. > > > > -- > > Eric Gray > > Principal Engineer > > Ericsson > > > >> -----Original Message----- > >> From: Pekka Savola [mailto:psavola@funet.fi] > >> Sent: Monday, March 31, 2008 3:57 AM > >> To: Eric Gray > >> Cc: James Lingard; David Ward; gen-art@ietf.org; > >> pim-chairs@tools.ietf.org > >> Subject: Re: Gen-ART LC Review of > >> draft-ietf-pim-lasthop-threats-03.txt > >> Importance: High > >> > >> Next steps: I'm expecting a response from Eric (and/or > >> comments from the > >> others) on the use of the word "unauthorized" (below). > Once that is > >> settled one way or the other, someone (not me) could make > a decision > >> whether to push the existing rev to IESG evaluation or > revise at this > >> point. I'll wait advice from DavidW or the chairs before > proceeding. > >> > >> I've added PIM WG chairs to cc:. > >> > >> Eric, thanks for your comments, my responses inline, > >> > >> On Thu, 27 Mar 2008, Eric Gray wrote: > >>> COMMENTS/QUESTIONS > >>> ================== > >>> > >>> I don't understand the following statement (from Introduction, > >>> page 3): > >>> > >>> "The impact on the outside of the link is described in [RFC4609]." > >>> > >>> What is the "outside of the link" in this context? > >> > >> It should probably say, "outside of the link connecting the > >> host". I.e. > >> this document is focused on the first and last hop. The title was > >> slightly revised a couple of revisions back and this should > >> maybe have > >> been reflected at this point. > >> > >>> __________________________________________________________________ > >>> > >>> In section 2, an attacking node is defined to be either a host or > >>> an unauthorized router. This brings up a point - perhaps it is > >>> necessary to point out that attacks based on subversion of an > >>> authorized router are out of scope (in the Introduction)? > >> > >> Good point, this could be added. > >> > >>> __________________________________________________________________ > >>> > >>> "Unauthorized" may not be the right word in section 2.2. The text > >>> in the section seems to imply that enabling PIM on a router's host > >>> interface effectively "authorizes" hosts to become PIM neighbors. > >>> > >>> Perhaps "Nodes May Exhibit Unauthorized Behavior as PIM Neighbors" > >>> or "Nodes May Be Invalid PIM Neighbors" would be more correct? > >>> __________________________________________________________________ > >> > >> Good observation, though the document uses "unauthorized" in > >> many places, > >> in most of Section 2. It would seem that all of those should > >> be changed > >> if 'unauthorized' is not suitable; there are some minor > >> variations on what > >> unauthorized implies in each context but in the higher level > >> view they > >> seem similar. I agree it's not an ideal word but I can't > >> think of better > >> ones: "unauthorized behaviour" is longer and has similar > >> problems with > >> 'unauthorized'. Invalid has a chance to lead the reader > >> astray because > >> invalid often implies that it is a protocol violation. > >> > >> How about "irregular" would be any better? It has more possible > >> interpretations so I'm not sure if it's much better. > >> > >> The thing I'm looking for is "unexpected by the network > >> administrator or > >> the spirit of the PIM-SM specification". > >> > >> If a better word can't be found, maybe this can be left as > >> is, or some > >> clarifying text added at the top of section 2. > Suggestions would be > >> welcome. > >> > >>> There is a bit of confusion in the bullets in section 3.1 (page 6) > >>> - the lead in appears to assume that bullets apply to an attacker > >>> that has managed to have itself elected as the DR, yet the third > >>> bullet doesn't seem to require this. > >> > >> Good observation. First I thought your reading was careless, but > >> re-reading proved me wrong :-). > >> > >>> I would suggest breaking the bit about "even if the router is not > >>> DR" out into a separate paragraph after the bullets (along the > >>> lines of "Sending PIM Prune messages may also be an effective > >>> attack vector even if the attacking node is not elected DR, since > >>> PIM Prune messages are accepted from (on?) downstream interfaces > >>> even in this case.") > >> > >> Yes, this seems like a good suggestion. I'll work on that. > >> > >>> __________________________________________________________________ > >>> > >>> NITs > >>> ==== > >>> > >>> In section 2.1 "as unicast" or just "unicast" as opposed to "by > >>> unicast"? > >>> > >>> ("unicast" is not - AFAIK - an active element or agent capable of > >>> sending [Register] messages...) > >>> __________________________________________________________________ > >> > >> simply "unicast" is probably right. > >> > >> Thanks, > >> Pekka > >> > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART LC Review of draft-ietf-pim-las… Eric Gray
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-pim… Pekka Savola
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-pim… Eric Gray
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-pim… Eric Gray
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-pim… Pekka Savola