RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt

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

Hi again Prashant,

Yes, you are right. In fact, one of the issues that we need to solve in
the ULE security system, how to hide the identity of the ULE sender and
receivers.  In draft  "draft-cruickshank-ipdvb-sec-01.txt", the proposal
is to use temporary NPA/MAC addresses.

Haitham

----

Dr. Haitham S. Cruickshank

Lecturer 
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK 

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: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk] 
Sent: 22 May 2006 15:12
To: Cruickshank HS Dr (CCSR)
Cc: ipdvb@erg.abdn.ac.uk
Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt


Hi Haitham,

I agree with you that in the tunnel mode the inner packet is encrypted
so protected from traffic analysis. But the outer IP packet would still
have the IP address of the ULE receiver (which acts as the gateway for
the tunnel mode) at the user end. This could still be used for some form
of traffic analysis (especially as for the MPEG2 network the user would
be the ULE receiver and not the IP hosts connected behind it).

Regards
Prashant

Quoting H.Cruickshank@surrey.ac.uk:

> Hi Prashant,
>
> Many thanks for your comments.  See replies in-line:
>
> ----
>
> Dr. Haitham S. Cruickshank
>
> Lecturer
> Communications Centre for Communication Systems Research (CCSR) School

> of Electronics, Computing and Mathematics University of Surrey, 
> Guildford, Surrey GU2 7XH, UK
>
> 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: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk]
> Sent: 22 May 2006 13:07
> To: Cruickshank HS Dr (CCSR)
> Cc: ipdvb@erg.abdn.ac.uk
> Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt
>
>
> Hi Haitham,
>
> I have a few more comments on the draft:
>
> 1. As stated in Section 3 - "Data confidentiality is the major 
> requirement against passive threats (using encryption).  L2 encryption

> or L3 (IPsec) Encryption can satisfy this requirement".  I disagree 
> with this. L3 (IPSEC) Encryption would not be able to prevent passice 
> threats like traffic analysis as the outer IP header is not encrypted.

> The only drive to provide L2 security is to provide encryption of the 
> complete higher layer packets to prevent any traffic analysis.
>
> Haitham: As you know that if IPsec is used in Tunnel mode then it will

> protect the inner IP header from traffic analysis.  Of course, we have

> to live with the overheads of IPsec tunnel mode.
>
> 2. Regarding the optional authentication and integrity. I think we 
> need to be careful with the wording in the draft.
>
> - Is there a requirement for an "optional authenticity/integrity 
> mechanism" (like you said that some service may not need it)? or
> - Is there a definite requirement for authenticity/integrity mechanism

> over the MPEG2 link? This may be optional at the ULE level when other 
> authentication/integrity mechanisms at other layers may be present 
> (like IPSEC AH or ESP with Auth).
>
> I prefer the second option which emphasises on the requirement for 
> authenticity/integrity but keeps it as an optional service at ULE. 
> Could the other members of the group also voice their opinion on this?
>
> 3. Who would be in-charge of selecting the Secure ULE level - the user

> or the NCC? Does the NCC decide on the level of security to be used 
> (according to the user profile, pricing plan, etc) or can the user 
> select the level of security (so the user can select different 
> security levels for different sessions)?
>
> Haitham: The draft states that the ULE link security focuses on 
> security between the Encapsulation Gateways (ULE source) and 
> Receivers.  The level of security such as encryption key length and 
> data integrity methods are part of key management exchange that should

> happen before ULE encryption or data integrity is performed.
>
>
> 4. What about content protection? Do we need to address the 
> support/interoperability with content protection mechanism (like DRM)?
>
> Haitham:  I think this is out of scope for ipdvb group.
>
> 5. What about Interworking with existing lower layer security 
> mechanisms especially the ones specified in DVB RCS (MKE, EKE, QKE)? 
> Do we expect a user to perform DVB RCS security setup (using MKE, EKE,

> QKE), then perform another set of security setup for Secure ULE (using

> GDOI/GSAKMP
> etc) and then a final end-to-end IPSEC setup (using IKE/ISAKMP or even
> GDOI/GSAKMP etc)?
>
> Haitham:  The specific link layer system (DVB-RCS) is just one type of
> MPEG2- transmission networks.  MKE, EKE and QKE are key agreement 
> protocols for DVB-RCS.  The ULE security draft mentions that key 
> management (or key agreement protocols) should be decoupled from the 
> ULE encryption/integrity.  The reason is that the implementers of ULE 
> security will be free to choose a suitable key management.  Of course,

> the MSEC related protocols (GSAKMP/GDOI ...) are the best choices, in 
> my opinion.
>
> Haitham
>
>


-- 
Prashant Pillai
Research Assistant
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
Phone: 0044-1274-233720
email: p.pillai@bradford.ac.uk
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message and full
headers to misuse@bradford.ac.uk
------------------------------------------------------------