Subject: Working Group Last Call (WGLC): draft-ietf-ipdvb-arch-01.txt

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 15 Oct 2004 20:59:58 +0100

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: Wed, 27 Oct 2004 15:14:04 -0400 (EDT)

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

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Thu, 28 Oct 2004 01:01:36 -0400

Is there unanimity the suggestions of this email should be part of ARCH?
Any other suggestion?

Marie-Jose

---

From: "Anurag Sharma" <[email-masked]>
Date: Thu, 28 Oct 2004 16:07:51 +0530

Hi,

I would like to know if the CRC check done for the DSMCC section includes
only the payload or DSM CC header too.

regards,
Anurag

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************