[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Following on from what Prashat has been saying, the current text says:

"      - Optional hiding of Layer 2 MAC/NPA address.  This is needed
        particularly in the MPEG-2 broadcast networks to stop an
        intruder gaining information by observing the identity of the
        communicating parties and the volume of their traffic.
             - Layer L2 terminal authentication. This will be part of
        the key management. It will be performed during the initial
        key exchange and authentication phase. "

Some more thoughts:
* It probably is woirth being clear that by "optional" you mean that this is only needed in networks that require this additional service, and that you do not expect all networks to need to provide identity hiding.
* Is it possible to cite some references to similar services over other technologies? 

* Some text to say why IPsec cannot provide this service would be good.
* Finally, is the second part meant to be second point? - Thsi notion of authentication at L2 seems different to that at L3 (are the goals different?). Is authentication of Receivers optional in the architecture or required? 

Gorry

H.Cruickshank@surrey.ac.uk wrote:


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