[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ULE Security Requirements : NiTs on text
Hi Gorry,
Thanks for the Nits/Comments update. I will change them for the next version (05).
Cheers
Sunny
***********************************************************
Sunil Iyengar,
Research Fellow, Networks Group,
Centre For Communication And Systems Research(CCSR),
School of Electronics, Computing & Mathematics,
University Of Surrey, Guildford GU2 7XH,
Surrey, England, United Kingdom.
Office: +44 (0)1483 686008
***********************************************************
________________________________
From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst
Sent: Tue 21/11/2006 17:56
To: ipdvb@erg.abdn.ac.uk
Subject: ULE Security Requirements : NiTs on text
Dear authors,
I have the following NiTs/Comments on the text.
Best wishes,
Gorry
----
Page 7:
/(e.g. by an Encapsulation Gateway) or other device to/
/(e.g. by an Encapsulation Gateway or other device) to/
^
--
/these messages are broadcasted/
^^
/these messages are broadcast/
---
/is out of scope for ULE security/
-- [ID.ule.ext] describes a method where they could be encapsulated using
ULE, allowing ULE security methods to also be used in these cases.
----
/eliminates the need to consider/
-- Well you do need to consider them in this document, but securing these
elements is an orthogonal issue...
---
/ The PID associated with an Elementary Stream can be modified /
/ The PID associated with an Elementary Stream can therefore be modified/
^^^^^^^^^
---
/a passive threat. It includes/
/a passive threat. This includes/
^^^^
----
Section 3.2
-- perhaps a forward pointer to a later section that ³masquerading and
modification² are more difficult on a specific link, than they are in the
general internet, and will be described more in section 3.
----
/defines services for Internet Protocol (IP)/
/defines services for the Internet Protocol (IP)/
^^^
---
/There is an extra overheads associated /
/There is an extra transmission overhead associated /
^^^^^^^^^^^^^^^^^^^^^^
- is this what is meant?
---
At the end of section 5, I would also like to say that any defined method
must also be capable of operating with ULE extension headers - specifically
it should allow encryption of a compressed SNDU payload...
---
/ This method does not preclude the use of IPsec at L3 (or TLS [RFC4346]
at L4)./
- True, but I would have preferred to be stronger and continued further to
state that IPsec and TLS can provide strong authentication
of the end-points in the communication. This authentication is desirable in
many scenarios to ensure the information the information
is being exchanged between the correct trusted entities. Layer 2 methods can
not provide this guarantee.
- I¹d also prefer to break the final para into two,the re-use of
established techniques is desirable, but distinct from the advantages of
IPsec/TLS, etc.
----
/ 2 NPA address. In broadcast networks this can /
/ 2 NPA address. In broadcast networks this protection can /
^^^^^^^^^^
---
/Case 2 is likely to a lesser degree within certain network configurations./
- Can you provide one of two concrete examples?
/Therefore case 3 is not considered further in this document. /
- Is it therefore assumed that the MPEG-2 transmission equipment
(multiplexors, etc) are secure? I think this was suggested on the list?
---
Hi Gorry,
Thanks for the Nits/Comments update. I will change them for the next version (05).
Cheers
Sunny
***********************************************************
Sunil Iyengar,
Research Fellow, Networks Group,
Centre For Communication And Systems Research(CCSR),
School of Electronics, Computing & Mathematics,
University Of Surrey, Guildford GU2 7XH,
Surrey, England, United Kingdom.
Office: +44 (0)1483 686008
***********************************************************
________________________________
From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst
Sent: Tue 21/11/2006 17:56
To: ipdvb@erg.abdn.ac.uk
Subject: ULE Security Requirements : NiTs on text
Dear authors,
I have the following NiTs/Comments on the text.
Best wishes,
Gorry
----
Page 7:
/(e.g. by an Encapsulation Gateway) or other device to/
/(e.g. by an Encapsulation Gateway or other device) to/
^
--
/these messages are broadcasted/
^^
/these messages are broadcast/
---
/is out of scope for ULE security/
-- [ID.ule.ext] describes a method where they could be encapsulated using
ULE, allowing ULE security methods to also be used in these cases.
----
/eliminates the need to consider/
-- Well you do need to consider them in this document, but securing these
elements is an orthogonal issue...
---
/ The PID associated with an Elementary Stream can be modified /
/ The PID associated with an Elementary Stream can therefore be modified/
^^^^^^^^^
---
/a passive threat. It includes/
/a passive threat. This includes/
^^^^
----
Section 3.2
-- perhaps a forward pointer to a later section that ³masquerading and
modification² are more difficult on a specific link, than they are in the
general internet, and will be described more in section 3.
----
/defines services for Internet Protocol (IP)/
/defines services for the Internet Protocol (IP)/
^^^
---
/There is an extra overheads associated /
/There is an extra transmission overhead associated /
^^^^^^^^^^^^^^^^^^^^^^
- is this what is meant?
---
At the end of section 5, I would also like to say that any defined method
must also be capable of operating with ULE extension headers - specifically
it should allow encryption of a compressed SNDU payload...
---
/ This method does not preclude the use of IPsec at L3 (or TLS [RFC4346]
at L4)./
- True, but I would have preferred to be stronger and continued further to
state that IPsec and TLS can provide strong authentication
of the end-points in the communication. This authentication is desirable in
many scenarios to ensure the information the information
is being exchanged between the correct trusted entities. Layer 2 methods can
not provide this guarantee.
- I¹d also prefer to break the final para into two,the re-use of
established techniques is desirable, but distinct from the advantages of
IPsec/TLS, etc.
----
/ 2 NPA address. In broadcast networks this can /
/ 2 NPA address. In broadcast networks this protection can /
^^^^^^^^^^
---
/Case 2 is likely to a lesser degree within certain network configurations./
- Can you provide one of two concrete examples?
/Therefore case 3 is not considered further in this document. /
- Is it therefore assumed that the MPEG-2 transmission equipment
(multiplexors, etc) are secure? I think this was suggested on the list?
---