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

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 05 Jul 2009 08:20:10 +0100

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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 05 Jul 2009 09:01:37 +0100

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./
---
/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.
---
/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.
---
Page 7:
/received data is recent/
                ^^^^^^^^^
- could this be better phrased?
---
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?

---

From: Michael Noisternig <[email-masked]>
Date: Fri, 10 Jul 2009 15:57:00 +0200

Hi Gorry,

thanks again. Please see a few comments inline.

Michael

> /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?

> 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?

> /even if it got hold of the transmitted data./

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

Or we might introduce (in)feasibility. ;)

> - could this be better phrased?

...fresh?

> by unauthoried or unintended or something similar?

I agree with all other suggestions.

---

From: Michael Noisternig <[email-masked]>
Date: Fri, 10 Jul 2009 15:56:06 +0200

Hi Gorry,

many thanks for reviewing the draft. Please see some questions/comments 
inline.

Michael

> - Is it possible to say this extension header *is* applicable to GSE?

Well, the extension /header/ is directly applicable to GSE, but the 
processing described in the document has to be adapted, such as 
replacing PID by ISI, and taking the 3-byte label into account. So I'd 
prefer saying 'it may be easily adapted'.

> could be shortened to /satellite mesh systems/ 

Ok.

> - Is it also possible to be used for signaling information?

I'm not sure what you mean. Are you asking whether the extension can 
secure L2 signalling information? If so, we may add something like: 
'Link-layer signalling information may be protected as well.'

> keys, and this may be appropriate in some important use-cases.

Agreed.

> or could it be moved to a change log or appendix? 

I was also wondering. We will discuss that.

> be a good reason to make exceptions... I think I do not understand.

This is left over from the old draft. It suggests MAC sizes to comply to 
the de-facto standard IPsec MAC sizes of 96 bits. However, given that we 
allow other authentication mechanisms (e.g., TESLA), and we do not 
define any algorithms in the document, I will remove the sentence.

> - What would you suggest for use with GSE, would you also suggest the 

Yes, for GSE we would take the ISI. I'm not sure whether we should point 
this out since we are primarily defining for ULE, and in the 
introduction/abstract we are saying that the extension may be /adapated/ 
to GSE.

> understand these additional cases: /for other scenarios of group

I will replace with 'multi-sender shared SA scenarios'. It should be 
more clear in this wording since that is used below.

> automated key management. ... or is it sufficient to be known at both

Yes, this is talking about automated key management. I will clarify this.

> interoperability issue, if other approaches are used?

Hm, the intention was to rather say duplication efforts could be avoided 
if references are stored. I will rephrase to
'To support shared SAs permitting bi-directional communication and avoid 
the effort of duplicating SAs, an SAD may store references to SAs, and 
reference bi-directional SAs in both the incoming and outgoing SAD.'

> - These seem like requirements, can this be written using MUST and MAY?

These are kinda requirements. An implementation may 'optimise' certain 
configurations, and e.g. define a bi-directional SP where appropriate. 
The point is that the behaviour to the outside must comply. So I suggest 
not using RFC2119 keywords (for now).

> - Should this be prefixed by /When a GCKS is configured, the GCKS must

Agreed.

> /must default to the first entry in the list/

<snip>

Agreed. These RFC2119 keywords got "lost" in copying to a paper and back.

> - This seems to be optional, as described earlier.

I suggest concluding the sentence with '(though another label may be 
re-inserted, see section 5.2)'.

> Reference 4 should be informational, since the standard can not rely on

Right. Will correct this.

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 11 Jul 2009 21:16:10 +0100

See in-line,

Gorry

> "The extension also supports what is called 'identity protection' in 
Sounds fine to me.

>> - This isn't quite so, you would would need to update these 
>> mechanisms, a forward reference to the appropriate section where this 
>> is discussed.
> 
Also seems good.

> ...will unlikely be able to derive a correct one.
That would be OK.

>> - could this be better phrased?
I'm not sure what would be best. I think I'd expect within a specified 
time interval. or "recently received", or something

>> some additional meanings that are not intended here - could you 
>> replace by unauthoried or unintended or something similar?
>