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

RE: Security-Requirements: alternatives?



Hi again Art,
 
May be we should get the terminology right first. 
 
A typical usage is for the ULE Stream sent on a single PID to carry unicast or multicast packets with several different IP destination addresses (and therefore corresponding different MAC addresses). The aim of ULE security is therefore to secure the L2 conversations between each Receiver and the Encapsulator that generates the corresponding ULE stream.  
 
Also it is possible to do a more fine grain security (per IP flow), depending on the security association which is part of a key management system.
Haitham 

 
----
Dr. Haitham S. Cruickshank 
Lecturer 
Communications Centre for Communication Systems Research (CCSR) 
School of Electronics, Computing and Mathematics 
University of Surrey, Guildford, Surrey GU2 7XH, UK 
 
Tel: +44 1483 686007 (indirect 689844) 
Fax: +44 1483 686011 
e-mail: H.Cruickshank@surrey.ac.uk 
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 

________________________________

From: owner-ipdvb@erg.abdn.ac.uk on behalf of Allison, Art
Sent: Mon 26/06/2006 16:15
To: ipdvb@erg.abdn.ac.uk
Subject: RE: Security-Requirements: alternatives?


Perhaps I misunderstood, but I thought that the approach chosen in ULE was for there to be one logical channel per PID ["...locate a specific ULE Stream (i.e., the PID value of the TS Logical Channel that carries a ULE Stream)"] as contrasted with multiple logical channels carried in MPEG-2 TS packets with a single PID.
 
The discovery of 'logical channels' carried in IP packets delivered  via MPEG-2 TS packets with a single PID appears to not be standardized.  Perhaps this falls into the general case of any IP delivery. If so,  separate security access for each distinct element a functionality that A/70A would not provide.
 
But then it seems to me to not be different than the functionality provided for by existing RFCs for security of arbitrary content delivered using IP encapsulation, i.e., https: and such
 
If it is general purpose IP, then it seems to me that the proposal should make a case that the current RFCs fail to meet the requirements asserted to be needed.  If it is 'logical channel' protection, then it is different that the general case.
 
But perhaps I have not been following this in adequate depth - and I waste your time,
If so - no need to attempt to educate me.
Regards, 
Art

_____________ 
Art Allison 
Director, Advanced Engineering 
Science & Technology 
National Association of Broadcasters 
1771 N Street, NW 
Washington, D.C. 20036 
Phone: 202.429.5418 
Fax: 202.777.4981 
aallison@nab.org <mailto:aallison@nab.org>  

The National Association of Broadcasters is a trade association that advocates on behalf of more than 8,300 free, local radio and television stations and also broadcast networks before Congress, the Federal Communications Commission and the Courts.

 


________________________________

	From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of H.Cruickshank@surrey.ac.uk
	Sent: Saturday, June 24, 2006 5:01 AM
	To: ipdvb@erg.abdn.ac.uk; ipdvb@erg.abdn.ac.uk; gorry@erg.abdn.ac.uk; S.Iyengar@surrey.ac.uk; P.Pillai@Bradford.ac.uk
	Subject: RE: Security-Requirements: alternatives?
	
	
	Hi Art,
	 
	Many thanks for your input:
	 
	********************
	* Conditional access for digital TV broadcasting is one example that
	exists today.  This system is optimised for TV broadcast services only,
	and is not suitable for IP packet transmissions and difficult to
	interwork with ULE.
	AA> See ATSC A/70A. I strongly disagree with assertion about the
	difficulty to interwork with ULE. The ULE can be put in a virtual
	channel in the ATSC system and the standard directly applied.
	*******************
	 
	I completely agree with you that  A/70A (Conditional Access System for Terrestrial Broadcast, Revision A) can interwork with ULE, where encryption is based on PIDs, which sometimes means bundling many IP flows with one PID.  In our draft (ULE requirements), we aim for more fine grain security and securing every IP flow individually and try to re-use existing work in the IETF on key management.
	 
	Accidentally reading through A/70A, it looks much better than the  DVB Conditional Access.  I personally do not have much faith in DVB Conditional Access (DVB CA): You might probably know that DVB CA has been surrounded by controversy for many years due to the spread of counterfeit smart cards.  For example, in late 1999, Italy was flooded with cheap counterfeit cards that enabled viewers use Canal Plus for free.  In March 2002 Canal Plus Group filed a  lawsuit against NDS Group, accusing it of cracking its digital television smart cards and putting the confidential information on the Internet.  Since then, I have not seen any major changes in DVB CA to cater for these challenges. 
	 
	Haitham
	
	----
	Dr. Haitham S. Cruickshank 
	Lecturer 
	Communications Centre for Communication Systems Research (CCSR) 
	School of Electronics, Computing and Mathematics 
	University of Surrey, Guildford, Surrey GU2 7XH, UK 
	 
	Tel: +44 1483 686007 (indirect 689844) 
	Fax: +44 1483 686011 
	e-mail: H.Cruickshank@surrey.ac.uk 
	http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 

________________________________

	From: owner-ipdvb@erg.abdn.ac.uk on behalf of Allison, Art
	Sent: Thu 22/06/2006 20:02
	To: ipdvb@erg.abdn.ac.uk; gorry@erg.abdn.ac.uk; Iyengar S Mr (CCSR); P.Pillai@Bradford.ac.uk
	Subject: RE: Security-Requirements: alternatives?
	
	

	See below.
	
	
	_____________
	Art Allison
	Director, Advanced Engineering
	Science & Technology
	National Association of Broadcasters
	1771 N Street, NW
	Washington, D.C. 20036
	Phone: 202.429.5418
	Fax: 202.777.4981
	aallison@nab.org
	
	The National Association of Broadcasters is a trade association that
	advocates on behalf of more than 8,300 free, local radio and television
	stations and also broadcast networks before Congress, the Federal
	Communications Commission and the Courts.
	
	-----Original Message-----
	From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
	Behalf Of H.Cruickshank@surrey.ac.uk
	Sent: Thursday, June 22, 2006 2:09 PM
	To: gorry@erg.abdn.ac.uk; ipdvb@erg.abdn.ac.uk; S.Iyengar@surrey.ac.uk;
	P.Pillai@Bradford.ac.uk
	Subject: RE: Security-Requirements: alternatives?
	
	 Hi Gorry,
	
	This issue has been addressed in the security draft.   Some text has
	been added to section 5.1 to this effect:
	
	Basically, in practice there are not many L2 security systems for MPEG
	transmission networks.  Two major examples are:
	
	* Conditional access for digital TV broadcasting is one example that
	exists today.  This system is optimised for TV broadcast services only,
	and is not suitable for IP packet transmissions and difficult to
	interwork with ULE.
	AA> See ATSC A/70A. I strongly disagree with assertion about the
	difficulty to interwork with ULE. The ULE can be put in a virtual
	channel in the ATSC system and the standard directly applied.
	
	* Some other L2 security systems are specified in standards such the MPE
	for DVB system . However, MPE security incomplete and there are no known
	implementations of such security system.
	
	* For DVB-S2 Generic Streams, where IP encapsulation could be similar to
	ULE. The authors believe that ULE security format can be used for
	Generic Streams as well.
	
	We would like to ask the ipdvb WG if anybody knows any other existing L2
	security systems that might be suitable for ULE.
	
	AA> See ATSC A/70A for ULE when sent in conformance with ATSC Standards.
	
	Haitham
	----
	
	Dr. Haitham S. Cruickshank
	
	Lecturer
	Communications Centre for Communication Systems Research (CCSR) School
	of Electronics, Computing and Mathematics University of Surrey,
	Guildford, Surrey GU2 7XH, UK
	
	Tel: +44 1483 686007 (indirect 689844)
	Fax: +44 1483 686011
	e-mail: H.Cruickshank@surrey.ac.uk
	http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
	
	
	
	-----Original Message-----
	From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
	Sent: 22 June 2006 15:37
	To: Cruickshank HS Dr (CCSR); ipdvb@erg.abdn.ac.uk; Iyengar S Mr (CCSR);
	P.Pillai@Bradford.ac.uk
	Subject: Security-Requirements: alternatives?
	
	Haitham, I-D Authors, List,
	
	One of the issues we need to be clear about in preparing for a WG
	adoption of the security requirements I-D is the possible alternatives
	that have been proposed/implemented in other standards organisations.
	
	Could you summarise the methods that have been proposed for MPEG-2
	transmission networks that provide equivalent L2 security functions, and
	say which to your knowledge has actually have been implemented in
	systems?
	
	Thanks,
	
	Gorry
	
	
	
	

Hi again Art,
 
May be we should get the terminology right first. 
 
A typical usage is for the ULE Stream sent on a single PID to carry unicast or multicast packets with several different IP destination addresses (and therefore corresponding different MAC addresses). The aim of ULE security is therefore to secure the L2 conversations between each Receiver and the Encapsulator that generates the corresponding ULE stream.  
 
Also it is possible to do a more fine grain security (per IP flow), depending on the security association which is part of a key management system.
Haitham 

 
----
Dr. Haitham S. Cruickshank 
Lecturer 
Communications Centre for Communication Systems Research (CCSR) 
School of Electronics, Computing and Mathematics 
University of Surrey, Guildford, Surrey GU2 7XH, UK 
 
Tel: +44 1483 686007 (indirect 689844) 
Fax: +44 1483 686011 
e-mail: H.Cruickshank@surrey.ac.uk 
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 

________________________________

From: owner-ipdvb@erg.abdn.ac.uk on behalf of Allison, Art
Sent: Mon 26/06/2006 16:15
To: ipdvb@erg.abdn.ac.uk
Subject: RE: Security-Requirements: alternatives?


Perhaps I misunderstood, but I thought that the approach chosen in ULE was for there to be one logical channel per PID ["...locate a specific ULE Stream (i.e., the PID value of the TS Logical Channel that carries a ULE Stream)"] as contrasted with multiple logical channels carried in MPEG-2 TS packets with a single PID.
 
The discovery of 'logical channels' carried in IP packets delivered  via MPEG-2 TS packets with a single PID appears to not be standardized.  Perhaps this falls into the general case of any IP delivery. If so,  separate security access for each distinct element a functionality that A/70A would not provide.
 
But then it seems to me to not be different than the functionality provided for by existing RFCs for security of arbitrary content delivered using IP encapsulation, i.e., https: and such
 
If it is general purpose IP, then it seems to me that the proposal should make a case that the current RFCs fail to meet the requirements asserted to be needed.  If it is 'logical channel' protection, then it is different that the general case.
 
But perhaps I have not been following this in adequate depth - and I waste your time,
If so - no need to attempt to educate me.
Regards, 
Art

_____________ 
Art Allison 
Director, Advanced Engineering 
Science & Technology 
National Association of Broadcasters 
1771 N Street, NW 
Washington, D.C. 20036 
Phone: 202.429.5418 
Fax: 202.777.4981 
aallison@nab.org <mailto:aallison@nab.org>  

The National Association of Broadcasters is a trade association that advocates on behalf of more than 8,300 free, local radio and television stations and also broadcast networks before Congress, the Federal Communications Commission and the Courts.

 


________________________________

	From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of H.Cruickshank@surrey.ac.uk
	Sent: Saturday, June 24, 2006 5:01 AM
	To: ipdvb@erg.abdn.ac.uk; ipdvb@erg.abdn.ac.uk; gorry@erg.abdn.ac.uk; S.Iyengar@surrey.ac.uk; P.Pillai@Bradford.ac.uk
	Subject: RE: Security-Requirements: alternatives?
	
	
	Hi Art,
	 
	Many thanks for your input:
	 
	********************
	* Conditional access for digital TV broadcasting is one example that
	exists today.  This system is optimised for TV broadcast services only,
	and is not suitable for IP packet transmissions and difficult to
	interwork with ULE.
	AA> See ATSC A/70A. I strongly disagree with assertion about the
	difficulty to interwork with ULE. The ULE can be put in a virtual
	channel in the ATSC system and the standard directly applied.
	*******************
	 
	I completely agree with you that  A/70A (Conditional Access System for Terrestrial Broadcast, Revision A) can interwork with ULE, where encryption is based on PIDs, which sometimes means bundling many IP flows with one PID.  In our draft (ULE requirements), we aim for more fine grain security and securing every IP flow individually and try to re-use existing work in the IETF on key management.
	 
	Accidentally reading through A/70A, it looks much better than the  DVB Conditional Access.  I personally do not have much faith in DVB Conditional Access (DVB CA): You might probably know that DVB CA has been surrounded by controversy for many years due to the spread of counterfeit smart cards.  For example, in late 1999, Italy was flooded with cheap counterfeit cards that enabled viewers use Canal Plus for free.  In March 2002 Canal Plus Group filed a  lawsuit against NDS Group, accusing it of cracking its digital television smart cards and putting the confidential information on the Internet.  Since then, I have not seen any major changes in DVB CA to cater for these challenges. 
	 
	Haitham
	
	----
	Dr. Haitham S. Cruickshank 
	Lecturer 
	Communications Centre for Communication Systems Research (CCSR) 
	School of Electronics, Computing and Mathematics 
	University of Surrey, Guildford, Surrey GU2 7XH, UK 
	 
	Tel: +44 1483 686007 (indirect 689844) 
	Fax: +44 1483 686011 
	e-mail: H.Cruickshank@surrey.ac.uk 
	http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 

________________________________

	From: owner-ipdvb@erg.abdn.ac.uk on behalf of Allison, Art
	Sent: Thu 22/06/2006 20:02
	To: ipdvb@erg.abdn.ac.uk; gorry@erg.abdn.ac.uk; Iyengar S Mr (CCSR); P.Pillai@Bradford.ac.uk
	Subject: RE: Security-Requirements: alternatives?
	
	

	See below.
	
	
	_____________
	Art Allison
	Director, Advanced Engineering
	Science & Technology
	National Association of Broadcasters
	1771 N Street, NW
	Washington, D.C. 20036
	Phone: 202.429.5418
	Fax: 202.777.4981
	aallison@nab.org
	
	The National Association of Broadcasters is a trade association that
	advocates on behalf of more than 8,300 free, local radio and television
	stations and also broadcast networks before Congress, the Federal
	Communications Commission and the Courts.
	
	-----Original Message-----
	From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
	Behalf Of H.Cruickshank@surrey.ac.uk
	Sent: Thursday, June 22, 2006 2:09 PM
	To: gorry@erg.abdn.ac.uk; ipdvb@erg.abdn.ac.uk; S.Iyengar@surrey.ac.uk;
	P.Pillai@Bradford.ac.uk
	Subject: RE: Security-Requirements: alternatives?
	
	 Hi Gorry,
	
	This issue has been addressed in the security draft.   Some text has
	been added to section 5.1 to this effect:
	
	Basically, in practice there are not many L2 security systems for MPEG
	transmission networks.  Two major examples are:
	
	* Conditional access for digital TV broadcasting is one example that
	exists today.  This system is optimised for TV broadcast services only,
	and is not suitable for IP packet transmissions and difficult to
	interwork with ULE.
	AA> See ATSC A/70A. I strongly disagree with assertion about the
	difficulty to interwork with ULE. The ULE can be put in a virtual
	channel in the ATSC system and the standard directly applied.
	
	* Some other L2 security systems are specified in standards such the MPE
	for DVB system . However, MPE security incomplete and there are no known
	implementations of such security system.
	
	* For DVB-S2 Generic Streams, where IP encapsulation could be similar to
	ULE. The authors believe that ULE security format can be used for
	Generic Streams as well.
	
	We would like to ask the ipdvb WG if anybody knows any other existing L2
	security systems that might be suitable for ULE.
	
	AA> See ATSC A/70A for ULE when sent in conformance with ATSC Standards.
	
	Haitham
	----
	
	Dr. Haitham S. Cruickshank
	
	Lecturer
	Communications Centre for Communication Systems Research (CCSR) School
	of Electronics, Computing and Mathematics University of Surrey,
	Guildford, Surrey GU2 7XH, UK
	
	Tel: +44 1483 686007 (indirect 689844)
	Fax: +44 1483 686011
	e-mail: H.Cruickshank@surrey.ac.uk
	http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
	
	
	
	-----Original Message-----
	From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
	Sent: 22 June 2006 15:37
	To: Cruickshank HS Dr (CCSR); ipdvb@erg.abdn.ac.uk; Iyengar S Mr (CCSR);
	P.Pillai@Bradford.ac.uk
	Subject: Security-Requirements: alternatives?
	
	Haitham, I-D Authors, List,
	
	One of the issues we need to be clear about in preparing for a WG
	adoption of the security requirements I-D is the possible alternatives
	that have been proposed/implemented in other standards organisations.
	
	Could you summarise the methods that have been proposed for MPEG-2
	transmission networks that provide equivalent L2 security functions, and
	say which to your knowledge has actually have been implemented in
	systems?
	
	Thanks,
	
	Gorry