Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)

Michael Noisternig <mnoist@cosy.sbg.ac.at> Fri, 10 July 2009 14:25 UTC

Return-Path: <owner-ipdvb@erg.abdn.ac.uk>
X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com
Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274E63A68CC for <ietfarch-ipdvb-archive@core3.amsl.com>; Fri, 10 Jul 2009 07:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.084
X-Spam-Level:
X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_AT=0.745, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXZkkkyF6KCN for <ietfarch-ipdvb-archive@core3.amsl.com>; Fri, 10 Jul 2009 07:25:08 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id A1C7928C35B for <ipdvb-archive@ietf.org>; Fri, 10 Jul 2009 07:24:43 -0700 (PDT)
Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n6ADvF7I018765 for <ipdvb-subscribed-users@dee.erg.abdn.ac.uk>; Fri, 10 Jul 2009 14:57:15 +0100 (BST)
Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id n6ADvFl1018764 for ipdvb-subscribed-users; Fri, 10 Jul 2009 14:57:15 +0100 (BST)
X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f
Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n6ADv4oB018749; Fri, 10 Jul 2009 14:57:04 +0100 (BST)
Received: from [192.168.1.2] (d83-187-170-40.cust.tele2.at [83.187.170.40]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id E6C112286A2; Fri, 10 Jul 2009 15:57:04 +0200 (CEST)
Message-ID: <4A5748AC.8070402@cosy.sbg.ac.at>
Date: Fri, 10 Jul 2009 15:57:00 +0200
From: Michael Noisternig <mnoist@cosy.sbg.ac.at>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: ipdvb@erg.abdn.ac.uk
Cc: gorry@erg.abdn.ac.uk, H.Cruickshank@surrey.ac.uk, Prashant Pillai <P.Pillai@Bradford.ac.uk>
Subject: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)
References: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk> <4A50542A.20001@erg.abdn.ac.uk> <4A505DE1.80009@erg.abdn.ac.uk>
In-Reply-To: <4A505DE1.80009@erg.abdn.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean, Found to be clean
Sender: owner-ipdvb@erg.abdn.ac.uk
Precedence: bulk
Reply-To: ipdvb@erg.abdn.ac.uk
X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk

Hi Gorry,

thanks again. Please see a few comments inline.

Michael

Gorry Fairhurst schrieb:
> 
> Authors, I dent some comments and questions on the draft in a previous 
> email. This email contains a few minor comments on editorial issues, 
> that may improve the next version of this draft.
> 
> Best wishes,
> 
> Gorry
> 
> ---
> /Another feature provided is called identity protection./
> - This reads oddly, I suggest something like:
> /The method also provides identity protection./

The problem was that 'identity protection' normally refers to something 
else. How about
"The extension also supports what is called 'identity protection' in 
this specification."?
Any better suggestion?

> ---
> /processing continues as usually/
> - this should be /continues with the usual processing/, although it 
> would be better to also cite a reference to indicate what this is.
> 
> ---
> /On securing the ULE SNDUs, security is provided at the link layer as
>    opposed to existing higher-layer mechanisms like IPsec [8] or TLS
>    [11]. This allows them to be used in/
> - This reads oddly. Is it possible to say something like:
> /This document provides security for ULE SNDUs at the link layer, iin 
> contrast to higher-layer mechanisms, such as IPsec [8] or TLS
> [11]. This design allows higher-layer mechanisms to be used in/
> ---
> /The security extension may use and benefit f/
> - This isn't quite so, you would would need to update these mechanisms, 
> a forward reference to the appropriate section where this is discussed.

I agree. We may remove that, and instead add the following paragraph 
after the one talking about the processing:

"Key management protocols assuming similar processing functionality, 
such as the MSEC Group Domain of Interpretation (GDOI) [9] and the Group 
Secure Association Key Management Protocol (GSAKMP) [7], may be adapted 
for the ULE scenario. Simple configurations are supported using manual 
keying (i.e., pre-shared keys)."

Is this more clear, should we still provide a forward reference?

> ---
> /The ULE security extension is designed to cope with both bi-
>    directional and unidirectional links, as well as unicast and
>    multicast settings./
> - Could you replace /to cope with/ by /for/
> - This would be a good place to identify the framework [RFC 4259]
> ---
> Please add abbreviations:
> GSE
> VPN
> SID
> etc.
> ---
> /Some of the main security services
>    (mandatory or optional) that the security extension for ULE aims to
>    provide are:/
> - delete /aims to provide/? and say /provides/?
> ---
> /even if it got hold of the transmitted data./
>         ^^^^^^^^^^^^^^^
> - Can you rephrase in more formal English?
> ---
> /arguably the most important step on providing/
> - Is it possible to say something like:
> /an important step in providing/
> ---
> /While one
>       solution for this is to use temporary addresses....
> - is this text needed? (see other comments).
> ---
> Page 6:
> /digital signatures, may be used in order to assure source/
> - I misread this. I don't think this talks about ordering, and so it 
> would be better in this case to remove /in order/.
> ---
> / will not be able to derive a correct one./
>        ^^^^^^^^^^^^^^^^^^^^^^^
> - True, it will be statistically hard, bit not impossible.

...will unlikely be able to derive a correct one.

Or we might introduce (in)feasibility. ;)

> ---
> Page 7:
> /received data is recent/
>                ^^^^^^^^^
> - could this be better phrased?

...fresh?

> ---
> Page 8:
> /After the ULE base header, the security extension header follows./
> - May be better as:
> /The security extension header follows the ULE base header./
> ---
> Page 11:
> / In order to support
>    shared SAs permitting bi-directional communication, an SAD should/
> - May be better as:
> / To support shared SAs for bi-directional communication, an SAD should/
> ---
> / Each set of Security Parameters contains information about:/
> - May be better as:
> / Each set of Security Parameters contains:/
> ----
> /no security services at all,/
>                       ^^^^^^
> - delete /at all/?
> ---
> /Note that we do not describe/
> - better, perhaps as:
> /This document does not describe/
> ---
> /, as this is regarded implementation specific details./
> - better, perhaps as:
> /. This is regarded as implementation-specific detail./
> ---
> Section 7.3:
> / Such protocol should/
>       ^
> - insert /a/.
> ---
> /Link-level security is commonly used in broadcast/radio links to
>    supplement end-to-end security, and may not be treated as a
>    substitute./
> - A substitute for what?
> ---
> /A device may receive data from different MPEG-2
>    multiplexes, which both may allocate PID values independently./
> - cite reference to another RFC?
> 
> ---
> References:
> 
> Some references are uncited, e.g. [5].
> 
> It may be helpful to consider citing [10] and [4] as informational 
> background to issues they consider. These are already published and 
> citing them where appropriate would help the reader understand issues 
> that have already been discussed.
> 
> ---
> 
> Finally,
> The following word appears in several place: /Illegitimate/ This has 
> some additional meanings that are not intended here - could you replace 
> by unauthoried or unintended or something similar?

I agree with all other suggestions.