[Pana] Switching to direct communication [was Re: PANA relay draft]

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Thu, 25 November 2010 23:27 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: pana@core3.amsl.com
Delivered-To: pana@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7B03A6A91 for <pana@core3.amsl.com>; Thu, 25 Nov 2010 15:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level:
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 EQPHJnFI5vC9 for <pana@core3.amsl.com>; Thu, 25 Nov 2010 15:27:42 -0800 (PST)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 37EC73A6997 for <pana@ietf.org>; Thu, 25 Nov 2010 15:27:41 -0800 (PST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id oAPNRifN007757; Fri, 26 Nov 2010 08:27:44 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id oAPNRhbF012400; Fri, 26 Nov 2010 08:27:43 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA12399; Fri, 26 Nov 2010 08:27:43 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id oAPNRh9A024145; Fri, 26 Nov 2010 08:27:43 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id oAPNRfiG012133; Fri, 26 Nov 2010 08:27:43 +0900 (JST)
Received: from [133.196.17.62] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LCG00LM0RU5GE50@mail.po.toshiba.co.jp>; Fri, 26 Nov 2010 08:27:41 +0900 (JST)
Date: Fri, 26 Nov 2010 08:27:38 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <00d601cb8bd3$c1909730$44b1c590$%yegin@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
Message-id: <4CEEF0EA.3000707@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit
References: <317A507F-239C-4AAD-B88F-2D5744E7D5F2@gmail.com> <F75BDF80-67C2-4008-8DC1-6EA8E1C00088@um.es> <4CE6E4B1.1080007@toshiba.co.jp> <934C8E59-C49E-4D96-A311-FB48B3DACD78@um.es> <00d601cb8bd3$c1909730$44b1c590$%yegin@yegin.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
Cc: pana@ietf.org, robert.cragie@gridmerge.com, 'Samita Chakrabarti' <samitac@ipinfusion.com>, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: [Pana] Switching to direct communication [was Re: PANA relay draft]
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Nov 2010 23:27:45 -0000

Let me create a new thread on this specific topic.

It has been identified that switching from relay to direct
communication requires not only change of PaC's address but also
change of PAA's address.

But RFC 5191 supports change of PaC's address for a given PANA session
but does not support change of PAA's address.

So it seems that switching to direct communication requires to go
through a full PANA authentication.

So if we mention "direct IP routing MAY be available" then we may also
need to mention that "switching to direct communication requires a
full PANA authentication using the new PaC's and PAA's addresses."

What do you think?

Yoshihiro Ohba


(2010/11/24 21:32), Alper Yegin wrote:
>>
>> [Rafa] In my opinion, after the successful PAA authentication, I
>> believe that it would be better that PaC does not require the PRE
>> anymore. In other words, the PaC and the PAA know each other. Moreover
>> I assume that after the successful PAA authentication the PaC will be
>> able to contact directly the PAA without the assistance of the PRE. If
>> these assumptions are reasonable, there will not be PAA-initated
>> messages that go through the PRE.
> 
> I think this spec shall not mandate or prohibit use of PRE after the first
> successful PANA auth. Spec shall allow both, and the consumers (deployments,
> architectures) shall decide.
> 
>>>>   If direct IP routing becomes available (e.g., after the successful
>>>>   PANA authentication as in the case of Zigbee IP),
>>>>
>>>> [Rafa]. Is the PRE informed by the PAA?. If it is, how?. In other
>>>> words, how is this enabled after a successful PANA authentication?
>>>
>>> The PRE is not informed by the PAA when direct IP routing becomes
>> available.
>>
>> [Rafa] I mean that it is mentioned that direct IP routing is available
>> , how is this enabled after a successful PANA authentication? is the
>> PaC enabled to use a non link-local IPv6 address?.
> 
> I think the spec shall say "direct IP routing MAY be available". In the
> specific case of zigbee, PaC receives RA and configures a global IPv6
> address. Such details belong to zigbee spec.
> 
>>>> On the other hand, what entity is acting as EP?.
>>>>
>>>
>>> An EP may reside in the PRE, or it could be a separate entity from
>> the PRE.
>>>
>>>> the PaC may choose
>>>>   to directly communicate with the PAA without use of the relay
>>>>   operation.
>>>>
>>>> [Rafa] However, it has been said that PaC that "From the PaC's
>>>> perspective, the PRE appears as the PAA."
>>>> This sentences seems to mean that PaC knows that it is talking with
>>>> a relay first.
>>>
>>> The PaC may not know that it is talking with a relay first.  OTOH,
>>> the PaC may know, after successful PANA authentication, that it was
>> talking with a relay, by using some out-of-band mechanism.  But this
>> does not mean that switching to direct communication is needed.  The
>> point here is that we try to describe possible cases as much as
>> possible.
>>
>>>
>>>> The IP address update procedure defined in [RFC5191] may
>>>> be performed to switch to non-relay operation.
>>>>
>>>> [Rafa] Who is sending this notification?
>>>
>>> The notification is generated locally by the node that has updated an
>> IP address.
>>
>> [Rafa] What is that node? the PAA? the PaC? both?. I mean to switch to
>> non-relay operation, under PaC point of view the PAA is switching the
>> IP address (PaC thought the PAA was the PRE but now it is the real PAA)
> 
> That's right. Both PaC's and PAA's IP address are changing for the given
> PANA session.
>