[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt
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
Quoting Gorry Fairhurst <gorry@erg.abdn.ac.uk>:
> 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: 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
------------------------------------------------------------
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
Quoting Gorry Fairhurst <gorry@erg.abdn.ac.uk>:
> 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: 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
------------------------------------------------------------