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

From: [email-masked]
Date: Tue, 16 May 2006 14:33:08 +0100

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.

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.

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.

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.

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.

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.

Regards
Prashant Pillai

Quoting Gorry Fairhurst <[email-masked]>:

> Prashat,
>
> Thanks for submitting your draft. Focussing for the moment on the
> security requirements and architecture:
>
> Are there any issues that you think you should be addressed in the
> security requirements document that are not currently captured in draft -01?
>
> Or any areas that you think should also be considered?
>
> Gorry
>

-- 
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: [email-masked]
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to [email-masked]
------------------------------------------------------------