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

Re: Security Considerations section for

OK here is my take on the coping:

Rod.Walsh@nokia.com wrote:


I think it is a wonderful idea to properly consider IPDVB security requirements. I would just like a sanity check that I still understand the field of what the group would consider. Are these statements about right?

* IP-layer/level security (IPsec, MSEC, etc) provides a handful of solutions. Use of these and further specification of IP-layer security is beyond the IPDVB solution scope.
- These are IP-level solutions, it would be reasonable to advocate their use, both with MPE, ULE and any associated network protocols. I would suggets it *is* reaonable to discuss these in the context of this list - If there is (which I have no indication of) any further development work required to update the specs specifically for DVB/MPEG-2, the actual work would probably be done within a security area working group. 


* security above IP-layer (DRM, SRTP, etc) are well beyond IPDVB solution scope.


- Agreed.


* security on MPEG-2 TS (CA, etc) is beyond IPDVB (and IETF) solution scope.
- The set of currently defined mechanisms will not be re-specified or developed within this WG under the Charter specified. It was my understanding that Conditional Access (CA) systems are generally proprietary, and few target IP services.
* If necessary, ULE security mechanisms would be IPDVB solution scope. 
- Yes, the transport of encrypted IP data is within scope.
- Security also need to be considered in respect of the control protocols used to provide the IP service.... 


Am I roughly on target with these?

Yes, that's a useful summary.


If so, then the use of the IPDVB Security Requirements is clear to me: 1. assess whether any IPDVB security requirements should be met by the ULE-layer and the IPDVB deliverables that would be needed for this; 2. for other IPDVB security requirements determine whether additional work in other WGs is necessary.

BTW, it may also help to describe any security problems MPE deployments currently leave open. (Currently I am ignorant of any in MPE-layer scope).

- Any inputs from the list?


Cheers, Rod.




-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On 
Behalf Of ext Allison, Art
Sent: Thursday, March 25, 2004 6:01 PM
To: 'ip-dvb@erg.abdn.ac.uk'
Subject: RE: Security Considerations section for



Sniped part and replied..

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
Sent: Thursday, March 25, 2004 4:48 AM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: Security Considerations section for
I'm quite happy to try to summarise the security thread - or get someone else to - I'll leave it a few days to see if there are any comments/issues 
from other people to add.

I have a small number of questions for clarifications...
...
<snip>

Art Allison wrote:
Second, it seems out of scope to put elements in the RF 
emissions that
belong in the contribution process. It seems that you are 
concerned about

attacks on the data flow up to the RF emission. This is a valid and
important concern; but seemingly not relevant to a light 
weight emission

Protocol.

Gorry Fairhurst asked:
Would such contribution feeds normally use MPEG-2 transmission?
AA responds> They generally do although not necessarily in strict compliance with the MPEG-2 transport standard. Often 45Mpbs per RF channel with higher 
profile and level is used so that the content can survive decoding and
recoding. Some are distributing at payload rates. ATM is used by some (with 
MPEG-2 packet mapping onto the ATM cells).

Gorry Fairhurst asked:
To what extent do you envisage these TV contribution feeds to carry IP
packet data?
Art responds> Perhaps lots, perhaps little, but MUCH more importantly the contribution contains very valuable content to the broadcaster, that normally they are contractually bound to protect anyway. It contains the A/V programming and 
lots of folks would like to rip that off. So, I would specify that
everything in the contribution link be protected with encryption and that further I would not want it to be standard as that increases the size of the target for attackers. The two ends of a contribution link have always worked 
best when they come from the same vendor anyway.  There are several
approaches to protect an entire link, but protection of this feed is not the job of the particular type of content embedded therein. If you assert that you should put protection on ULE content type, to be logically consistent you would have to assert that each content type have a protection scheme at this layer. If the threat is significant enough, (and for the contribution link I agree 
it is) protect it ALL.
But that protection-for-it-all is out of scope here and is already being used today (I am not aware of any in-the-clear contribution links in the US.)