Subject: RE: ULE Security Requirements : NiTs on text

From: <[email-masked]>
Date: Fri, 1 Dec 2006 18:59:04 -0000

Hi All,
Please find the comments inline. All the comments are incorporated in the new version of the draft ( a diff of this will be posted on the IPDVB mailing list for comments)

Cheers
Sunny
 
________________________________

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,

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/

//Sunny

DONE

done                                                  ^
--
/these messages are broadcasted/
                             ^^
/these messages are broadcast/

//Sunny

done
---
/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...

//Sunny

//Agree with this and have added a reference to it

---
/ The PID associated with an Elementary Stream can be modified /
/ The PID associated with an Elementary Stream can therefore be modified/
                                                   ^^^^^^^^^
//Sunny

done

/a passive threat. It includes/
/a passive threat. This includes/
                   ^^^^
//Sunny

done

----
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.

//Sunny

any suggestions ?????
----

/defines services for Internet Protocol (IP)/
/defines services for the Internet Protocol (IP)/
     //Sunny

done                ^^^
---
/There is an extra overheads associated /
/There is an extra transmission overhead associated /
                   ^^^^^^^^^^^^^^^^^^^^^^
- is this what is meant?

//Sunny

Yes and its changed
---
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...

//Sunny

Added as a new requirement
---
/   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.

//Sunny

//Have rewritten it reflect the change

----
/ 2 NPA address. In broadcast networks this can /
/ 2 NPA address. In broadcast networks this protection can /

//Sunny

//Done
                                            ^^^^^^^^^^
---
/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?

//SUnny

Done

---

Thanks 

Sunny

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 01 Dec 2006 19:32:19 +0000

Thanks Sunny for doing all those edits, and responding to my questions.

You specifically asked for clarification on:

<snip>

Section 3.2

//Sunny

any suggestions ?????

GF - I was thinking here that a key driver in the design of IPsec, and 
one that is often stated by our security ADs is that one must protect 
from masquerading and modification of IP packets, this being 
comparatively easy in an Internet environment. So, my suggestion was to 
agree with such arguments, but then to state for link-layer security fro 
broadcast links that you note such attacks are in fact MUCH harder.
- This could for instance motivate the use of sequence numbers in IPsec, 
but not the mandatory use of them on synchronous links.

<snip>

and on:

<snip>
4) I would like to see more references to methods used by DVB/MPEG-2 
network architectures ...
* How is the proposal positioned against technologies from say the IEEE 
(for 802.14; 802.16).

//Sunny

//Any suggestions ?????

<snip>

- I don't know the answer... does anyone else?

I now suggest that you make a new revision of the draft and upload to 
the web site (I can do this for you), so we can see the interim version, 
and see if Michael and others can see if they have anything more to add 
at this stage.

Gorry