Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351

Brian Weis <bew@cisco.com> Wed, 30 April 2014 13:50 UTC

Return-Path: <bew@cisco.com>
X-Original-To: msec@ietfa.amsl.com
Delivered-To: msec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0861A08DF for <msec@ietfa.amsl.com>; Wed, 30 Apr 2014 06:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.17
X-Spam-Level:
X-Spam-Status: No, score=-14.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBeAA4CVsYl5 for <msec@ietfa.amsl.com>; Wed, 30 Apr 2014 06:50:52 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 617DE1A08DC for <msec@ietf.org>; Wed, 30 Apr 2014 06:50:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12365; q=dns/txt; s=iport; t=1398865851; x=1400075451; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=k3IVMCjFmLe6kIESnox5hdMsMptNq6WPDVlXJec4f+M=; b=cSXigER1VwfJF/MfMWiOnvu+TkTsHAmi3qsR6nKUqhO1QURmX/L9Bp5v 0eOtP1kCcoOx5ED7SR5TNVxQyRYmU6stgWwp8GlWDU5YPc3lnDJANVo4t EolwgdPnAIXIDivAPgh+9cI03Lach4c4EKbxQaPR3LrBhzt3ZXkU3uXHs Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFABr/YFOrRDoJ/2dsb2JhbABZgwbFaIEeFnSCJQEBAQMBeQULC0ZXBhOIOQfJPReLQoMPB4MkgRUEigWPIpJrg1Ed
X-IronPort-AV: E=Sophos; i="4.97,958,1389744000"; d="scan'208,217"; a="108960659"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 30 Apr 2014 13:50:50 +0000
Received: from stealth-10-32-244-213.cisco.com (stealth-10-32-244-213.cisco.com [10.32.244.213]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3UDomJq017444; Wed, 30 Apr 2014 13:50:48 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_2673E109-C16E-4283-914C-FEE5D4DF8A76"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Brian Weis <bew@cisco.com>
In-Reply-To: <0815908A-7B2F-4A0B-9654-5367962995B6@inria.fr>
Date: Wed, 30 Apr 2014 06:50:47 -0700
Message-Id: <9D95662F-312D-40C6-95E8-4EEB2A84F386@cisco.com>
References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> <E6C9F0E527F94F4692731382340B3378025AA7@DENBGAT9EH2MSX.ww902.siemens.net> <E6C9F0E527F94F4692731382340B3378029F9D@DEFTHW99EH4MSX.ww902.siemens.net> <7CD270C5-2E9F-45A5-B434-8A4EB6146C24@cisco.com> <0815908A-7B2F-4A0B-9654-5367962995B6@inria.fr>
To: Vincent Roca <vincent.roca@inria.fr>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/msec/R1aO1_dBGULDOiKz4VxaCPtj6m0
Cc: msec@ietf.org, Kathleen Moriarty <kathleen.moriarty@emc.com>, draft-weis-gdoi-iec62351-9@tools.ietf.org
Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351
X-BeenThere: msec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multicast Security List <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/msec>, <mailto:msec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/msec/>
List-Post: <mailto:msec@ietf.org>
List-Help: <mailto:msec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Apr 2014 13:50:57 -0000

Hi Vincent,

Many thanks for your review. I've addressed them, with some notes inline.

On Mar 3, 2014, at 10:27 AM, Vincent Roca <vincent.roca@inria.fr>; wrote:

> Hi Brian,
> 
> I finally gave a look at the document (draft-weis-gdoi-iec62351-9-03).
> Here are my comments:
>      
> Section 2.2.  SA TEK Payload
> ----------------------------
> 
> ** typo:
> An GDOI_PROTO_IEC_61850 SA TEK includes => A GDOI_PROTO_IEC_61850 SA TEK includes
>                                            ^^
> ** typo:
> represents a SPI => represents an SPI
>                                ^^
> (there are many occurrences of "a SPI", is it volontary?)

I double checked with some sources, and the general rule (at least for American English) is "a" before a consonant, and "an" before a vowel. There are a few special rules but "a before s" does not seem to be one of them.

> 
> ** typo:
> are define in Section 2.2. => are defined in Section 2.2.X
>                                        ^^
> (several occurrences)
>       
> ** There is a window of 2 keys (CK and NK). Each of them have timing values, representing
> their validity time till it needs to be updated. As I understand, the CK will take the
> value of the NK upon CK expiration. Potentially, the CK/NK timing values can be different.
> Is it an issue (e.g. if the NK remaining lifetime is < CK remaining lifetime, the NK must
> be updated before the CK) ? I imagine this is discussed elsewhere. A note might be useful.

This case is not mentioned; I've added a note.

>      
> Section 2.3:
> ------------              
> 
> ** incoherencies:
> there are several occurences of "KD payload", whereas it is written "Key Download Payload" elsewhere.
> Also, section 1.3 mentions:
>    KD    Key Download Payload
> i.e. includes the payload in the KD acronym definition.

> 
> ** Typo: "The KD TYPE MUST be TEK" => "The KD Type MUST be TEK"
>                                               ^^^^
>    
> ** Fig 6: The figure mentions "KD Length", but this is a Key Packet.
> Should it be the "Key Packet Length" instead?
> 
> Appendix A:
> -----------
> 
> ** I find it strange to provide actual field payloads, without respecting the field size. E.g.:
> 	OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02>
> is 13 byte long if I understand correctly, but in the figure, it only spans 3 bytes.
> Same remark for the OID SP=<DER for 233.252.0.1> field.    

Sorry this is confusing. The field ends in a "~", which is a shortcut for saying the length of the field goes beyond the bytes shown, which (if you know that) makes the example easier to understand. I'll see if I can make the example clearer.

> 
> BTW, these figures are not numbered which makes it more complicated to reference them.
> 
> ** I was also wondering if there are alignment requirements. In theory no as there is
> no padding field. I haven't seen any note for this, whereas all figures are presented in
> such a way that 16-bit fields are correctly aligned. A note could be added to section B.1.

A note is a good idea. It's hard to mandate padding when there are multiple variable-length fields.

>  
> ** Fig p.19: 
> typo: There is a trailing "2" character in "RESERVED2".

Actually, that's what the field is called in the  KD Payload definition (RFC 6407, Section 5.6).

> 
> 
> Cheers,
> 
>    Vincent
> 

[snip]

Thanks,
Brian