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

From: "Allison, Art" <[email-masked]>
Date: Mon, 22 Mar 2004 16:37:42 -0500

It seems we must have a different environment and application in mind and
therefore may be talking past each other.

It seems that you envision some of the traffic being directed to a narrow
set of users (transported by the RF), who will have the keys to de scramble
the packets, and who don't want anyone to know the amount of their traffic.
If just these users' traffic is scrambled the traffic analysis can still
reveal changes in the total amount of private (scrambled) data. <the
solution to that is to scramble everything, which leads to the need to
address the key management and distribution issues--but that does not seem
to be a light weight approach.>

I thought this was a Broadcast means, not a narrowcast means. If one were to
dedicate part of the bandwidth to send sensitive data, do so in a private
manner, not a internationally standardized one.  Why give an attacker any
information at all? And as one has to get the CA system in place for these
users, any protocol can do that (can even use a PID that is not in the PMT).

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.
Certainly, these elements are appropriate to consider when it is practical
to replace packets. 

Protection vs. replacement packets in the RF domain is just overkill.
See comments below...
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: Monday, March 22, 2004 5:50 AM
To: [email-masked]
Subject: Re: Security Considerations section for
draft-fair-ipdvb-req-04.txt

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:

"Allison, Art" wrote:

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

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.
AA> Anyone can listen, true. So what? If a user wants to avoid traffic
analysis they could send data all the time...the valid receiver will toss
the filler as presumably the content would be important to protect at a
higher level (IP->UDP->application). 

2. End users might not have control on the overall link such as the link
between
the service provider and the satellite gateway.
AA> Seems out of scope hypothetical... that is contribution control not
emission transport control.  End users=consumers to me, not a broadcaster.
This is for an MPEG-2 stream, and if it is important to protect a
contribution link, the entire stream can be scrambled for protection.
>
>
> 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?
> /

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

AA> So the attack you think we need to protect against my this level
scrambling is increased traffic FROM a particular IP address (or set) that
is associated with a particular user that is being broadcast using RF to get
to many locations? Further the amount of traffic need to matter to the
sending org and the org does not want to pay for a steady data stream of
IP-level protected material; constant flows are the only way to protect
against traffic analysis.  Or can we expect  to hear next that ALL TS
packets with ULE need this so that certain important packets are disguised 
Do you have a statement from any such organization that they want to use
this means?  As to MAC address, did I miss the requirement for a return
channel to make this work? This is one-way only.
>
>
> 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?
> /

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

AA> Protection against this attack is important, but hardly addressed by
scrambling inside some of the transport packets. Contribution links need
security, but not at this level, where it does nothing to protect the rest
of the transport packets. As a broadcaster, I am concerned about my video
being so attacked and replaced, not just the ULE packets in the TS - and
therefore the entire link needs to be protected by means appropriate to the
attack risk.
>
>
> 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.

Yes I agree it is difficult in the RF domain
AA> I thought that ALL the intended use is in the RF domain. Wired networks
have addressed this issue, of course. It makes zero sense to put MPEG-2
packets which have <this Rec IP packets> into IP packets and expect such
buried security to prevent much of anything.

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

Yes agree.

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

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.

AA> Again, true but out of scope-- protection of contribution links is the
job of the link not the job of some of the packets in the payload of that
link.
>
> 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.

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

AA> And as to optimistic, well I learned at the CIA that one can be certain
that attacks will occur if there is something to be gained by the attacker.
And the something can just be pride in doing so. But all I see here is a
push to get more technology into the draft that just increases complexity
and provides no practical protection. The first step in deciding what
security is appropriate is a risk analysis. I have not seen a case for an
international recommendation to have this <even for the contribution attacks
postulated>.  

Haitham

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

--
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: Haitham Cruickshank <[email-masked]>
Date: Tue, 23 Mar 2004 10:10:41 +0000

Hi again,

The several issues raised at Art's email are interesting, but I feel it is going
too far into the security related issues, which is not the main focus of the
group.

I think the security consideration for IP over DVB should be filled objectively
and should satisfy two major requirements:

1. The security complexity should be considered carefully so that it will not
impact the IP over DVB operation severely
2. The security solution must be conform with IETF views on security and the
Internet operations in general.

Finally,  I think it is time for Gorry to summarize the security related
discussions and progress towards the exact text to be put in the requirements
and/or the ULE documents.

Haitham

Senior Research Fellow

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 26 Mar 2004 12:13:11 +0000

Trying to draw together the security inputs suggests a general need for more
precise scenarios that exhibit different properties/requirements, this also
will be useful when describing other protocols used to build the IP over
MPEG service. Can I ask for inputs to help draw up this list of scenarios?

Here is a start (from looking through the mailing list):

1) Art's recent inputs to the security thread seem oriented to TV-style
networks ("contribution" and "broadcast").  In the broadcast context,
transmission goes to many Receivers (unidirectional star) and IP packets can
be integrated with TV/radio transmission channels. The broadcast part of the
networks are characterised by a large population of receivers that may
receive the same bit stream.

2) Laurent Claverotte's focus was oriented to two-way satellite IP provision
- where the MPEG transmission network provides a physical & link technology
for a two-way star IP network (DVB-RCS). Organisation is currently usually
based around a star toplogy, in which a central hub station acts as the
gateway to the wider Internet.

Other scenarios include:

3) Point-to-point network links can be used to connect between Internet
Service Providers - these typically have no TV content - and use MPEG as
just a physical & link technology, many use the same technology (e.g. DVB-S)
in both directions. Such networks are characterised by a small number of
receivers for each transmitted bit stream.

4) Point-to-multipoint networks where the outbound link uses broadcast
technology (possibly shared with TV/radio?) and the return link uses some
other technology (e.g. Modem, LMDS, GPRS, ...).  Such networks could utilise
UDLR protocols for routing [RFC3077].

Are there more important cases, that I have missed?

What about cable networks, cellular DVB-T, mobile DVB-T, mesh DVB-RCS?

A typical usage could be:

End-host<-->IP network<-->IP network
                               |
                          IP gateway<->MPEG-2 network<-> Receiver
                                                            |
                                          End-host<-->IP network

Where the middle line represents the "MPEG-2" part of the internet path, in
this case  the end users are the people using the end-hosts.

Gorry Fairhurst.