From nmelam@juniper.net Fri Jun 10 17:58:04 2011 Return-Path: X-Original-To: msec@ietfa.amsl.com Delivered-To: msec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236AE9E8039 for ; Fri, 10 Jun 2011 17:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SgW-79ZVBOi for ; Fri, 10 Jun 2011 17:58:03 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 640B59E802C for ; Fri, 10 Jun 2011 17:58:03 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTfK9msDrunXUFH/EmyV6FadZYEtqPiye@postini.com; Fri, 10 Jun 2011 17:58:03 PDT Received: from juniper.net (10.150.59.109) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Jun 2011 17:54:48 -0700 Date: Fri, 10 Jun 2011 17:54:46 -0700 From: Suresh Melam To: Message-ID: <20110611005446.GA6618@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stephen Hanna Subject: [MSEC] Comments on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 00:58:04 -0000 Hi, I've looked at the Appendix C. and some of the other related changes. These changes look good and makes the GDOI protocol more robust. While obviously Juniper hasn't already implemented these changes yet, they are not in conflict with what was already done. One comment, ----------- In Sec: 5.6.4.3. Group Member Semantics The SID_VALUE attribute value distributed to the group member MUST be used by that group member as the SID field portion of the IV for all Data-Security SAs including a counter-based mode of operation distributed by the GCKS as a part of this group. When the Sender-Specific IV (SSIV) field for any Data-Security SA is exhausted, the group member MUST no longer act as a sender on that SA using its active SID. The group member SHOULD re-register, at which time the GCKS will issue a new SID to the group member, along with either the same Data-Security SAs or replacement ones. The new SID replaces the existing SID used by this group member, and also resets the SSIV value to its starting value. A group member MAY re-register prior to the actual exhaustion of the SSIV field to avoid dropping data packets due to the exhaustion of available SSIV values combined with a particular SID value. A group member MUST NOT process an SID Download Type KD payload present in a GROUPKEY-PUSH message. ----------- If a member receives a new set of keys for an existing Data-Security SA in a GROUPKEY-PUSH exchange, there will not be any new SIDs in the message so that not all members have the same SID. However, it is not clearly specified whether or not member should consider resetting SSIV range. Since it is a new combination of (SID+key) (key being new, though SID is same), previous values of SSIV based on the SID, can be reused for the new key. This way there is significantly less chance of SSIV getting exhausted, and hence avoiding unnecessary GROUPKEY-PULL message to obtain a new SID. thanks, -suresh From bew@cisco.com Fri Jun 17 10:36:16 2011 Return-Path: X-Original-To: msec@ietfa.amsl.com Delivered-To: msec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A2A11E80AD for ; Fri, 17 Jun 2011 10:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HrKJpqSOGR6 for ; Fri, 17 Jun 2011 10:36:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C124511E8071 for ; Fri, 17 Jun 2011 10:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3315; q=dns/txt; s=iport; t=1308332173; x=1309541773; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=olZqlxlXU4N4R0MML4nNsuPd6Wyf+7f83PRdESt7roM=; b=W5byaq57Ezh8wnpGG4Ky+lZHa5ks7XAyVqpFyFbN/Ae8LO0m9+fpftN4 OqObrRBjPC31IC1/+ChMJpTVYvh/zH08YWFp70nceqTqIKZFcqWawtpZ2 JBZSk60A1GzsmaDWCsdNf/ujXTH2VkRs1JuYA7wExMqNrlSSHzsPyP1rW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALGP+02rRDoH/2dsb2JhbABMBqZQd4hzoHueDYM0gnMEhyCKPpAd X-IronPort-AV: E=Sophos;i="4.65,382,1304294400"; d="scan'208";a="339804315" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2011 17:36:10 +0000 Received: from dhcp-128-107-147-115.cisco.com (dhcp-128-107-147-115.cisco.com [128.107.147.115]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5HHaASl021511; Fri, 17 Jun 2011 17:36:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <20110611005446.GA6618@juniper.net> Date: Fri, 17 Jun 2011 10:36:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110611005446.GA6618@juniper.net> To: Suresh Melam X-Mailer: Apple Mail (2.1084) Cc: msec@ietf.org, Stephen Hanna Subject: Re: [MSEC] Comments on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:36:16 -0000 Hi Suresh, Many thanks for your careful review! Your comment that the group member = should have be given more guidance on SSIV handing is very helpful. I = propose replacing the last paragraph in that section (which duplicates = text in Section 5.56.4) with the following new guidance for handling a = GROUPKEY-PUSH message: "A GROUPKEY-PUSH message may include Data-Security SAs that are = distributed to the group member for the first time. An SID previously = issued to the receiving group member is used with counter-based mode of = operation Data-Security SAs on which the group member acts as a sender. = Because this Data-Security SA has not previously been used for = transmittion, the SSIV field should be set to its starting value." Is this wording sufficient? Thanks, Brian On Jun 10, 2011, at 5:54 PM, Suresh Melam wrote: > Hi, >=20 > I've looked at the Appendix C. and some of the other related changes. > These changes look good and makes the GDOI protocol more robust. = While > obviously Juniper hasn't already implemented these changes yet, they = are > not in conflict with what was already done. >=20 > One comment, >=20 > ----------- > In Sec: > 5.6.4.3. Group Member Semantics >=20 > The SID_VALUE attribute value distributed to the group member MUST = be > used by that group member as the SID field portion of the IV for all > Data-Security SAs including a counter-based mode of operation > distributed by the GCKS as a part of this group. >=20 > When the Sender-Specific IV (SSIV) field for any Data-Security SA is > exhausted, the group member MUST no longer act as a sender on that = SA > using its active SID. The group member SHOULD re-register, at which > time the GCKS will issue a new SID to the group member, along with > either the same Data-Security SAs or replacement ones. The new SID > replaces the existing SID used by this group member, and also resets = the > SSIV value to its starting value. A group member MAY re-register = prior > to the actual exhaustion of the SSIV field to avoid dropping data > packets due to the exhaustion of available SSIV values combined with = a > particular SID value. >=20 > A group member MUST NOT process an SID Download Type KD payload = present > in a GROUPKEY-PUSH message. >=20 > ----------- >=20 > If a member receives a new set of keys for an existing Data-Security = SA in > a GROUPKEY-PUSH exchange, there will not be any new SIDs in the = message so > that not all members have the same SID. >=20 > However, it is not clearly specified whether or not member should = consider > resetting SSIV range. Since it is a new combination of (SID+key) (key > being new, though SID is same), previous values of SSIV based on the = SID, > can be reused for the new key. This way there is significantly less = chance > of SSIV getting exhausted, and hence avoiding unnecessary = GROUPKEY-PULL > message to obtain a new SID. >=20 > thanks, > -suresh > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com