RE: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt

[George Gross <gmgross@nac.net>]

Hi Art,

On Mon, 14 Aug 2006, Allison, Art wrote:

> <long timers can skip this post-nothing new here>
>
> I have not contributed my point of view in a long time, but the last
> line of this post prompts me to do so once again in hopes that some
> new participants will at least have more information about MPEG-2 TS
> and RF distribution.
>
> When the MPEG-2 TS ULE packets are delivered via an RF channel; be it
> over cable, satellite, or terrestrial; to succeed in an attack, the RF
> signal must be over powered.  If the attacker can do that, they can
> replace the entire stream (or indeed they could receive the stream and
> selectively substitute some packets-but why?).

One of the use cases for IPDVB is as an intra-company virtual LAN (e.g.
several dozen SOHO distributed over a region). In this trust model, the IP
communications between peer LAN endpoints would normally be considered
reliable and they would not be authenticated or encrypted at the IP layer.
Even if one did apply IPsec, this would negatively interact with PEP
sessions. In this scenario, the Adversary's motivation is economic and
dependent on the value of the company information that could be
compromised by eavesdropping or alteration.

One could envision all kinds of mischief if an Adversary were able to
intercept and alter those communications at the IPDVB Layer-2. So the
"why" is entirely up to the Adversary's game plan.

>  However, the risk
> assessment should consider the practical difficulties and potential
> benefits of the attack mode.  A mobile truck could indeed deny service
> to a small radius of terrestrial receivers, perhaps even to a smaller
> radius or satellite receivers, and a cable cut on a pole can wipe out
> an entire area.  These attacks are difficult to mount and easy to
> detect and counter.

The perceived difficulty of attack is an illusion, it would hardly deter a
well funded Adversary such as an organized crime family or a rogue nation
state. All they'd need for motivation is either a high value target, or
else a design a mobile wireless unit that would attack a number of lower
value targets. Expecting these victems to anticipate, detect, and counter
such attacks (especially when wireless), is optimistic.

>    If one is concerned about protection of the distribution link,
> [where the packets are themselves sent as part of an entire MPEG-2 TS
> using another protocol such as TCP or AVT], that seems better done by
> protecting the protocol delivering the entire set of packets, rather
> than within the packet.

A more pragmatic security policy is defence in depth, in which every layer
in the protocol stack participates in securing the application end to end.

Unfortunately, satellite communications that use PEP will have problems
with IPsec gateways at layer-3. In contrast, a layer-2 encryption and
authentication protocol is transparent to PEP. Layer-2 encryption also has
the benefit that the IP traffic temporarily transiting a satellite
sub-network (i.e.  terrestrial link fail-over) does not require the remote
layer-3 endpoints to define security policies contingent on the change in
their IP packet's routing path.

>  And there is a long-defined method for
> protecting the entire contents of an MPEG-2 packet, independent of its
> payload (which can be employed on a PID by PID basis).

We have already established on this list several months back that the PID
does not offer the fine granularity of key management needed to secure IP
over MPEG and ULE.

>
> I still see placing security at the ULE level as unneeded, even a
> 'poor' design choice, but having a standard to enable a solution
> should this design choice be made is perhaps better than not having
> one.

As explained above, layer-2 security is hardly a "poor" design choice.
Rather, it represents another tool in the MPEG-2 network operator's
security toolchest.

br,
	George

>
> Art
> _____________
> Art Allison
> Director, Advanced Engineering
> Science & Technology
> National Association of Broadcasters
> 1771 N Street, NW
> Washington, D.C. 20036
> Phone: 202.429.5418
> Fax: 202.777.4981
> aallison@nab.org
>
> The National Association of Broadcasters is a trade association that advocates on behalf of more than 8,300 free, local radio and television stations and also broadcast networks before Congress, the Federal Communications Commission and the Courts.
>
> -----Original Message-----
> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Michael Noisternig
> Sent: Monday, August 14, 2006 5:51 AM
> To: ipdvb@erg.abdn.ac.uk
> Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt
>
> Hello everyone,
>
> this is my first post here, so just a few words to introduce myself...
> I'm a student of computer science and mathematics at the University of Salzburg, and I've been working as a project assistent in the areas of ULE and security for a couple of months now. I'm currently working on a draft that is hopefully going to be released soon.
>
> I've read the current version of the ULE security requirements draft, and there are few things I want to comment on. The first thing is, it reads a lot better now than the last version I read (-01). :-)
>
> So here are my other comments:
>
> §3.2, last paragraph:
> - data integrity alone does not provide authentication
> - the defence statement is oversimplifying and belongs to the requirements section
>
> §3.3, threat cases 2 and 3:
> one can distinguish between two other cases:
> (a) insider attacks, i.e. active attacks from adverseries in the know of certain keys
>      -> protection against this attack requires source authentication (e.g. digitial signatures)
> (b) outsider attacks, i.e. active attacks from outside of a VPN
>      -> in this case simple MACs are sufficient (i.e. group authentication)
>
> §4: all the references to section 2 should be 3
>
> §4, security requirements list:
> - instead of "ULE source authentication is required..." should more generally say "integrity protection and authentication is required..."
> - missing L2 ULE sender and receiver authentication (entitiy authentication)
>
> $4, other general requirements list:
> - might mention requirement for policy management
> - integrity of control messages (SI tables): as said before, what we want is authentication
>
> §4, security requirements case 2:
> - MACs do NOT provide source authentication for cases 2 and 3 (subcase (a))
> - if mentioning TESLA should first speak of digital signatures (btw, TESLA introduces further latencies at the receiver side and still requires digital signatures (for signing the head of the hash chains))
>
> §5, first paragraph, last sentence:
> ...impact on bandwidth?
>
> §5, last list item:
> I don't see how the issue of address preservation is of relevance to the ULE scenario. AFAIK address preservation is important for correct routing within multicast trees, but since in ULE networks data is simply sent from one L2 point to the next I don't understand the problem.
>
> §6.1, disadvantages:
> third item should probably mean "Encryption of the MAC/NPA address is not permitted in MPE systems."
>
> §6.2:
> - references to section 2 should be 3
> - information in first paragraph is redundant, i.e. already in the requirements section (section 4)
>
> §7, second paragraph:
> It should better read "There is an optional requirement for L2 authentication and integrity assurance as well as protection against insertion of other data into the ULE stream (i.e. replay attacks)."
>
> Gorry Fairhurst wrote:
> >
> > 2) Can  we determine precisely what we man by a "Stream". Does a
> > Stream always only have ONE originating source? That is, does the PID
> > imply a specific intended source?
>
> It is my understanding that there can only be at most one designated sender per PID, basically due to multiple synchronization problems otherwise. However, this does not preclude the possibility of a sophisticated active adversery injecting data on the same PID.
>
> Regards,
> Michael Noisternig
>
>