Last Call Review of draft-vanelburg-dispatch-private-network-ind-05
review-vanelburg-dispatch-private-network-ind-05-secdir-lc-zhang-2014-03-20-00

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



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



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?



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.



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



Cheers



Dacheng