Re: [Gen-art] Gen-ART LC Review of draft-ietf-pim-lasthop-threats-03.txt

[Pekka Savola <[e-mail]>]

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