RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt

[P.Pillai@Bradford.ac.uk]

Hi Haitham,

I have a few more comments on the draft:

1. As stated in Section 3 ? ?Data confidentiality is the major requirement
against passive threats (using encryption).  L2 encryption or L3 (IPsec)
Encryption can satisfy this requirement?.  I disagree with this. L3 (IPSEC)
Encryption would not be able to prevent passice threats like traffic analysis
as the outer IP header is not encrypted. The only drive to provide L2 security
is to provide encryption of the complete higher layer packets to prevent any
traffic analysis.

2. Regarding the optional authentication and integrity. I think we need to be
careful with the wording in the draft.

- Is there a requirement for an ?optional authenticity/integrity mechanism?
(like you said that some service may not need it)? or
- Is there a definite requirement for authenticity/integrity mechanism over the
MPEG2 link? This may be optional at the ULE level when other
authentication/integrity mechanisms at other layers may be present (like IPSEC
AH or ESP with Auth).

I prefer the second option which emphasises on the requirement for
authenticity/integrity but keeps it as an optional service at ULE. Could the
other members of the group also voice their opinion on this?

3. Who would be in-charge of selecting the Secure ULE level ? the user or the
NCC? Does the NCC decide on the level of security to be used (according to the
user profile, pricing plan, etc) or can the user select the level of security
(so the user can select different security levels for different sessions)?

4. What about content protection? Do we need to address the
support/interoperability with content protection mechanism (like DRM)?

5. What about Interworking with existing lower layer security mechanisms
especially the ones specified in DVB RCS (MKE, EKE, QKE)? Do we expect a user
to perform DVB RCS security setup (using MKE, EKE, QKE), then perform another
set of security setup for Secure ULE (using GDOI/GSAKMP etc) and then a final
end-to-end IPSEC setup (using IKE/ISAKMP or even  GDOI/GSAKMP etc)?

Regards
Prashant




Quoting H.Cruickshank@surrey.ac.uk:

> Many thanks Prashant,
>
> See responses in-line:
>
>
> ----
> Dr. Haitham S. Cruickshank
> Lecturer
> Communications Centre for Communication Systems Research (CCSR)
> School of Electronics, Computing and Mathematics
> University of Surrey, Guildford, Surrey GU2 7XH, UK
>
> Tel: +44 1483 686007 (indirect 689844)
> Fax: +44 1483 686011
> e-mail: H.Cruickshank@surrey.ac.uk
> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
>
> ________________________________
>
> From: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk
> Sent: Tue 16/05/2006 14:33
> To: ipdvb@erg.abdn.ac.uk
> Subject: Comments on draft-cruickshank-ipdvb-sec-req-01.txt
>
>
>
> Hi Gorry and Haitham,
>
> The new version of the draft (draft-cruichshank-ipdvb-sec-req-01.txt)
> addresses
> most of the security requirements that shall/may be required for the ULE
> links.
> I have just a few comments on the draft.
>
> 1. Is there a particular reason why the security measurements are only taken
> for
> wireless MPEG2 networks (as indicated in the Introduction section)? Why are
> the
> wireline MPEG2 networks more secure? I think that the security requirements
> should be for any MPEG2 networks, wired or wireless.
>
> Haitham: You are right the requirements should cover both wired and wireless
> environment. However, wireless environment is more vulnerable to security
> attacks. For example eavesdroping is easier in wireless broadcast networks.
>
> 2. Network access control is also an important security requirement. There is
> no
> point to just secure the user traffic, when this user has not been
> authenticated
> and authorised for the connection. This may be coupled with key management.
>
> Haitham: I agree. The draft does address this issues.  May be we need to make
> it clearer.
>
> 3. This document aims to basically highlight the security requirements that
> are
> important for securing (just) the MPEG2 link. Hence this is important from
> the
> point of view of the MPEG2 Network Provider (NP).  As the MPEG2 Network
> provider has no control on any end-to-end security mechanism, it is something
> that should not directly affect the security requirements on the ULE Link.
> ULE
> Security should aim to provide all the security requirements. The text leads
> to
> confusion where the Section 2, Last paragraph mentions that the ULE
> authentication and Integrity are required especially because active attacks
> are
> possible at the receiver end; while Section 3 suddenly states that these are
> optional requirements.
>
> Haitham: There are two points here: One, is interworking of end-to-end and
> ULE link security. The draft highlights the fact that ULE security should not
> be an obstacle against end-to-end security, if such service exists. For
> example, if IPsec or transport layer end-to-end security is used, then ULE
> security should allow passing such traffic as long as it is compliant with
> general rules and plocies of that MPEG-2 transmission network. The second
> point is the optional authentication and Integrity: The reason is that we
> want to leave a flexibility for the MPEG-2 transmission network to implement
> it depending on the specific policies for each service. Some services might
> not need authentication or data integrity. Any comments from ipdvb group are
> welcome on this issue.
>
> There are contradicting sentences in the document, like in Section 5 2nd
> para,
> the documents says that "ULE link security is considered as an additional
> security mechanism to IP transport and application Layer security." But the
> very next sentence says that "It should provide similar functions to that of
> IPsec...". It leads to a confusion as to why to we need same level of
> security at
> two layers.
>
> Haitham: See answers above.
>
> I agree with the fact that ULE security should provide high security similar
> to
> IPSec, but just because their may be end-to-end mechanism present (which the
> MPEG2 network provider cannot control anyways) we should not decide that the
> other requirements (like source authentication, integrity etc) are optional.
>
> Haitham: See answers above.
>
> 4. There are quite a few typo errors in the document, but I guess this is not
> so
> important at this moment and could be looked into when we submit the draft as
> a
> WG item.
>
> Haitham: Thanks.
>
>
>
> Regards
> Prashant Pillai
>


-- 
Prashant Pillai
Research Assistant
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
Phone: 0044-1274-233720
email: p.pillai@bradford.ac.uk
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to misuse@bradford.ac.uk
------------------------------------------------------------