Subject: ULE Security Requirements : NiTs on text

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 21 Nov 2006 17:56:50 +0000

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?

---

---

From: <[email-masked]>
Date: Thu, 23 Nov 2006 17:45:49 -0000

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: [email-masked] on behalf of Gorry Fairhurst
Sent: Tue 21/11/2006 17:56
To: [email-masked]
Subject: ULE Security Requirements : NiTs on text

Dear authors,

Best wishes,

Gorry

----
Page 7:

----

---