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

[<Rod.Walsh@nokia.com>]

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: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On
> Behalf Of ext George Gross
> Sent: Wednesday, October 27, 2004 10:14 PM
> To: ipdvb@erg.abdn.ac.uk
> 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)
> >
> >
> 
>