RE: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt

[<Rod.Walsh@nokia.com>]

Please see in-line...

> -----Original Message-----
> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On
> Behalf Of ext George Gross
> Sent: Friday, October 29, 2004 3:14 PM
> To: ipdvb@erg.abdn.ac.uk
> Subject: RE: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
> 
> 
> Hi Rod,
> 
> On Fri, 29 Oct 2004 Rod.Walsh@nokia.com wrote:
> 
> > George's observations are valid, but I an sure that 
> mandiating a link
> > level security will significantly reduce the deployability of this
> > architecture. In the short and medium term there is no hope of
> > convergence to a single "MPEG2-TS link layer security" method.
> 
> So what I think I hear you saying here is that the IPDVB is 
> not one link
> layer really, but "N" different vendor-specific link layers, each with
> their own link layer security service. is this a fair assessment?

It's one model but I don't feel it's comprehensive enough.

The MPEG2-TS layer in question does not come with security, but in DVB, ATSC etc. various security solutions have come in. Most of these are describe as CA and most are "security by obscurity". With or without CA, IPsec and higher layer protection is feasible.

Just within the DVB world there are a couple of security solutions (symulcrypt and somethingelse-crypt - me not being an MPEG2 security expert who'd remember the name)

> It seems to me, IPDVB without security is a non-starter. Yet the above
> would lead me to conclude that there is a tacit assumption that IPDVB
> implementations are vendor-specific.

IPDVB can assume that some networks are totally insecure and some are totally secure. The grey world inbetween has not been considered. (Note, "totally secure" is the simple way of saying secure enough not to worry source and destination about additional security).

> When I contrast this aspect of IPDVB with the IEEE 802.11 and 
> IEEE 802.16
> wireless standards, the lack of a common security service 
> looks to be a
> barrier to its acceptance, economies of scale, and a widespread
> interoperability between different IPDVB vendor's equipment.

Very true. WLAN security is much more designed for wide ranging adoption.

Among other things, currently DVB is working on technologies to enable IP Datacast over DVB-H. Among this are security technologies including both "open" and "closed" proposals - time will tell what is the final solution, but I do hope a common open security service will come about to enable the acceptance, economies of scale, and a widespread interoperability required for the mobile internet world. In anycase, this will be security at IP layer and above. So the DVB working assuption is that IP over DVB will be protected above link layer. This may be a reasonable assumption for IETF-IPDVB to adopt.

> > So I think George is right when he asks for a "definition 
> of what that
> > security service is, and how it would be integrated with 
> the IP layer
> > related services, such as DVB address resolution" - the document is
> > well on the way to this. However, the architecture needs to 
> be modular
> > enough to enable the current mix of solutions to be used and make
> > space for future ones.
> 
> Agreed. For starters, I would like to see a list of 
> references enumerating
> the relevant security services, assuming they are in the public domain
> >
> > IMHO, some requirements and guidelines on the link layer 
> security would be sufficient.
> 
> That would be a good first step, although I am not confident that such
> guidelines will be enough to avoid a future security exposure 
> along the
> lines that I sketched. Or other scenarios yet to be discussed 
> that lurk in
> the IPDVB link layer. Unfortunately, since this is an informational
> document, its statements are not normative. A vendor could claim IPDVB
> compliance even if its products are not secure.

(I mean "sufficient for the framework I-D")

> 
> Given what we saw with the 802.11b security debacle, it would be
> worthwhile to have a strong industry-wide IPDVB security 
> standard. If one
> of the IPDVB vendors doesn't "get it right" like as happened 
> with 802.11b,
> then all IPDVB deployments get a publicity blackeye even if their own
> respective security service is adequate.

Though I agree, we need to debate whether this is the right forum and right time in this forum.

> 
> What I think this all points to is the need for a standards 
> track IPDVB
> security protocol document that straddles the vendor-specific DVB link
> layers. I don't know IPDVB history in other SDO, so this may 
> have already
> been tried and stalled in those venues. Could someone who knows that
> history please offer some perspective?
> 
> In the IETF MSEC venue, we do have IP-layer candidate 
> solutions that could
> be extended and applied to IPDVB's problem. Would this working group
> consider such an approach?

Unsuprisingly IPsec (with MSEC's contribution to ESP) and MIKEY are among the proposals in DVB and 3GPP for mobile mass media IP multicast security.

(Beware, I am not good at opening cans of worms and I do not have all the references to documents as I am not active in security - I can forward requests but with low QoS)


Cheers, Rod.

> 
> br,
> 	George
> 
> <snip the rest to save bandwidth>
> 
>