RE: Security Considerations section for

[<Rod.Walsh@nokia.com>]

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.
* security above IP-layer (DRM, SRTP, etc) are well beyond IPDVB solution scope.
* security on MPEG-2 TS (CA, etc) is beyond IPDVB (and IETF) solution scope.
* If necessary, ULE security mechanisms would be IPDVB solution scope.

Am I roughly on target with these?

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

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