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

[Brian Weis <[e-mail]>]

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,
> 
> 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/msec


-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: [phone]
Email: [e-mail]