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

<> Fri, 17 July 2009 13:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8BB93A6B68 for <>; Fri, 17 Jul 2009 06:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uxT-D0i6c6cb for <>; Fri, 17 Jul 2009 06:49:37 -0700 (PDT)
Received: from ( [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by (Postfix) with ESMTP id 779FE3A6837 for <>; Fri, 17 Jul 2009 06:49:25 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (8.13.4/8.13.4) with ESMTP id n6HDHCPB020068 for <>; Fri, 17 Jul 2009 14:17:12 +0100 (BST)
Received: (from majordomo.lists@localhost) by (8.13.4/8.12.2/Submit) id n6HDHB25020067 for ipdvb-subscribed-users; Fri, 17 Jul 2009 14:17:11 +0100 (BST)
X-Authentication-Warning: majordomo.lists set sender to using -f
Received: from ( []) by (8.13.4/8.13.4) with SMTP id n6HDGxlG020052; Fri, 17 Jul 2009 14:16:59 +0100 (BST)
X-VirusChecked: Checked
X-StarScan-Version: 6.1.2; banners=-,-,-
X-Originating-IP: []
Received: (qmail 18219 invoked from network); 17 Jul 2009 13:16:53 -0000
Received: from (HELO ( by with SMTP; 17 Jul 2009 13:16:53 -0000
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 14:16:52 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)
Date: Fri, 17 Jul 2009 14:16:50 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)
Thread-Index: AcoGrXVvyt4ktFDbRIWzFx77qMoS0AAMPP9A
X-OriginalArrivalTime: 17 Jul 2009 13:16:52.0306 (UTC) FILETIME=[D962EB20:01CA06E0]
X-ERG-MailScanner: Found to be clean, Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id n6HDHBxT020062
Precedence: bulk

Many thanks Ana for your comments,
See 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: <> <outbind://1-00000000A3A4994E2BD6A748A3EE49099E5DCB460700C31D320295E23A4EBD131946F0FE1BB000000033C7FF0000C31D320295E23A4EBD131946F0FE1BB0000001AB9C620000/exchweb/bin/redir.asp?URL=>  


From: [] 
Sent: 17 July 2009 08:05
Cc:; Cruickshank HS Dr (CCSR);
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, 


Satellite Networks Manager
Thales Alenia Space España
tel. +34 91 807 78 21