Re: [secdir] secdir review of draft-vanelburg-dispatch-private-network-ind-05

[Shida Schubert <[e-mail]>]

Dear Decheng;

 I am glad the description is acceptable.. I will make the change and submit the 
doc over the next few days. 

 Thanks again for reviewing and providing constructive/valuable feedback! 
 
 Shida


On Mar 18, 2014, at 11:11 PM, Zhangdacheng (Dacheng) <[e-mail]> wrote:

> Hi, very happy that you like the comments. About comment D.  Your description about the sensitive information is good. So, could you please in to the document when updating it? ^_^
>  
> Cheers
>  
> Dacheng
>  
> From: Shida Schubert [mailto:[e-mail]] 
> Sent: Wednesday, March 19, 2014 1:58 PM
> To: Zhangdacheng (Dacheng)
> Cc: [e-mail]
> Subject: Re: secdir review of draft-vanelburg-dispatch-private-network-ind-05
>  
>  
> Dear Dacheng; 
>  
>  
>  
> From: Zhangdacheng (Dacheng) 
> Sent: Friday, March 14, 2014 6:32 PM
> To: [e-mail]
> Cc: [e-mail]; '[e-mail]'
> Subject: secdir review of draft-vanelburg-dispatch-private-network-ind-05
>  
>  
> I have reviewed this document as part of the security directorate's ongoing effort to for early review of WG drafts.  These comments were written primarily for the benefit of the security area directors.  Document editors and working group chairs should treat these comments just like any other comments.
>  
> This document specifies a SIP P-Private-Network-Indication P-header which is able to contain a domain name to identify the organization that certain private network traffics belong to and enable network nodes to process different traffics with different sets of rules.
>  
> There are some comments in the security considerations.
>  
> A: “The private network indication defined in this document MUST only be used in an environment where elements are trusted and where attackers do not have access to the protocol messages between those elements.”
>   
> This sentence is not very accurate. In the examples discussed in the document, the private traffics could be transported over public networks, where they can be“accessed” by attackers. In addition, there is no definition of “trust” or “trusted notes”. I guess you are using the terms specified in RFC3324. If so, please mention it in section 3. When using the terms in RFC3324, I think this sentence could be changed to ”The private network indication defined in this document MUST only be used in an environment where elements are trusted and there are secure connections between those elements.” Or even simpler, “The private network indication defined in this document MUST only be used in the traffics transported between the elements which are mutually trusted.”
>  
> Many thanks for suggestion, I will reflect the changes when updating the draft. 
> 
> 
>  
> B: “Traffic protection between network elements can be achieved by using IPsec and sometimes by physical protection of the network.” 
>  
> Because we intend to provide confidentiality protection for the contents of this header field, IPsec AH may not be suitable here. So, maybe we can change this sentence to “Traffic protection between network elements can be achieved by using the security protocols such as IPsec ESP [RFC2406] or sometimes by physical protection of the network.”
>  
> Again, sounds great. Thanks for the suggestion. 
> 
> 
>  
> C: “A private network indication received from an untrusted node MUST NOT be used and the information MUST be removed from a request or response before it is forwarded to entities in the trust domain.”
>  
> There is a concern about this sentence. If a device receives a message with a invalid indication, should the device forwards it or just discards it?
>  
> As you sated the concern is valid, why should you receive the header from an untrusted node. It is very likely an attempt to compromise the public or private network.
>  
> We could change it to:
> “A private network indication received from an untrusted node MUST NOT be used and the information MUST be removed from a request or response before it is forwarded to entities in the trust domain. Additionally local policies may be in place that ensure that all requests entering the trust domain for private network indication from untrusted nodes with a private network indication will be discarded.”
> 
> 
>  
> D:  “There is a security risk if a private network indication is allowed to propagate out of the trust domain where it was generated. In that case sensitive information would be revealed by such a breach.”
>  
> It would be good to clarify what kind information is sensitive and what kind of risk will be caused by disclosing such information. The domain name of an organization is public, right? I know the leak of the domain name is undesired. But I suggest making some discussions here.
>  
>  
> The indication may reveal information about the identity of the caller, i,e, the organisation that he belongs to. That is sensitive information. It also reveals to the outside world that there is a set of rules that this call is subject to that is different then the rules that apply to public traffic. That is sensitive information too.
>  
> 
> 
> E: “There is no automatic mechanism to learn the support for this specification.”
>  
> Maybe we can change this sentence to “However, how to learn such knowledge is out of scope.”
>  
>  Great! we will :-)
>  
>  Many Thanks! 
>  
>  Shida
> 
> 
>  
> Cheers
>  
> Dacheng