Pekka,

        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:[EMAIL PROTECTED] 
> Sent: Monday, March 31, 2008 3:57 AM
> To: Eric Gray
> Cc: James Lingard; David Ward; [email protected]; 
> [EMAIL PROTECTED]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to