DVB GBS & IETF IPDVB Liaison
H.Cruickshank at surrey.ac.uk
H.Cruickshank at surrey.ac.uk
Thu Sep 13 11:50:48 BST 2007
Hi Gorry and Alexander,
Many thanks to Alexander for the comments from the DVB-GBS group. See
authors' replies in-line:
Dr. Haitham S. Cruickshank
Communications Centre for Communication Systems Research (CCSR)
BA Building, Room E11
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, UK, GU2 7XH
Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank at surrey.ac.uk
From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
Sent: 04 September 2007 15:34
To: ipdvb at erg.abdn.ac.uk
Cc: Cruickshank HS Dr (CCSR); 'Prashant Pillai'; Iyengar S Mr (CCSR)
Subject: Fwd: DVB GBS & IETF IPDVB Liaison
I am pleased to have received the following comments from DVB via the
These comments concern two ipdvb WG documents that are approaching WGLC
(and a related draft). The comments are provided as inputs to this
working group, and I would encourage people with interest, particularly
in Security, to discuss the issues that are raised to allow the
generation of a final draft-ietf-ipdvb-sec-req-04.txt.
(ipdvb WG Chair)
GBS comments as supplied:
- general comments
The good news is that we have only very few comments and these
are on very specific issues. This means that we came to
conclusions most similar to yours and we're hence probably all
on the right track.
"Extension Formats for Unidirectional Lightweight Encapsulation
(ULE) and the Generic Stream Encapsulation (GSE)"
This appears rather to be an introductory document so we don't
have any security related comments on this one.
"Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol"
This document basically lists the same threat scenarios that we
GBS is considering. So we have nothing to add in this respect.
However we have come to the conclusion that some of these
threats might also require mechanisms at the layer below the IP
encapsulation which we did not see in your document? As GBS is
building on top of a baseband layer which is currently under
development, we of course still have the option of imposing
security requirements on that layer (as opposed to the MPEG-2 TS
which you are building upon)
ANSWER: I am not sure if baseband layer security in GSE means physical
or link layer security. Our solution (ipdvb) is link layer solution
that adopt many features of IPsec. I am aware of some recent research
work on physical layer security, but not related to DVB.
In section 5.2, when talking about the distribution of IP
streams across PIDs, we think that the 1st and 2nd disadvantage
do not apply in the generality in which they appear to be
stated. In the text above the disadvantages, you correctly say
that _typically_ the IP streams share a PID which implies that
they don't necessarily do so. This aspect is dropped and shared
PID is always assumed when talking about the disadvantages.
ANSWER: I propose to change the text in requirements draft to the first
two bullet points in disadvatages in section 5.2:
However it has the following disadvantages:
o When a PID is shared between several users, then each ULE Receiver
needs to decrypt all MPEG-2 TS Packets with a matching PID ....
o When a PID is shared between several users, then ULE Receivers will
have access to private traffic destined to other ULE Receivers ...
"Security Extension for Unidirectional Lightweight Encapsulation
"Receiver NPA address hiding (mandatory)":
draft-ietf-ipdvb-sec-req-03.txt seemed to suggest it were
optional? We would prefer to have it optional.
ANSWER: We agree this should be optional too. The SNDU type that is
visible to all receivers has the value "encrypted
content", whereas the type of PDU being carried is described using a
field within the encrypted payload.
The PDU type does not seem to be encrypted?
We would suggest opening up for optionally using encrypted MAC
addresses instead of temporary ones.
ANSWER: We agree that encrypted MAC option is better than temporary
MAC. We will make the necessary changes to the design draft.
We truly hope to have been helpful with our review and comments. Should
you in turn have any further comments or questions, please don't
hesitate to contact me.
Please feel free to distribute the comments to all ipdvb members as you
Thanks a lot and cheers,
More information about the Ip-dvb