Comments on draft-ietf-ipdvb-sec-req-06 (editorial)

[Gorry Fairhurst <[e-mail]>]

Here are some editorial NiTs, which I'd like you to consider in 
preparing the next revision of the document.

Best wishes,

Gorry Fairhurst.

------

Overall NiTS:

- The words /Receiver/ and /Receivers/ should be capitilised for
consistency.
- The words /ULE stream/ and /ULE streams/ should be capitilised for
consistency.
- The words /Header Extension/ should be changed to /Extension Header/
and all occurences should be capitilised for consistency with RFC5163.
- The words /extension format/ should be changed to /Extension Header
format/
- [ID-EXT] should be replaced by [RFC5163].
- I am confused about the difference between a ULE Stream (as defined in
RFC4326, and a ULE link). If there is no difference, can we change all
to /ULE Stream/?

=======

Abstract:
/... multicast transmission./
- Please add:
/The analysis also describes applicability to the Generic Stream
Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB)
Project./
---
Page 3. The scenarios are labeled 1,2,..., however in RFC 4259, these
are labeled A,B,C,... Maintaining a consistent labeling could help
cross-referencing.
---
Page 3:
/This can be typically satellite-based and
       star-based utilising a Hub station to deliver a common bit
       stream to medium-sized groups of receivers. /
---
/Point-to-Point/
- Please add:
/This connectivity may be provided using a pair of transmit
    and receive interfaces./
---
/This can be typically satellite-based and
       star-based utilising a Hub station to deliver a common bit
       stream to medium-sized groups of receivers. /
- I think this "typically" could be disputed, and this should be an
example place after the following sentence.
---
/both unidirectional as well
    as bidirectional links for the scenarios mentioned above./
- Please clarify, e.g.
/(A,B,C,D)
    and bidirectional (E,F) links for these scenarios./
---
Page 8:
/like IPSec/
- change to
/e.g. IPSec/
---
/rely on security assumptions as of wired links/
- can I suggest the following?
/may make the same security assumptions as for wired links [RFC3819]/
---
/ networks which are /
            ^^^^^
- please change /which/ to /that/
---
page 8:
/ ULE link security focuses only on the security between/
- change to
/ULE Link Security only concerns the secuirty between/
---
page 8:
/governmental users/
- please change to:
/users requiring high assurance of security (e.g. government use)/
---
Page 8:
  / Hence for such cases the confidentiality and
    integrity of the user data will already be taken care of by /
- English needs to be improved, suggest:
  / Hence for such cases, the requirements for confidentiality and
    integrity of the user data will be met by /
---
Page 9:
/   are considered the major threats. An example of such a threat is/
could be simplified to:
/   are the major threats. One example is/
---
Page 9:
/; an intruder can gain information by determining/
could be simplified to:
/allowing an intruder to determine/
---
Page 10:
/the security threat cases can be abstracted into three cases/
could be simplified to:
/the security threats can be abstracted into three cases/
---
Page 11:
/ This is normally receiver to hub authentication and it could/
- "hub" - not sure what this word means here?
- The document should be agnostic to the choice of physical layer.
- Are we talking about the encapsulator, key management system, or what?
---
/[ISO-8802, IEEE-802]./
- Please change to:
/[ISO-8802], [IEEE-802]./
---
/GReq (g)/
- Add missing stop to end of sentence.
---
Case 2:
/to monitor most denial/
             ^^^^
- delete most? or replace by "common"?
---
/and apply to all the scenarios above, where appropriate./
- Either delete this, or explain what you mean (preferably before the
start of the list).
- At the moment this says it always applies, except when it does not.
---
Page 13:
   /This would help in the design of the ULE Security
    extension header. For example this could help in the selection of
    security fields in the ULE Security extension Header design./
- please simplify to:
   /This may assist in selecting
    security fields for design of a ULE Security Extension Header/
---
Page 13:
/   Moreover the security services could also be grouped into
    profiles based on different security requirements. One example is
    to have a base profile which does payload encryption and identity
    protection. The second profile could do the above as well as
    source authentication.
/
- please simplify to:
/   Security services may be grouped into
    profiles based on the security requirements, e.g.  base profile
   (with payload encryption and identity protection) and a second
    profile could that extends this to also provide source
    authentication./
---
DoS is used in table. but not previously defined (it looks like this
should be defined on page 9).
---
---
Section 6., page 14:
/ The [ID-EXT] document describes two new Header /
        ^^^^^^                     ^^^^
- RFC 5136 defines three.
---
/and specifically for DVB-S2 [ID-EXT]./
- delete above.
---
/It might be
    desirable to authenticate some/all of the headers; such decision
    can be part of the security policy for the MPEG-2 transmission
    network./
- This seems rather vague. Are the headers you mention GSE headers?
- which security policy? (note: this would not be a MPEG-2 one).
---
Section 7:
/It also defines/
- delete also.
---
---
/between a ULE Encapsulation Gateway to Receivers/
                                      ^^
change to:
/between a ULE Encapsulation Gateway and the corresponding Receiver(s)/
---
/End-to-end security mechanism may then be used
    additionally and independently for providing strong
    authentication of the end-points in the communication.
/
- I suggest omitting this, since this seems covered by the first clause
in the paragraph.
---
Section 8:
/(out of scope) such as:/
change to:
/(i.e. are out of scope), e.g.:/
---
Section 10:
/from University of Salzburg./
to:
/(University of Salzburg)./
---
These words appear in Appendix A:
/ There
    could be other extension headers (either mandatory or optional).
    It is RECOMMENDED that these are placed after the security
    extension header. This permits full protection for all headers.
    It avoids situations where the SNDU has to be discarded on
    processing the security extension header, while preceding headers
    have already have been evaluated. One exception is the Timestamp
    extension which SHOULD precede the security extension header [ID-
    EXT]. When applying the security services for example
    confidentiality, input to the cipher algorithm will cover the
    fields from the end of the security extension header to the end
    of the PDU./
- I like them, and think they follow RFC5163, but I do not think you're
allowed to use RFC 2119 keywords on requirements in an appendix. Could
you consider moving these to follow the words in  GReq (g)?
---
Appendix B:
   /section compares the disadvantages when security functionalities
    are present in different layers./
Change to:
   /section compares the placement of security functionalities
    in different layers./
---
Please add a citation in section 6 to the following new informative
reference:
   [GSE]        TS 102 606 "Digital Video Broadcasting (DVB); Generic
                 Stream Encapsulation (GSE) Protocol, "European
                 Telecommunication Standards, Institute (ETSI), 2007.
---
I suspect [RFC4326] is a normative reference (rather than informative).

===================


-End-

-- 
Dr Gorry Fairhurst, School of Engineering.
The University of Aberdeen is a charity registered in
Scotland No SC013683.