[cgl_discussion] RE: [cgl_specs] Latest draft on security requirements

Makan Pourzandi (LMC) Makan.Pourzandi at ericsson.ca
Fri Nov 15 16:21:34 PST 2002

Hi Florence, 

Thank you for your comments, see my comments in the text, please, 


> -----Original Message-----
> From: Florence.Hussy at alcatel.fr [mailto:Florence.Hussy at alcatel.fr]
> Sent: Wednesday, November 13, 2002 11:51 AM
> To: Makan Pourzandi (LMC)
> Cc: 'cgl_discussion at osdl.org'; 'cgl_specs at osdl.org';
> Page 5, introduction, item 3:
> Accountability is indeed important but Alcatel is not 
> interrested in "non
> repudiation" which is more for financial applications than telcos.
> Furthermore, this functionality is probably very difficult to 
> achieve /
> implement

Very good point ! 
Actually, I used "Accountability OR Non-repudiation". In first place, I believed that they represent the same thing, but you are right to mention that there is a difference between them. Can you give me a definition for each and perhaps detail more Alcatel argumentation regarding the subject?  

> Page 6, Carrier grade context, minimum performance degradation:
> It may be very difficult for some of the features described 
> in the document
> to achieve the target of 5% / 10%. It should be stated that security
> features having a significant impact on the performance of the system
> should be configurable

Definitely, we have to discuss whether we want to put numbers or not. In my experience, during my discussions with development people when trying to sell them the security, this is a major issue. Whatever you tell them, the final decision depends greatly on the answer to the following question "what is the impact of all this on response time/performance... ?" It seems that the performance degradation is one of the major issues that distinguishes CGL from other kinds of servers. Do we want to go further and give numbers or not? 

> Page 8, current situation:
> Alcatel does not agree that the thread of Trojan horses is 
> not important -
> You can insert a trojan horse by exploiting a fault on the 
> system such as a
> buffer overflow

Removed the Trojan related paragraph ! 

> Page 11, 6.3 IPsec options:
> Alcatel does not require the IPsec options - only IPsec

IP options are used to transport security related info (authentication) through the networks. If there is no more interest for this topic from other participants, I'll move it into long term requirements. 

> Page 12, 6.5 Digital signatures
> Digital signatures are not enough in themselves to guarantee 
> the security -
> Access control is required as well but this feature is 
> probably outside the
> scope of CGL

By access control, do you mean something like MAC? Can you give more details here?  

> Page 18, 7.7 PKI:
> This package should not be implemented as kernel code as it 
> is very large
> and complex and therefore bug prone
> The requirement should state which part of PKI is important - Alcatel
> thinks that only the client part is necessary

I agree with you. 
However, I'm confused, I don't see any mention of the kernel in that section. Do you want to add the fact that PKI must not be supported at kernel level as a requirement? Actually, what about modifying the requirement as the support for fast retrieval of keys/certificates? 

By client part, do you mean support for the client certificates retrieval/storage? 

> Page 19, 7.8 security management:
> Remove the word "automatic" for the security patch insertion 
> - Any patch
> insertion musy be done in a controlled manner under the 
> authority of the
> administrator

Done ! 

>  Page 26, 8.9 security management:
> Simple security policies are potentially very difficult to 
> achieve - A more
> basic requirement could be to have well documented security 
> policies - Any
> "abstraction" can then be done at the administrator's level.
Agree ! 

Added the following: 
" The security policies must be expressed in a simple, comprehensible way. Different situations and the related security rules must be documented. " 

See something else to be added? 


More information about the cgl_discussion mailing list