Re: Security Considerations section for

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

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


On 22/3/04 10:50 am, Haitham Cruickshank wrote:
<snip>

> The material in my previous email (Security Considerations section for
> draft-fair-ipdvb-req-04.txt) are taken from two source:
> 
> * draft-ietf-pilc-link-design-15.txt:  This document has the consensus of many
> people in the IETF,...

Exactly what I would hope - the PILC WG wrote this to help collect wisdom on
IETF aspects for links supporting IP, it should very soon be a BCP RFC.

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

Would such contribution feeds normally use MPEG-2 transmission?

To what extent do you envisage these TV contribution feeds to carry IP
packet data?

----------------
<snip>

HC> The vulnerability refers to two separate issues:
HC> 1. Satellite and wireless links are more vulnerable to attacks such as
HC> eavesdropping and traffic analysis due to the broadcast nature of these
HC >links.
AA> Anyone can listen, true. So what? If a user wants to avoid traffic
AA> analysis they could send data all the time...the valid receiver
AA> will toss the filler as presumably the content would be important
AA> to protect at a higher level (IP->UDP->application).

I'm not sure what it is we are trying to hide by encryption to prevent
traffic anaylsis of the IP service - Is it the volume of TS-Packets that are
sent by the satellite operator per PID or the ability to measure the traffic
per Receiver (i.e. Destination MAC/IP address of an individual ISP
customer).


Gorry Fairhurst