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

[P.Pillai@Bradford.ac.uk]

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