[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