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

Michael Noisternig <> Fri, 17 July 2009 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 117023A6B7C for <>; Fri, 17 Jul 2009 09:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.084
X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_AT=0.745, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lmTFV5dk33Mj for <>; Fri, 17 Jul 2009 09:29:13 -0700 (PDT)
Received: from ( [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by (Postfix) with ESMTP id 445803A6B4A for <>; Fri, 17 Jul 2009 09:28:50 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (8.13.4/8.13.4) with ESMTP id n6HFvprx024258 for <>; Fri, 17 Jul 2009 16:57:51 +0100 (BST)
Received: (from majordomo.lists@localhost) by (8.13.4/8.12.2/Submit) id n6HFvpqW024257 for ipdvb-subscribed-users; Fri, 17 Jul 2009 16:57:51 +0100 (BST)
X-Authentication-Warning: majordomo.lists set sender to using -f
Received: from ( [IPv6:2001:628:408:102::30:0]) by (8.13.4/8.13.4) with ESMTP id n6HFvepl024237; Fri, 17 Jul 2009 16:57:40 +0100 (BST)
Received: from [] ( []) by (Postfix) with ESMTP id 08B8222869D; Fri, 17 Jul 2009 17:57:39 +0200 (CEST)
Message-ID: <>
Date: Fri, 17 Jul 2009 17:57:26 +0200
From: Michael Noisternig <>
User-Agent: Thunderbird (Windows/20090605)
MIME-Version: 1.0
Subject: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs)
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ERG-MailScanner: Found to be clean, Found to be clean
Precedence: bulk

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

Michael schrieb:
> 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: <>  
> <outbind://1-00000000A3A4994E2BD6A748A3EE49099E5DCB460700C31D320295E23A4EBD131946F0FE1BB000000033C7FF0000C31D320295E23A4EBD131946F0FE1BB0000001AB9C620000/exchweb/bin/redir.asp?URL=>  
> ________________________________
> From: [] 
> Sent: 17 July 2009 08:05
> To:
> 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?  

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.

>  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. 

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.

> 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? 

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.

> 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 
> =========================
> Satellite Networks Manager
> Thales Alenia Space España
> tel. +34 91 807 78 21
> =========================