Re: [HOKEY] adoption ofhttps://datatracker.ietf.org/doc/draft-wu-hokey-ldn-discovery/ as a WG document

Qin Wu <sunseawq@huawei.com> Fri, 02 April 2010 04:03 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: hokey@core3.amsl.com
Delivered-To: hokey@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5943A6916 for <hokey@core3.amsl.com>; Thu, 1 Apr 2010 21:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.086
X-Spam-Level: ****
X-Spam-Status: No, score=4.086 tagged_above=-999 required=5 tests=[AWL=-3.101, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, FRT_SOMA2=2.199, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hp1nRnF8pxP for <hokey@core3.amsl.com>; Thu, 1 Apr 2010 21:03:09 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2CD393A6783 for <hokey@ietf.org>; Thu, 1 Apr 2010 21:03:09 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L08006TBDXW1V@szxga04-in.huawei.com> for hokey@ietf.org; Fri, 02 Apr 2010 12:03:32 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L08005G4DXVOV@szxga04-in.huawei.com> for hokey@ietf.org; Fri, 02 Apr 2010 12:03:32 +0800 (CST)
Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0800AYUDXV7X@szxml06-in.huawei.com> for hokey@ietf.org; Fri, 02 Apr 2010 12:03:31 +0800 (CST)
Date: Fri, 02 Apr 2010 12:03:31 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Sebastien Decugis <sdecugis@nict.go.jp>, hokey@ietf.org
Message-id: <024601cad219$7560bd50$23548a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
References: <008501cacd54$504b4ea0$f0e1ebe0$@net> <4BB55FEF.5070609@nict.go.jp>
Subject: Re: [HOKEY] adoption ofhttps://datatracker.ietf.org/doc/draft-wu-hokey-ldn-discovery/ as a WG document
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Apr 2010 04:03:11 -0000

Hi, Sebastinen:
Thank for your feedback. Let me do some clarification in response to your comments.

Regards!
-Qin
----- Original Message ----- 
From: "Sebastien Decugis" <sdecugis@nict.go.jp>
To: <hokey@ietf.org>
Sent: Friday, April 02, 2010 11:09 AM
Subject: Re: [HOKEY] adoption ofhttps://datatracker.ietf.org/doc/draft-wu-hokey-ldn-discovery/ as a WG document


I don't fully understand the purpose of this document.

If my understanding is correct, in many deployment scenario, the DHCP
traffic is allowed only once the peer is authenticated (ex: 802.1X). 

[Qin]: It is true in the non-handover scenario. But it is not in the handover scenario.
Each time inter-authenticator handover or inter-AAA handover happens,  DHCP 
procedure should always been performed again.

To authenticate using ERP protocol, the peer needs to know the local domain
name before the re-authentication starts. Therefore, I really don't
understand how carrying the LDN information in DHCP can help.

Can you please explain it to me?

[Qin]: 
The typical scenario is 
i) peer moves from previous authenticator to the new authenticator
ii) the previous authenticator and the new authenticator share the same Local ER server, i.e., local domain name. 
In this scenario, before the peer move to the new authenticator, the implicit bootstapping
is used by local ER server to fetch DSRK from the home domain, unfortuntely, implicit bootrapping can not 
let the peer know the local domain name. In order to help the peer know the local domain before the re-authentication happens between the peer and the local ER server 
in the local domain, DHCP mechanism can be used to fetch local domain from the DHCP server before the peer leaves the previous authenticator. Becos DHCP procedure happen after implicit bootstrapping, but before the peer move to the new authenticator.

Hope this clarifies. Also you can read the previous version of this draft and presentation slides in the IETF 75 for more details.

Best regards,
Sebastien.

Le 27/03/2010 11:22, Glen Zorn a écrit :
> During yesterday's session, the consensus of the room was to adopt
> https://datatracker.ietf.org/doc/draft-wu-hokey-ldn-discovery/ as a WG
> document; the purpose of this message is to confirm this with the entire WG.
> Please read the document and express an opinion before 2 Apr.  Thanks!
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
>
>   

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www.ietf.org/mailman/listinfo/hokey