RE: DVB GBS & IETF IPDVB Liaison

[<H.Cruickshank@surrey.ac.uk>]

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 
Lecturer 
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@surrey.ac.uk 
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 

-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] 
Sent: 04 September 2007 15:34
To: ipdvb@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
GBS Chair.

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.

Best wishes,

Gorry Fairhurst
(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.

- draft-ietf-ipdvb-ule-ext-04.txt
   "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.

- draft-ietf-ipdvb-sec-req-03.txt
   "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 ...


- draft-cruickshank-ipdvb-sec-03.txt
   "Security Extension for Unidirectional Lightweight Encapsulation
   Protocol"

     "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
deem appropriate.

Thanks a lot and cheers,

   --alexander