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

"Alper Yegin" <alper.yegin@yegin.org> Mon, 29 November 2010 12:09 UTC

Return-Path: <alper.yegin@yegin.org>
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 7BA203A6AB3 for <pana@core3.amsl.com>; Mon, 29 Nov 2010 04:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.081
X-Spam-Level:
X-Spam-Status: No, score=-100.081 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_05=-1.11, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100]
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 sOJENYCiDA5V for <pana@core3.amsl.com>; Mon, 29 Nov 2010 04:09:56 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 3CC683A6AAC for <pana@ietf.org>; Mon, 29 Nov 2010 04:09:56 -0800 (PST)
Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M1FNg-1OYMn83mjw-00tHDr; Mon, 29 Nov 2010 07:10:56 -0500
From: Alper Yegin <alper.yegin@yegin.org>
To: 'Rafa Marin Lopez' <rafa@um.es>
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> <4CEEF0EA.3000707@toshiba.co.jp> <028c01cb8d3a$98967d50$c9c377f0$@yegin@yegin.org> <789D8FFB-6375-4433-AD79-927B0FB7970F@um.es>
In-Reply-To: <789D8FFB-6375-4433-AD79-927B0FB7970F@um.es>
Date: Mon, 29 Nov 2010 14:10:43 +0200
Message-ID: <00b901cb8fbe$79dee4c0$6d9cae40$@yegin>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuNXNRjG37bTRpURsOFO5MPYjoDLgCYSixw
Content-Language: en-us
X-Provags-ID: V02:K0:3I9l+BXoyzJtFBGwgfYENdx4GCme5jh9/sjGDM5sC6h UlnsN+eFgTRHilMlBgAa9fv7imfdXyDmYJ553mYNrFliSRkXzl yaIcnzSAVgirWHsUXorBsGJo/tzy1dUc9kSOKo8J97GRHU/XsB anmu6Glv6+Un8+J2tV+krJ+aMK+EUrBycHyNUY7bZ5JllOBGNW tUh97e6b6G5sdA1fV9R88qAngNGbzibaWvnn8//+RM=
Cc: pana@ietf.org, robert.cragie@gridmerge.com, 'Samita Chakrabarti' <samitac@ipinfusion.com>, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [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: Mon, 29 Nov 2010 12:09:57 -0000

Rafa,

> El 26/11/2010, a las 08:21, Alper Yegin escribió:
> 
> >> 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.
> >
> > Yes, RFC 5191 has an explicit support for that.
> >
> >
> >> So it seems that switching to direct communication requires to go
> >> through a full PANA authentication.
> >
> > I don't think that's necessary at all.
> >
> > If the PaC learns another (or new) IP address of the PAA by some out-
> of
> > scope mechanism, then it can start using that IP address. And that's
> the
> > case in Zigbee.
> 
> [Rafa] What I believed is that a new PANA authentication was necessary
> when you switch the PAA's interface, as Yoshi has mentioned. It does
> not mean that it is the best option of course, but what happens is that
> there is no support for PAA's address change. I believe this scenario
> was not considered in RFC 5191. 

We didn't envision this scenario. Hence RFC 5191 is "silent" about it.
In other words, there is no explicit facility to realize that (PAA IP
address change), and there is no prohibition against it either. Which means,
if some implementation/SDO/deployment can figure out a way to enable that
w/o breaking the RFC, it's OK. And that's the case with this Zigbee Alliance
usage.


> In the same way that "In order to
> maintain the PANA session, the PAA needs to be notified about the
> change of PaC address.", I would expect a mechanism saying that: "In
> order to maintain the PANA session, the PaC needs to be notified about
> the change of PAA address."

We can say something to that affect in the relay I-D.

Alper




> 
> 
> >
> > Alper
> >
> >
> >
> >
> >> 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.
> >>>
> >
> >
> 
> -------------------------------------------------------
> Rafael Marin Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
> -------------------------------------------------------
> 
>