IETF Logo Mail Archive

[pcp] 答复: About selecting a key management for PCP

"Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com> Thu, 02 August 2012 14:58 UTC

Return-Path: <zhangdacheng@huawei.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5B11E80C5 for <pcp@ietfa.amsl.com>; Thu, 2 Aug 2012 07:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.374
X-Spam-Level:
X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-3.823, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxKHwUsx9pkk for <pcp@ietfa.amsl.com>; Thu, 2 Aug 2012 07:58:42 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F0F4111E8072 for <pcp@ietf.org>; Thu, 2 Aug 2012 07:58:41 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ11316; Thu, 02 Aug 2012 06:58:41 -0800 (PST)
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 07:56:53 -0700
Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 07:56:58 -0700
Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.120]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 22:56:52 +0800
From: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>
To: Alper Yegin <alper.yegin@yegin.org>
Thread-Topic: [pcp] About selecting a key management for PCP
Thread-Index: AQHNbwnvoZws8buZFUaBTiMDCJuBl5dF8XcAgACsKsI=
Date: Thu, 02 Aug 2012 14:56:51 +0000
Message-ID: <C72CBD9FE3CA604887B1B3F1D145D05E2CE63FF9@szxeml528-mbx.china.huawei.com>
References: <C72CBD9FE3CA604887B1B3F1D145D05E2CE62CD3@szxeml528-mbx.china.huawei.com>, <0096E801-3D17-4751-981A-67A46B96F739@yegin.org>
In-Reply-To: <0096E801-3D17-4751-981A-67A46B96F739@yegin.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.24.1.45]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Margaret Wasserman <mrw@painless-security.com>, "pcp@ietf.org" <pcp@ietf.org>
Subject: [pcp] 答复: About selecting a key management for PCP
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 14:58:42 -0000

________________________________________
发件人: Alper Yegin [alper.yegin@yegin.org]
发送时间: 2012年8月2日 20:32
到: Zhangdacheng (Dacheng)
Cc: pcp@ietf.org; Margaret Wasserman
主题: Re: [pcp] About selecting a key management for PCP

> an in-band authenticaiton mchanism for PCP (actually a simplified PANA).


>It's not simplified…. It's basically growing PANA (an EAPoUDP transport) within PCP. A redundant work that'd >result in more complexity than keeping two simple protocols separate. This "oh I'll just carry EAP over my favorite >protocol (e.g., DHCP!), and it'd be sooo simple" was tried before and failed miserably.  PCP and its key >management are two separate issues that deserve two separate protocols (similar to IKE and IPsec being >separate). I don't see any value in cobbling them up, which is more like a PPP-style approach -- all-in-one.



Maybe my bad English causes confusion. Sorry for that. The "simplified" here means we can remove the redundant functions of PANA and only keep the necessary part. That is exactly what we are trying to do in the pcp authentication draft.

In addition, you remind me one thing. Karp WG is trying to use IKEv2 to provide key management for unicast routing protocols. If our WG decide to select a seperated AKM solution. Do you think it is a good idea to borrow their work to secure PCP?

Cheers

Dacheng

Alper

v2.23.0 | Report a Bug | By Email