[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ULE Security Requirements : NiTs on text



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: 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/


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






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: 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/


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