[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: Re: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08]
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 <rupert@ecotel.demon.co.uk>
To: ipdvb@erg.abdn.ac.uk
CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, H.Cruickshank@surrey.ac.uk
References: <487DC23A.7040903@erg.abdn.ac.uk>
<225B6337E699484095DA8EE02A5063B5090B14@EVS-EC1-NODE1.surrey.ac.uk>
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