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

From: Vincent Roca <[email-masked]>
Date: Tue, 04 Jan 2011 15:58:58 +0100

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

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).

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).

** 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?

** 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.

I hope these comments are useful.
Regards,

    Vincent

---
Two typos:

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

* 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..."

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 6 Jan 2011 10:55:02 +0530

Hi Vincent,

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

Regards,
Bharat
 
> (e.g. it is currently being considered in the KARP WG).

Yes. I agree.
 
> which would cause a DoS? (I have no idea if this is feasible or not, it's

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? 

> reduces the possibility of selecting different RP for the same group.

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.

> 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.

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

Yes. Will fix.

> 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***