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:[EMAIL PROTECTED]
> Sent: Thursday, May 08, 2008 3:41 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
>
> 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:[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
