RE: Security Considerations section for

["Allison, Art" <AAllison@nab.org>]

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