Subject: RE: Security Considerations section for

From: "Allison, Art" <[email-masked]>
Date: Thu, 25 Mar 2004 11:00:53 -0500

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:[email-masked]]
Sent: Thursday, March 25, 2004 4:48 AM
To: [email-masked]
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.)

---

From: <[email-masked]>
Date: Wed, 31 Mar 2004 09:06:04 +0300

Hi

Thanks for the responses, I think I'm reading from the same page.

On one issue...

> > >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?
> 
> Here is some limited input on the security problems with MPE 
> deployments:
> 
> DVB-CA is mainly implemented in the MPEG-TS layer.  The MPE 
> security procedures are defined in the current DVB-RCS 
> standard (ETSI EN 301 790). The MPE security major problem is 
> that security features are optional. Therefore (I think) many 
> people do not implement them.  Another problem is that there 
> is not efficient
> support for secure multicast (secure group communication).

..that problem is in the scope of two-way communications with RCS - right?

What kind of TS, MPE, IP (or other) kinds of solutions would be appropriate? (e.g. are there any issues on the efficient support for secure multicast which would not be MSEC/IP-layer level issues?)

Cheers, Rod.