[MSEC] Comments on draft-ietf-msec-gdoi-update-08

Suresh Melam <nmelam@juniper.net> Sat, 11 June 2011 00:58 UTC

Date: Fri, 10 Jun 2011 17:54:46 -0700
From: Suresh Melam <nmelam@juniper.net>
To: msec@ietf.org
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 <shanna@juniper.net>
Subject: [MSEC] Comments on draft-ietf-msec-gdoi-update-08
Precedence: list

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

[MSEC] Comments on draft-ietf-msec-gdoi-update-08 Suresh Melam
Re: [MSEC] Comments on draft-ietf-msec-gdoi-updat… Brian Weis