Re: [Fwd: Re: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08]

[Michael Noisternig <[e-mail]>]

Hello Rupert,

many thanks for your review and the comments. See our replies inline.

> -------- Original Message --------
> Subject: Re: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08
> Date: Wed, 30 Jul 2008 11:53:32 +0100
> From: Rupert Goodings <[e-mail]>
> To: [e-mail]
> CC: Gorry Fairhurst <[e-mail]>, [e-mail]
> References: <[e-mail]> 
> <[e-mail]>
> 
> 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.  

ULE security concerns security for the ULE link which is the connection 
between the encapsulator and the receiver. There is no reason ULE cannot 
be used throughout in 2-way networks if the MPEG-2 transmission network 
accomodates that. Plus, the transmission network could be hubless. 
Speaking of that, ULE can be used in any MPEG-2 network and is not 
restricted to satellite networks.

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

Assuming senders directly use ULE with ULE security both forward and 
return link are protected.

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

We want to reserve MAC for Message Authentication Code as this is a 
security document.

Also NPA has been defined in RFC 4326 and therefore it should be used in 
all IP-DVB related documents.

Gorry adds that this could also be confused with the LAN MAC address 
with bridging encaps - which is something different.

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

As above, the definition is taken from RFC 4326 which people will 
eventually refer to, anyways.

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

We do not want to complicate that figure. It is adapted from RFC 4259 
and its purpose is to identify all entities within the MPEG-2 network, 
which is used later for threat analysis.

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

I guess the confusion comes from the term VPN. I (Michael) meant to use 
this for all entities sharing the same secret material thus enabling 
them to form some secure overlay network. So you could be in the same 
physical network but not having the key makes you an outsider.

Maybe just say "Outsider attacks, i.e. active attacks from adversaries 
without knowledge of the secret material." to avoid any confusion.

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

Algorithm agility is a common/established term in the security area for 
protocol design.

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

That's good.

> Section 7: Typo: "Annexe 1"

Yes, should be Appendix A.

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

Ok.

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

We do not want to unnecessarily complicate the figure by duplicating the 
SA/SP block for the key server. However we'll add the text
"The Security Databases Block exists in both the group member and server 
sides.  However, it has been omitted from Figure 2 just for clarity."
to the introduction of the building blocks.

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

Ok.

> 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

Ok.

> disadvantages.  Two suggested disadvantages:
> - no protection of MAC Address

There seems to be some confusion. ULE security *does* protect the 
MAC/NPA address. This is said by the point
"Ability to protect the identity of the Receiver within the MPEG-2 
transmission network at the IP layer and also at L2."
By identity we mean (NPA) addresses as introduced earlier.

> - only protects C-plane control messages if they are encapsulated.

Yes that is correct.  But Ipsec and TLS/DLS can not protec control 
messages either.

> 
> ==END OF COMMENTS