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

"Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com> Tue, 18 March 2014 01:20 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 77CA31A045D for <secdir@ietfa.amsl.com>; Mon, 17 Mar 2014 18:20:31 -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 URKuDCsMvn5O for <secdir@ietfa.amsl.com>; Mon, 17 Mar 2014 18:20:27 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D70B1A0473 for <secdir@ietf.org>; Mon, 17 Mar 2014 18:20:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCE04190; Tue, 18 Mar 2014 01:20:17 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 01:19:59 +0000
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 01:20:00 +0000
Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.209]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 18 Mar 2014 09:19:56 +0800
From: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>
To: "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: secdir review of draft-vanelburg-dispatch-private-network-ind-05
Thread-Index: Ac8/cKSE3IBqqIfsSWK0qV6GmzJeoQC1326Q
Date: Tue, 18 Mar 2014 01:19:56 +0000
Message-ID: <C72CBD9FE3CA604887B1B3F1D145D05E7BC3DFEB@nkgeml507-mbs.china.huawei.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_C72CBD9FE3CA604887B1B3F1D145D05E7BC3DFEBnkgeml507mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LNMtn6Z0zVPh2l9-3Bb9k_gUJhs
Subject: [secdir] FW: 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: Tue, 18 Mar 2014 01:20:31 -0000


From: Zhangdacheng (Dacheng)
Sent: Friday, March 14, 2014 6:32 PM
To: secdir@ietf.org
Cc: iesg@ietf.org; '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."

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