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

From: <[email-masked]>
Date: Mon, 1 Nov 2004 08:59:25 +0200

Please see in-line...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext George Gross
> Sent: Friday, October 29, 2004 3:14 PM
> To: [email-masked]
> Subject: RE: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
> 
> 
> Hi Rod,
> 
> On Fri, 29 Oct 2004 [email-masked] 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>
> 
>

---

From: <[email-masked]>
Date: Mon, 1 Nov 2004 08:59:26 +0200

Thanks for the clarification - sorry abour being too lazy to read the charter (or too busy to think of it :)

BTW, although George is making good points (which I mostly agree with) these can not be solved in the framework without some length of work and strong DVB liaison even at this stage (as the related DVB work is in progress) so it could be best to move towards modifing the I-D to accomodate furture security work. (George ocrrect me if I'm wrong but I have the impression that "a subsequent plug-in IPDVB security framework" would be more along the lines of your thoughts, given that a framework would be describing the current solutions and the need to fill gaps and improve interoperability).

(So far this has not been part of the WG charter so the framework security considerations do already seem to be a good effort in my eyes. On one hand I'd like to encourage the WG to look into these security aspects more. On the other, it may be better to keep focused and wait for the DVB IP security solution dust to settle.)

Cheers, Rod.

> Behalf Of ext Gorry Fairhurst
> Sent: Friday, October 29, 2004 8:09 PM
> To: [email-masked]
> Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
> 
> 
> 
> 
> Thanks Rod!
> 
> I will respond more to the detail at a later date, but to answer the 
> following quickly:
> 
> <snip>
> 
> > Also, what is the "statement of intent"? (i.e. I assume the 
> intention 
> > is to give this to the IESG to become an Informational RFC, but the 
> > WGLC doesn't say. Experimental could be an option if there is any 
>  > intent to turn this into a normative specification once other IPDVB
> > I-Ds progress - though I have not got the impression that this has 
>  > been asked for).
> > 
> > Cheers, Rod.
> > 
> 
> It is not the intention to change THIS document into a 
> protocol spec - 
> although the WG is now invited/expected to work on the other Charter 
> items which relate to implementing elements of the architecture.
> 
> The document was written in reponse to the following charter item:
> 
> "Specify the requirements and architecture for supporting 
> IPv4/IPv6 via
> MPEG-2 transmission networks. Such requirements should consider the
> range of platforms currently (or anticipated to be) in use. This draft
> will be an Informational RFC."
> 
> When completed it will therefore be put to the IESG for proposed 
> publication as an INFORMATIONAL document, although the final 
> classification is of course determined by the IESG, not the WG.
> 
> 
> 
> Best wishes,
> 
> Gorry Fairhurst
> (ipdvb WG Chair)
> 
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 02 Nov 2004 11:16:42 +0000

On clarification of the AR work scope:

[email-masked] wrote:

<snip>

> * I get the impression that it is an intentional limitation of the AR that it 
 > applies only to the current TS (as you would expect cf ARP). This is 
a sensible
 > limitation but it's worth stating explicitly.
 > (i.e. that address resolution for other TSes, e.g. for moving TS and 
mobility
 >  optimisation, is not in scope).

<snip>

> Cheers, Rod.

My understanding was that the scope of any new work will be to resolve 
*within* a transport multiplex (i.e. a single physical bearer). The 
proposals to date do not allow the possibility of a TS logical channel 
(i.e. PID value) to be changed during (re)multiplexing - there are 
scenarios in which this can happen - and there are specific solutions 
already in this space (guidance on how to use these is within scope).

Providing AR services that span multiple physical bearers is 
significantly more complex and typically requires processing of SI table 
information - solutions also already exist in this space e.g. proposed 
by ATSC and DVB (guidance on how to use these is within scope).

I'd encourage an approach which is simple.

Rod is that any help? Do other people have thoughts?

Gorry