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

Sebastien Decugis <sdecugis@nict.go.jp> Fri, 02 April 2010 04:10 UTC

Return-Path: <sdecugis@nict.go.jp>
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 E19D63A69E4 for <hokey@core3.amsl.com>; Thu, 1 Apr 2010 21:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.329
X-Spam-Level: ***
X-Spam-Status: No, score=3.329 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FRT_SOMA2=2.199, HELO_EQ_JP=1.244]
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 RAHwZqwGngQ5 for <hokey@core3.amsl.com>; Thu, 1 Apr 2010 21:10:04 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 918AA3A6916 for <hokey@ietf.org>; Thu, 1 Apr 2010 21:10:03 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o324AMoN008275; Fri, 2 Apr 2010 13:10:22 +0900 (JST)
Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o324AMhA004033; Fri, 2 Apr 2010 13:10:22 +0900 (JST)
Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o324AMoL004030; Fri, 2 Apr 2010 13:10:22 +0900 (JST)
Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 81F70164B9; Fri, 2 Apr 2010 13:10:22 +0900 (JST)
Received: from [133.243.146.171] (5gou2f-dhcp11.nict.go.jp [133.243.146.171]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 7A98C164B1; Fri, 2 Apr 2010 13:10:22 +0900 (JST)
Message-ID: <4BB56E28.8090707@nict.go.jp>
Date: Fri, 02 Apr 2010 13:10:16 +0900
From: Sebastien Decugis <sdecugis@nict.go.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Qin Wu <sunseawq@huawei.com>
References: <008501cacd54$504b4ea0$f0e1ebe0$@net> <4BB55FEF.5070609@nict.go.jp> <024601cad219$7560bd50$23548a0a@china.huawei.com>
In-Reply-To: <024601cad219$7560bd50$23548a0a@china.huawei.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=33D9F61D
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: hokey@ietf.org
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:10:07 -0000

Hi Qin,

Thank you for the clarification. Anyway, I am still confused. Are you
assuming that the new authenticator always belong to the same domain as
the previous authenticator in the case of handover?

Best regards,
Sebastien.

Le 02/04/2010 13:03, Qin Wu a écrit :
> 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)