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

From: <[email-masked]>
Date: Fri, 29 Oct 2004 13:23:06 +0300

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

IMHO, some requirements and guidelines on the link layer security would be sufficient.

BTW, I'm sorry I've been too busy to do a detailed review of draft-ietf-ipdvb-arch-01.txt review, but here are a few comments that should help at high level scan review:

* The document looks good and the flow and level of detail looks right
* The table of contents needs page numbers
* the "Change Notice:" should be described in a annex including a note to the RFC Editor that they are not to be included in the RFC
* "D-TV" of figure 1 should be "terrestrial" to be in line with "satelite" and "cable" (all 3 can deliver D-TV and more).
* "Data-cast" is correctly spelt "Datacast" and is more commonly known as "IP Datacast" in this context (other-than-IP packetisation over broacast also gets labelled datacast from time to time)
* 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 optomisation, is not in scope).
(You can see that level at which I read :)

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.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext George Gross
> Sent: Wednesday, October 27, 2004 10:14 PM
> To: [email-masked]
> Subject: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
> 
> 
> Hi,
> 
> 	I was reviewing the above draft's security 
> considerations section
> 8, and thinking about possible threat models.
> 
> 	Suppose a rogue DVB-RCS subscriber cracked the 
> terminal's software
> and took control of its behavior. From what I could discern, in the
> absence of point to point link layer encryption that adversary could
> eavesdrop on any peer subscriber's IP communications, correct? Let's
> assume the hapless peer subscriber is Joe Consumer, for whom 
> IPsec and TLS
> are random letters in the alphabet. This scenario could be a security
> exposure similar to what early 802.11b had, which garnered lots of
> negative press and rev'ing to fix that standard.
> 
> 	As currently written, the section 8.1 leaves it up to the Access
> Network Operator to optionally set up a link layer security 
> service. Yet
> there is insufficient definition of what that security 
> service is, and how
> it would be integrated with the IP layer related services, such as DVB
> address resolution. It seems odd to imply that the IPDVB architecture
> would depend on those link layer security services, yet not 
> even name them
> by reference and mandate one.
> 
> 	I would have thought the IPDVB architecture would 
> require at least
> _one_ of those possible choices _must_ be implemented as part 
> of the IETF
> standard. Otherwise, no two IPDVB implementations could inter-operate
> unless they happened to understand the same Access Network 
> Operator's link
> layer security service.
> 
> 	I seem to recall that there was an e-mail thread on 
> this list wrt/
> security last spring, but its conclusion didn't seem to 
> account for the
> above security risks and inter-operability issue...
> 
> hth,
> 	George
> 
> 
> On Fri, 15 Oct 2004, Gorry Fairhurst wrote:
> 
> >
> > This note starts the ipdvb WG Last Call for comments for 
> the WG document
> > named below:
> >
> > draft-ietf-ipdvb-arch-01.txt
> >
> > The last call will end on 29/10/2002.
> >
> > Members of the IETF are asked to read the draft and send any issues,
> > comments, or corrections to this mailing list. The WGLC 
> procedure is the
> > last chance for this working group to modify/correct this z.
> >
> > Please do forward any comments to the list.
> >
> > Best wishes,
> >
> > Gorry Fairhurst
> > (ipdvb WG Chair)
> >
> >
> 
>

---

From: George Gross <[email-masked]>
Date: Fri, 29 Oct 2004 08:13:35 -0400 (EDT)

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

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.

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

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.

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?

br,
	George

<snip the rest to save bandwidth>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 29 Oct 2004 18:09:10 +0100

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)