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 []) 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-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (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 []) (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 (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,


/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
- 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
- Can you elaborate or remove the following text, currently I do not
understand these additional cases: /for other scenarios of group
- 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

The standards language should be tightened:

/must default to the first entry in the list/
Section 6.3:
/the SNDU data must be/
/ and this event should be logged as an invalid/
/it must be set up as /
/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/?

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