Re: [pim] AD Review of draft-ietf-pim-explicit-rpf-vector-06

[Stig Venaas <[e-mail]>]

Hi

I suggest adding text saying that this should be used within a single
management domain so that one cannot inject explicit RPF attributes
from the outside. Also suggest that if a router finds that it cannot
use the vector list due to the next hop not being a PIM neighbor, it
may log an error. Also maybe log if it is overridden due to downstream
routers specifying different lists.

Would this address the security and operational concerns?

Stig


On Wed, Oct 28, 2015 at 12:20 PM, Alvaro Retana (aretana)
<[e-mail]> wrote:
> Sowmya:
>
>
> Hi!
>
> Sorry for being so picky, but the Security section is not there yet.
>
> The new text you added is this:
>
>    ...There is the risk of a malicious node injecting an
>    incorrect Explicit RPF vector stack.  Since the draft does not have a
>    feedback mechanism to the end nodes that are injecting the Explicit
>    RPF vector as to whether the injected path was used or an alternate
>    path was used due to conflict resolution on an upstream node, it is
>    upto the mechanisms that produced the Explicit RPF vector to ensure
>    that the the PIM tree is built correctly.
>
>
> If I was the security AD, I would then ask you to build in that feedback
> mechanism. :-(
>
> The risks that I see are:
> - injecting a incorrect stack (as you mentioned above),
> - topology changes resulting in nodes that don't support this in the path
> - changes in features/support at the nodes (maybe as a result of a crash..)
>
> ...there might be others.  Note that 2 of those risks may still occur even
> if the stack was correct -- but not having that feedback mechanism may
> results in issues (lost traffic, loops, etc.) a long time after the stacks
> were first injected.
>
> Because the programming of the network is external, what about
> authentication and authorization?
>
> Maybe I'm becoming too paranoid, but those are the types of things I'm
> expecting in the Security considerations.  Maybe some text like this:
>
> "The creation of the Explicit RPF Vector list is outside the scope of this
> document.  It is then expected that the mechanisms used create a correct
> list: one that describes a path for the Join message to be propagated
> without looping, that considers only nodes that support the mechanism
> defined in this document, etc..  [IOW, define what "correct" is.]  The
> network administrator should take special care in strictly verifying the
> authentication and authorization of and potential protocol/mechanism used
> to program the network.  Given that even if the path is correct, the
> network topology (for example) can change over time, it is recommended
> that the administrator strictly monitor the network in order to react to
> any events that may require the instantiation of a new list.."
>
>
> Please include something like that and upload the new version (after
> Sunday) and then I'll start the IETF Last Call.
>
> Thanks!
>
> Alvaro.
>
>
> On 10/28/15, 2:17 PM, "Sowmya Krishnaswamy (sowkrish)"
> <[e-mail]> wrote:
>
>>Attaching the latest XML.
>>________________________________________
>>From: Alvaro Retana (aretana)
>>Sent: Tuesday, October 27, 2015 3:18 PM
>>To: Sowmya Krishnaswamy (sowkrish)
>>Cc: [e-mail]; [e-mail];
>>[e-mail]; [e-mail]
>>Subject: Re: AD Review of draft-ietf-pim-explicit-rpf-vector-06
>>
>>Hi!
>>
>>You attached the old version.
>>
>>Alvaro.
>>
>>Thumb-typed and autocorrected..
>>
>>> On Oct 27, 2015, at 3:17 PM, Sowmya Krishnaswamy (sowkrish)
>>><[e-mail]> wrote:
>>>
>>> Please review the Security section and let us know if it's ok.
>