Gorry, All,
Following a nudge from Haitham, I've reviewed this draft RFC.
See below for my detailed comments.
Apologies to you all for the lateness of my comments.
To summarise; I think this draft generally reads OK - these just
suggestions that are intended to improve the doc - I would hope that
they can all be dealt with pretty easily and hence (hopefully) not
introduce any delays.
best regards
Rupert Goodings
==START OF COMMENTS
Section 1: (this my major comment)
I find the introduction confusing with regard to scope of this RFC for
Two-Way IP networks.
In my understanding this RFC only really considers link level ULE
security on the forward (hub to remote) link of 2-way networks. Hence
although ULE can be used in 2-way networks the scope of this RFC is
limited to security of the ULE encapsulated forward link only. I think
some reworking of section 1 would help -
specifically the para immediately below the A-F list. I suggest:
RFC 4259 states that ULE must be robust to errors and security threats.
Security must also consider both unidirectional (A, B, C and D) as well
as bidirectional (E and F) links for the scenarios mentioned above. #NEW#
This RFC will consider security for the unidirectional scenarios, and
for the forward link of the bidirectional scenarios.#END NEW#
[Aside: As an example of this assumption: the discussion of monitoring
threats due to the broadcast nature of the network, is clearly only true
for the forward link.]
Section 2:
The definition of NPA really seems to be a definition of MAC Address.
It seems that the rest of the RFC is concerned with the MAC Address (not
the NPA). Hence I suggest you replace NPA with "MAC Address"; i.e:
MAC Address: In this document, the MAC Address refers to a 6-byte
destination address (resembling an IEEE Medium Access Control address)
within the MPEG-2 transmission network that is used to identify
individual Receivers or groups of Receivers.
[[Obviously this requires replacing NPA with MAC Address in the rest of
the Doc. I think replacement is appropriate in most cases]]
ALTERNATIVELY, if you want to retain "NPA" please used a better definition.
I'd insert the phrase "A point where a host can be attached to the network."
Then continue with the current definition with a few tweaks. Hence:
NPA: Network Point of Attachment. A point where a host can be attached
to the network. In this document, the NPA is identified by the 6-byte
destination address (resembling an IEEE Medium Access Control address)
within the MPEG-2 transmission network that is used to identify
individual Receivers or groups of Receivers.
Section 3:
Could we add the NPA to this picture?
(I assume it is between the Host and MPEG-2 receiver. This assumes
my definition as above - i.e. *identified* by the MAC address; not the
MAC Address itself).
[[This depends on response to previous comment]]
Section 3.3.
The definition of "outsider attacks" seems unduly narrow.
Why is this limited to VPNs? I suggest removing VPN:
"Outsider attacks, i.e. active attacks from adversaries outside the
network without knowledge of the secret material. "
Section 4: Greq (c)
I'd prefer to replace "agility" with "update".
For me, agility implies a dynamic process (new alg every few secs)
rather than a slow update process similar to software update.
[[Else please clarify the agility intended]]
Section 4. Table 1.
Table 1 Headings do not align to the Text. Suggest changing the Table
Replace "Attack" with "Threat"
Replace "Mitigation of Threat " with "Security Mechanism"
Section 7: Typo: "Annexe 1"
Section A.1; Figure 2
The text does not align to the Figure. Suggest correcting Figure.
"Key Management Group Member Block"
"Key Management Group Server Block".
Section A.1; Figure 2
I am a bit confused by the Databases block. Why is this on one side only?
I *guess* that the columns relate to the "Receiver" (LHS) and
Encapsulator/Transmitter (RHS). Two suggestions:
a) Introduce column headings as above (and/or create two overall boxes
round the
three blocks on each side;
b) Add a Database block on the RHS.
(Nit: it would be nice to have the order of the text subsections
correspond to the
order of the blocks in Fig 2. i.e. reverse ULE Extension and Database
text sections.)
Section B.3
I think it would be good to have a bit more balance in the discussion of
this option.
Specifically delete "major" from advantages and add some of the
disadvantages. Two suggested disadvantages:
- no protection of MAC Address
- only protects C-plane control messages if they are encapsulated.
==END OF COMMENTS
> *From:* owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst
> *Sent:* Wed 7/16/2008 10:41
> *To:* ipdvb@erg.abdn.ac.uk; Gorry; Martin Stiemerling
> *Subject:* WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08
>
>
> This email starts a WG Last-Call for comments for the WG document named
> below:
>
> http://tools.ietf.org/html/draft-ietf-ipdvb-sec-req-08
>
> Members of the IETF ipdvb WG are now asked to read the above draft and
> send any issues, comments, or corrections to this mailing list. The WGLC
> procedure is the last chance for this working group to modify/correct
> this document. This document is intended for publication as an
> INFORMATIONAL RFC. The document shepherd for the process following
> completion of the WGLC shall be me, as the ipdvb Chair (Gorry Fairhurst).
>
> This Last-Call will end on midnight, 1st August 2008. This is a second
> WGLC, following major revisions to the I-D to address the SecDir review
> comments. The LC period has been extended because this call is made
> adjacent to an IETF meeting.
>
> Please *DO* forward any comments to the list.
>
> Best wishes,
>
> Gorry Fairhurst
> (ipdvb WG Chair)
>
--
This email, its content and any attachments is private and confidential
to ECOTEL LTD (UK). If received in error, please notify the sender and
destroy the original message and any attachments. Thankyou.
Rupert Goodings; Ecotel Ltd <rupert@ecotel.demon.co.uk>