draft-noisternig-ipdvb-sec-ext-00.txt

[Gorry Fairhurst <gorry@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.