Re: [secdir] SecDir review of draft-ietf-pim-group-rp-mapping-08

[Bharat Joshi <[e-mail]>]

Hi Vincent,

     Thanks for your comment. Please see in line for my response.

Regards,
Bharat
 
> The current security consideration section is extremely limited.
> I understand that the additional risks introduced by the current
> specification are limited. I also understand that securing PIM is a
> problem by itself, that is well beyond the goals of this section
> (e.g. it is currently being considered in the KARP WG).

Yes. I agree.
 
> However I'd appreciate if the authors can improve the current section:
> 
> ** clarify that the main risk is the fact different RPs be selected for the
> same group. Is there anything else? E.g. can forged control messages
> lead PIM routers to point to a non existing RP for some (all?) groups
> which would cause a DoS? (I have no idea if this is feasible or not, it's
> just an example).
>

If a different RP is selected, a PIM join/prune message will be sent to this RP which may not be the RP for the group in PIM join/prune message.

A forged control message from which a group-to-rp mapping is learned, will be used by the algorithm defined in this document. But we have not added such information in this draft because the forged message should have been handled as defined in RFCs that has defined this particular mechanism which was used to learn this group-to-rp mapping? This is what is mentioned in the draft as well.

Do you think we should explain some more here? 

> ** the following sentence is ambiguous.
>    "The updated algorithm will not completely prevent the possibility of
>     different routers selecting different group-to-rp mappings for the
>     same group."
> It suggests (but does not say explicitly) that the updated algorithm
> reduces the possibility of selecting different RP for the same group.
> Is it the case?
> 

Actually this sentence is trying to say that routers using this algorithm can come up with a different RP for a given group if the group-to-rp mappings learned by various methods are not same. Now this can be avoided if we keep these various methods consistent and secure across all routers.

> ** the last sentence is the key sentence and it MUST be developed.
> What does:
> "if various mechanisms [...] are secure and consistent across the network"
> mean? You don't have to give answers (as I said it's a problem by itself
> that deserved a specific WG to be created). However you can give a
> few pointers, and illustrate with a simple attack that can make the
> choice incoherent across the network, etc.

Ok. Do you think the following paragraph instead of what is there in the draft looks better:

<<<

   This document enhances an existing algorithm to deterministically
   choose between several group-to-rp mappings for a specific group.
   Different routers may select different group-to-rp mapping for the same group
   if the group-to-rp mappings learned in these routers are not consistent. For
   example: let us assume that BSR is not enabled in one of the router and so it 
   does not learn any group-to-rp mappings from BSR. Now as the group-to-rp 
   mappings learned in this router is not consistent with other routers in the 
   network, it may select a different RP or may not select any RP for a given group. 
   Such situations can be avoided if various mechanisms used to learn group-to-rp
   mappings are secure and consistent across the network.

>>>

Is the above good enough? If not, can you suggest something?

> I hope these comments are useful.

Yes. They surely are.

> ---
> Two typos:
> 
> * section 2: "Wherever this term in used in this document..." -> "is"

Yes. Will fix.

> * section 6: it is said (bullets 5, 6 and 7):
>         *  If there is only one entry available then that is selected as 
> Group-to-RP mapping.
> I suggest: "... then that entry is selected..."

Yes. Will fix.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***