Subject: RE: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)

From: <[email-masked]>
Date: Fri, 17 Jul 2009 14:16:50 +0100

Many thanks Ana for your comments,
 
See 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: [email-masked] <mailto:[email-masked]>  
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ <outbind://1-00000000A3A4994E2BD6A748A3EE49099E5DCB460700C31D320295E23A4EBD131946F0FE1BB000000033C7FF0000C31D320295E23A4EBD131946F0FE1BB0000001AB9C620000/exchweb/bin/redir.asp?URL=http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/>  

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: 17 July 2009 08:05
To: [email-masked]
Cc: [email-masked]; Cruickshank HS Dr (CCSR); [email-masked]
Subject: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)

Dear authors, 

Nice initiative looking for security over ULE. In fact, link layer security for DVB systems is becoming more and more an issue.  
Haitham: Thanks. 

One question about the security key management, have we thought how to perform it over DVB-RCS systems with different topologies? 
Star systems with a central HUB seems to be an easy scenario, but what about mesh scenarios, who will handle the security keys? 
Is there going to be a pair of share keys per pair of terminals communicating with each other or there will be a different criteria as maybe per 
MAC connection between terminals?  
 
 Haitham: This draft does not address the key management issue. It only focuses on the security extension header format for ULE. The key management can be viewed as an independent issue from the topic of this draft. But it is an important issue. 

   What protocol and what messages will be used for the security key management?  DVB-RCS security systems does cover the star 
topology configuration, but not yet the mesh case. If we believe that in this case we could use GDOI or GSAKMP protocols, 
in our understanding, it will be another exercise to check how these two protocols really solve the problem of security key management in the different  mesh scenarios. 

Haitham: Yes GSAKMP, GDOI or others can be used to solve the key management issues.

Other comments: 

- Section 8. Security considerations 
"Increasing sequence numbers could be linked to a single connection." 
Are we referring to IP connections or link layer connections? 

Haitham: It relates to link layer connection.

- Broadcasting DVB systems use MPEG formatting. But DVB-RCS star transparent systems, mostly use ATM formatting and only optionally MPEG formatting. Using the PID value to identify the source can always be applied to the user terminal in RCS systems. But in a star transparent configuration, the HUB will receive ATM cells,  Does it have any impact? 

Haitham: In this draft we did not address the ATM cell transmissions. I am not sure if there is a demand for using ATM.

Kind regards, 

Ana 

=========================
Ana YUN GARCIA
Satellite Networks Manager
Thales Alenia Space España
tel. +34 91 807 78 21
www.thalesaleniaspace.com
=========================

---

From: Michael Noisternig <[email-masked]>
Date: Fri, 17 Jul 2009 17:57:26 +0200

Thanks again, Ana, for your review. Please see my replies inline. I hope 
I understood your questions correctly.

Michael

> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ <outbind://1-00000000A3A4994E2BD6A748A3EE49099E5DCB460700C31D320295E23A4EBD131946F0FE1BB000000033C7FF0000C31D320295E23A4EBD131946F0FE1BB0000001AB9…

Meshed networks require DVB-RCS to carry MPEG/ULE, otherwise ULE 
security won't be possible. Then, the link endpoints (terminals) 
maintain the security keys. These may be set up using manual keying in 
the form of pre-shared keys, either per link (pair of terminals) each or 
one key for all terminals.

Keys may be set up automatically using some key management protocol. 
Then, for traditional bi-directional unicast communication, it's the 
link end-points that negotiate and hold the security keys. Key 
management for secure groups requires a designated Group Controller and 
Key Server (GCKS) that is reponsible for maintaining the secure group 
and issuing the keys. This is partly addressed in the processing 
section. However, a key management protocol is intended to be specified 
separately, in order to allow a clear separation and flexiblity between 
the key management and the extension header specification.

> in our understanding, it will be another exercise to check how these two protocols really solve the problem of security key management in the different  mesh scenarios. 

Key management is not specified in this document. GDOI and GSAKMP may 
very well be some good candidates to adapt for group key management. 
This is to be defined independently.

> - Broadcasting DVB systems use MPEG formatting. But DVB-RCS star transparent systems, mostly use ATM formatting and only optionally MPEG formatting. Using the PID value to identify the source can a…

We only consider the ULE link in the document. If ATM is used on the 
return channel, then the ULE link is between the hub and a terminal, and 
the hub is the source.