Re: [secdir] secdir review of draft-ietf-conex-mobile-05

"Xialiang (Frank)" <> Fri, 11 September 2015 09:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 851701A0242; Fri, 11 Sep 2015 02:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.76
X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p6w_tVEBltGK; Fri, 11 Sep 2015 02:20:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4B071A0035; Fri, 11 Sep 2015 02:20:28 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CBD60438; Fri, 11 Sep 2015 09:20:26 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 11 Sep 2015 10:20:24 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Fri, 11 Sep 2015 17:20:18 +0800
From: "Xialiang (Frank)" <>
To: Dirk Kutscher <>
Thread-Topic: secdir review of draft-ietf-conex-mobile-05
Thread-Index: AdDsK7I1VyJu7Bl6QJ2ZXX3RKt6srwAQblSwAAEGHKA=
Date: Fri, 11 Sep 2015 09:20:17 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AE6349DSZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Cc: "" <>, "" <>, secdir <>
Subject: Re: [secdir] secdir review of draft-ietf-conex-mobile-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Sep 2015 09:20:36 -0000

Hi Dirk,
Thank you for quick response.
I reviewed the drafts you mentioned below. I agree that they already discussed the general security issues I am concerned, especially in the draft-conex-abstract-mech-13 and its reference.

So, in general, my concerns are addressed. But I still have a little bit doubts about possibly new security issues for the use cases of using ConEx protocol over the mobile communication networks. I am not an expert in this area, can you clarify me?



发件人: Dirk Kutscher []
发送时间: 2015年9月11日 16:52
收件人: Xialiang (Frank); secdir;;
主题: RE: secdir review of draft-ietf-conex-mobile-05

Hi Frank,

thanks for the review.

The security issues you mentioned would apply to ConEx in general. The corresponding documents are discussing potential security issues: (also see the references)

We’d therefore rather not duplicate that discussion in conex-mobile.

Regarding the security risks you mentioned, I’d say it is questionable whether ConEx introduces additional issues for confidentiality (compared to IP alone).


From: Xialiang (Frank) []
Sent: Freitag, 11. September 2015 02:49
To: secdir;<>;<>
Subject: secdir review of draft-ietf-conex-mobile-05

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comment.

This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS).

I have the following comments:

l  1. It should be helpful to consider the communication security between the ConEx senders and receivers such as the Confidentiality, data integrity and peer entity authentication in the security considerations part. Because in general, the corresponding risks are still possible to exist.

l  2. The authentication mechanism among all the elements of ConEx solution should also be considered to handle the condition of faked messages or invalid peer elements.

Recommendation:  Ready With Issues