draft-noisternig-ipdvb-sec-ext-00.txt
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sun, 05 July 2009 07:42 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 D2E2D3A659B for <ietfarch-ipdvb-archive@core3.amsl.com>; Sun, 5 Jul 2009 00:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level:
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599]
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 KPhhM0Gakdzg for <ietfarch-ipdvb-archive@core3.amsl.com>; Sun, 5 Jul 2009 00:42:54 -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 78EF63A63C9 for <ipdvb-archive@ietf.org>; Sun, 5 Jul 2009 00:42:53 -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 n657KnCK009828 for <ipdvb-subscribed-users@dee.erg.abdn.ac.uk>; Sun, 5 Jul 2009 08:20:49 +0100 (BST)
Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id n657KnJQ009827 for ipdvb-subscribed-users; Sun, 5 Jul 2009 08:20:49 +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 Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n657K9SM009806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 5 Jul 2009 08:20:10 +0100 (BST)
Message-ID: <4A50542A.20001@erg.abdn.ac.uk>
Date: Sun, 05 Jul 2009 08:20:10 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: ipdvb@erg.abdn.ac.uk
CC: H.Cruickshank@surrey.ac.uk, mnoist@cosy.sbg.ac.at, Prashant Pillai <P.Pillai@Bradford.ac.uk>
Subject: draft-noisternig-ipdvb-sec-ext-00.txt
References: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk>
In-Reply-To: <1244702672.4a30a7d0b5839@webmail.brad.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
Thanks for this new draft. It is good to see progress on this draft, I have a number of comments on the draft, and some editorial NiTs that I shall send separately. best wishes, Gorry --- Abstract: /The extension may be easily adapted to the Generic Stream Encapsulation (GSE) protocol, which uses a similar extension header mechanism./ - Is it possible to say this extension header *is* applicable to GSE? --- Para 2 of introduction: /(e.g., satellite mesh systems with on-board processing)./ - As far as I know, this is a property of any mesh network. If so, this could be shortened to /satellite mesh systems/ --- Para 3 of introduction: /This allows them to be used independently and in parallel, and any network layer protocol like IP (even with Ethernet bridging) may be used with the security extension./ - Is it also possible to be used for signaling information? --- Para 5 of introduction: /may benefit from IETF key management protocols, / - It could be worth saying the simplest method is to use pre-shared keys, and this may be appropriate in some important use-cases. --- Page 6 states: /More importantly, from a security point of view, temporary addresses do not provide adequate identity protection, as a passive adversary may easily link different SNDUs to the same connection. Also, a procedure to allocate temporary addresses is required such that they are unique in the system. Hence it is proposed to encrypt the destination address/ - I found this confusing. Does this text need to be in the current draft or could it be moved to a change log or appendix? --- Section 5.8 /It is RECOMMENDED that it has a default size of 12 octets./ - I'm confused by the RFC-2119 keyword here. Does this define a 12 byte default? (it could) Or does this recommend something for which there may be a good reason to make exceptions... I think I do not understand. --- Section 5.8 - What would you suggest for use with GSE, would you also suggest the ISI value was included? --- Section 6 /for multicast settings, for other scenarios of group communication, and also for unidirectional links, where the SPI value has to be centrally selected by a group controller/ - Can you elaborate or remove the following text, currently I do not understand these additional cases: /for other scenarios of group communication/ - Does it have to be centrally selected? - This implies a need for automated key management. ... or is it sufficient to be known at both ends, and hence a pre-shared value could alternatively be used with a static configuration. --- Section 6 / an SAD should only store references to SAs, and reference/ ^^^^^^ - Does this need to be /SHOULD/ i.e. is there a protocol interoperability issue, if other approaches are used? --- Section 6 / This document always requires separate SPs to be defined for incoming and outgoing data, and in turn allows SAs to be shared across several devices, supporting both unidirectional links and group communication./ - These seem like requirements, can this be written using MUST and MAY? --- /The GCKS must be contacted by a device which cannot find an SA for a matching SP, and when the SP does not define a static SID and default key data in its first set of Security Parameters./ - This seems to imply there is always a GCKS? - Should this be prefixed by /When a GCKS is configured, the GCKS must be.../ --- The standards language should be tightened: /must default to the first entry in the list/ ^^^^ - MUST? --- Section 6.3: /the SNDU data must be/ ^^^^ - MUST? --- / and this event should be logged as an invalid/ ^^^^^^ - SHOULD? --- /it must be set up as / ^^^^ - MUST? --- /the device should postpone transmission, or discard the data./ - device, is this the "sender"? - is there a MUST or SHOULD here and in the following sentence? --- /If no new SA is available, a transmitter may still use the current SA during its full lifetime. After that, it must discard the data, and this event should be logged./ - is there a MUST or SHOULD here? --- Point 4. /If the SA requests identity protection, the destination NPA address is omitted from the base header, setting the base header's D bit to 1./ - This seems to be optional, as described earlier. --- /the SNDU is discarded silently./ - /MUST be silently discarded/? --- References: There is a Downref: A Normative reference to Informational RFC 5458. Reference 4 should be informational, since the standard can not rely on an informational draft. === - It would be really helpful to see an appendix (that may be removed by the RFC Editor) that keeps a change log of what has changed in the draft revision. In this case, it would be useful if the authors could provide some inherited history from the drafts that contributed to this combined draft - so that other people reviewing this can see where the work came from.
- draft-noisternig-ipdvb-sec-ext-00.txt Gorry Fairhurst
- Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editor… Gorry Fairhurst
- Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editor… Michael Noisternig
- Re: draft-noisternig-ipdvb-sec-ext-00.txt Michael Noisternig
- Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editor… Gorry Fairhurst