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

Re: Security Considerations section for



Hi Gorry,

I am answering the last question.

Gorry Fairhurst wrote:

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

Yes.  The volume of traffic and timing can give away some information about
receiver/sender activities.  In extremely important security situations and low
activities, the traffic can be padded with random data (before encryption) to keep
the traffic volume constant.  I hope this answers the question.

>
>
> Gorry Fairhurst

--
Dr. Haitham S. Cruickshank

Senior Research Fellow
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/