Re: [secdir] SecDir review of draft-ietf-pim-group-rp-mapping-08
Bharat Joshi <bharat_joshi@infosys.com> Thu, 06 January 2011 05:23 UTC
Return-Path: <bharat_joshi@infosys.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843223A6ECD; Wed, 5 Jan 2011 21:23:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.137
X-Spam-Level:
X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPyf48sG3WlC; Wed, 5 Jan 2011 21:23:24 -0800 (PST)
Received: from kecgate06.infosys.com (Kecgate06.infosys.com [122.98.14.33]) by core3.amsl.com (Postfix) with ESMTP id 70B713A68DA; Wed, 5 Jan 2011 21:23:23 -0800 (PST)
X-TM-IMSS-Message-ID: <014a8e8f001ed4e9@infosys.com>
Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 014a8e8f001ed4e9 ; Thu, 6 Jan 2011 10:56:14 +0530
Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Thu, 6 Jan 2011 10:55:03 +0530
From: Bharat Joshi <bharat_joshi@infosys.com>
To: Vincent Roca <vincent.roca@inrialpes.fr>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Date: Thu, 06 Jan 2011 10:55:02 +0530
Thread-Topic: SecDir review of draft-ietf-pim-group-rp-mapping-08
Thread-Index: AcusH/ScoaqYT08AQCOE+lb3nlZ6eABO0Dcu
Message-ID: <31D55C4D55BEED48A4459EB64567589A10811495B1@BLRKECMBX02.ad.infosys.com>
References: <4D2335B2.9030803@inrialpes.fr>
In-Reply-To: <4D2335B2.9030803@inrialpes.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 06 Jan 2011 09:46:04 -0800
Cc: "draft-ietf-pim-group-rp-mapping.all@tools.ietf.org" <draft-ietf-pim-group-rp-mapping.all@tools.ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-pim-group-rp-mapping-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jan 2011 05:23:25 -0000
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***
- [secdir] SecDir review of draft-ietf-pim-group-rp… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-pim-grou… Bharat Joshi