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

From: Suresh Melam <[email-masked]>
Date: Fri, 10 Jun 2011 17:54:46 -0700

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: Brian Weis <[email-masked]>
Date: Fri, 17 Jun 2011 10:36:13 -0700

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:

> _______________________________________________
> MSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/msec

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]