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

[Michael Noisternig <mnoist@cosy.sbg.ac.at>]

Hi Gorry,

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

Michael

Gorry Fairhurst schrieb:
> 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?

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'.

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

Ok.

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

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.'

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

Agreed.

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

I was also wondering. We will discuss that.

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

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.

> ---
> Section 5.8
> - What would you suggest for use with GSE, would you also suggest the 
> ISI value was included?

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.

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

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

> - Does it have to be centrally selected? - This implies a need for
> automated key management. ... or is it sufficient to be known at both

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

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

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.'

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

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).

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

Agreed.

> ---
>
> The standards language should be tightened:
>
> /must default to the first entry in the list/
>  ^^^^
> - MUST?

<snip>

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

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

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

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

Right. Will correct this.

> ===
>
> - 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.