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

"Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com> Wed, 19 March 2014 06:12 UTC

Return-Path: <zhangdacheng@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C339B1A0545 for <secdir@ietfa.amsl.com>; Tue, 18 Mar 2014 23:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level:
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6Pyx3kjjYOX for <secdir@ietfa.amsl.com>; Tue, 18 Mar 2014 23:11:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DBDF51A0505 for <secdir@ietf.org>; Tue, 18 Mar 2014 23:11:47 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCF19597; Wed, 19 Mar 2014 06:11:38 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 06:11:25 +0000
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 06:11:36 +0000
Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.209]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 19 Mar 2014 14:11:29 +0800
From: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>
To: Shida Schubert <shida@ntt-at.com>
Thread-Topic: secdir review of draft-vanelburg-dispatch-private-network-ind-05
Thread-Index: Ac8/cKSE3IBqqIfsSWK0qV6GmzJeoQDCTf/wAB7RpQAAERnJwA==
Date: Wed, 19 Mar 2014 06:11:28 +0000
Message-ID: <C72CBD9FE3CA604887B1B3F1D145D05E7BC3EC91@nkgeml507-mbs.china.huawei.com>
References: <C72CBD9FE3CA604887B1B3F1D145D05E7BC3E42D@nkgeml507-mbs.china.huawei.com> <398D4FFF-FB13-4686-B7CB-F621912BF5BB@ntt-at.com>
In-Reply-To: <398D4FFF-FB13-4686-B7CB-F621912BF5BB@ntt-at.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.139]
Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3EC91nkgeml507mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wrrPcVipqp5XwEf9mVXXZOhwhK0
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org" <draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org>
Subject: Re: [secdir] secdir review of draft-vanelburg-dispatch-private-network-ind-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 06:12:07 -0000

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:shida@ntt-at.com]
Sent: Wednesday, March 19, 2014 1:58 PM
To: Zhangdacheng (Dacheng)
Cc: draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org
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: secdir@ietf.org<mailto:secdir@ietf.org>
Cc: iesg@ietf.org<mailto:iesg@ietf.org>; 'draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org<mailto:draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org>'
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