Subject: RE: Security Considerations section for draft-fair-ipdvb-req-04. txt

From: "Allison, Art" <[email-masked]>
Date: Wed, 17 Mar 2004 09:16:36 -0500

The suggestion made in the email from Haitham Cruickshank did not seem a
reasonable one to me; but I stand ready to hear additional, relevant
reasons.  To start, I would like to probe the reasons  that I found lacking
in applicability a bit.. see embedded excerpts and responses.

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418

-----Original Message-----
From: Haitham Cruickshank [mailto:[email-masked]]
Sent: Wednesday, March 17, 2004 6:00 AM
To: [email-masked]
Subject: Security Considerations section for draft-fair-ipdvb-req-04.txt

Hi All,
<snip>

However, subnetwork security is important [LINK] and should be
encouraged, on the principle that it is better than the default
situation, which all too often is no security at all.  Users of
especially vulnerable subnets (such as radio/broadcast networks and /or
shared media Internet access) often have control over at most one
endpoint - usually a client and therefore cannot enforce the use of
end-to-end mechanisms.
AA> Just what is the alleged vulnerability? To what exactly?

A related role for subnetwork security is to protect users against
traffic analysis, i.e., identifying the communicating parties and
determining their communication patterns and volumes even when their
actual contents are protected by strong end-to-end security mechanisms
(this is important for networks such broadacst/radio, were
eaves-dropping is easy). 
AA> Let us explore this a bit. What communication pattern? All that I can
see is that the emission station sends x% of their packets using ULE. How is
a traffic analysis of any kind going to harm a broadcaster in any way?
Please describe how this a threat to the transmitter operator?
/ 

Finally an important role for subnetwork
security is the protection of the subnetwork itself.  Possible threats
to subnetwork assets include theft of service 

AA> Please explain what service is protected from being stolen by this
addition.
If the contents are not usable, (and each service has many means to so
insure), what can one do with these packets?
/

and denial of service;
shared media subnets tend to be especially vulnerable to such attacks
AA>I don't see this in the RF domain. One way to deny service from a DTV
transmitter is to create interfering RF energy that prevents reception.
While possible, RF DFing works fine to track down and eliminate the attacker
were it to occur- and it wipes out all reception, not just some packets. I
fail to see a motive for anyone to make such an investment, the cost of
which is directly related to the number of receivers interfered with. For a
satellite service it is much harder to interrupt as one must get into the
aperture of the antenna.

But you posit a even more complex and sophisticated attack... here is what I
think would be required to do selective denial of service at the MPEG packet
level:
One would have to demodulate the stream, then strip <just> the packets that
contain the service to be denied, the re-emit the altered stream (replacing
the deleted packets with null or faked packets) and recreate the RF
modulation. And even then the attacker would only affect those where he
could achieve local undesired to desired signal levels (as he has to
override the desired stream with his undesired stream).  
/

Security concerns not just the packet data being communicated, but also
the control protocols.
AA> Please explain how the control protocols could be altered in the real
word considering the RF systems.
/

Appropriate security functions must therefore be
provided for ipdvb support protocols [LINK].

AA> Please provide additional information to show what risk is mitigated in
order to support your assertion that this 'must' be done. So far you have
not enabled me to see any concrete basis for this complexity, nor that there
is even a very small real attack risk. 

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418

---

From: Haitham Cruickshank <[email-masked]>
Date: Mon, 22 Mar 2004 10:50:20 +0000

Hi again,

Before answering the specific issues that Art raised, I like to say that most of
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, where Gorry is a co-author.
* Mr. Laurent Claverotte email, where Alcatel are actively developing DVB-RCS
equipment.

See in-line for extra replies:

> Director Advanced Engineering

The vulnerability refers to two separate issues:

1. Satellite and wireless links are more vulnerable to attacks such as
eavesdropping and traffic analysis due to the broadcast nature of these links.
2. End users might not have control on the overall link such as the link between
the service provider and the satellite gateway.

> Please describe how this a threat to the transmitter operator?

Even if the information is encrypted, it is possible for intruders to identify
communicating parties identities from IP addresses (if not encrypted) or
satellite terminal MAC addresses.  Therefore intruders can identify the
satellite operator customers and this is really bad if the customer is a high
profile organization (such as UK MoD or US DoD).

> insure), what can one do with these packets?

This point is really about source authentication to prevent intruders from high
jacking a satellite link and pretending to be a legitimate user.

> AA>I don't see this in the RF domain.

Yes I agree it is difficult in the RF domain

> One way to deny service from a DTV

Yes agree.

> word considering the RF systems.

This is a system issues not RF. Control protocol refer to two areas:
* Connection establishment/termination messages
* Network management and routing messages.

If intruders can send bogus control/routing messages, then legitimate users
might experience denial of service attacks.

> is even a very small real attack risk.

It is interesting to see that you have such optimistic views about security
relating issues, where companies such as CANAL+   have paid a heavy price for
smart card frauds (DVB-S Conditional Access).

Haitham

--
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: [email-masked]
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 25 Mar 2004 09:47:30 +0000

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

---

From: Haitham Cruickshank <[email-masked]>
Date: Mon, 29 Mar 2004 15:35:10 +0100

Hi Gorry,

I am answering the last question.

> IETF aspects for links supporting IP, it should very soon be a BCP RFC.

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.

Senior Research Fellow

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Mon, 29 Mar 2004 10:10:44 -0500

> the traffic volume constant.  I hope this answers the question.
Although in any transmission over wireless media padding will just reduce
the ability to sell more bandwidth or to increase stat mux on the channel. I
think want is needed IMHO is to get a list/table of what is needed in terms
of security for the MPEG, what exists with plus and minuses, what is
non-adressed right now and the costs or perceived costs to solve remaining
problems. That's beyond just the requirement draft though.

Marie-Jose