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

From: "Alper Yegin" <[email-masked]>
Date: Wed, 1 Dec 2010 16:25:51 +0200

I think this text is fine.

From: Robert Cragie [mailto:[email-masked]] 
Sent: Wednesday, December 01, 2010 3:51 PM
To: Alper Yegin
Cc: 'Yoshihiro Ohba'; 'Rafa Marin Lopez'; [email-masked]; 'Ralph Droms'; 'Samita Chakrabarti'; 'Paul Duffy (paduffy)'
Subject: Re: Switching to direct communication [was Re: PANA relay draft]

Maybe I'm missing something but switching to direct communication has nothing to do with a *change* in the PAA address. I would suggest the following:

"If direct IP routing becomes available[1] and the PaC is notified about the PAA's[2] IP address using an out-of-band mechanism that is not specified in this document, the PaC may choose to directly communicate with the PAA without use of the relay operation.  The PaC[3] IP address update procedure defined in [RFC5191] may additionally[4] be performed to switch to non-relay operation, using the directly reachable IP address of the PAA."

[1] Removed ZigBee IP reference
[2] "the change of PAA's" -> "the PAA's"
[3] Added PaC as per Alper's suggestion
[4] Added "additionally" as this is independent from getting the PAA address

Comments?

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/> 

On 30/11/2010 9:20 PM, Alper Yegin wrote: 

Looks good to me.
 
One minor update:
 
"The IP address update procedure" --> "PaC IP address update procedure"

Alper

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]]
Sent: Tuesday, November 30, 2010 3:52 AM
To: Alper Yegin
Cc: 'Rafa Marin Lopez'; [email-masked]; 'Ralph Droms';
[email-masked]; 'Samita Chakrabarti'; 'Paul Duffy
(paduffy)'
Subject: Re: Switching to direct communication [was Re: PANA relay
draft]
 
OK.  How about the following change?
 
Current text:
 
"If direct IP routing becomes available (e.g., after the successful
PANA authentication as in the case of Zigbee IP), the PaC may
choose to directly communicate with the PAA without use of the relay
operation.  The IP address update procedure defined in
[RFC5191] may be performed to switch to non-relay operation."
 
Propose text:
 
"If direct IP routing becomes available (e.g., after the successful
PANA authentication as in the case of Zigbee IP) and the PaC is
notified about the change of PAA's IP address using an out-of-band
mechanism that is not specified in this document, the PaC may choose
to directly communicate with the PAA without use of the relay
operation.  The IP address update procedure defined in [RFC5191] may
be performed to switch to non-relay operation, using the directly
reachable IP address of the PAA."
 
Yoshihiro Ohba
 
(2010/11/29 21:10), Alper Yegin wrote:

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: [email-masked]
-------------------------------------------------------

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 1 Dec 2010 15:30:11 +0100

Hi all,

my apologies for answering a bit late to this.

I do not completely understand the sentence:

"The PaC IP address update procedure defined in [RFC5191] may additionally be performed to switch to non-relay operation, using the directly reachable IP address of the PAA."

I think that the PaC IP address update procedure defined in [RFC5191] is useless for this scenario where the PAA "changes" its IP address. I believe what PaC must simply do is to update the IP address in the PANA session with the PAA's IP address obtained with this out of band mechanism.

This, my suggestion would be to remove that sentence.

Best regards.

El 01/12/2010, a las 14:50, Robert Cragie escribió:

> http://www.gridmerge.com

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 1 Dec 2010 15:31:32 +0100

Hi Alper, all

I am ok with this text.

El 01/12/2010, a las 08:47, Alper Yegin escribió:

> Yoshi,
> 
> " the solution must ensure that both the EAP peer and the EAP server can use
> the same PAA address"
> 
> This text is suggesting some solution. We better not do that. We shall just
> make the CB solution designer aware of this and request it be taken into
> account. 
> 
> With that, I'd propose:
> 
> 
> "In the relay operation, the IP address of PAA that is seen by the PaC
> (i.e., an IP address of the PRE) is different from the IP address of the PAA
> that is seen by the authentication server. If an EAP channel binding
> solution uses the IP address of PAA as part of channel binding parameters,
> such a solution must take this into account. Note that the same issue arises
> even when non-relayed PANA is used and the PAA has one IP address configured
> on its interface facing the PaC and another IP address on the other
> interface facing the authentication server."
> 
> Alper
> 
> 
> 
> 
> 
> 
>> Sent: Wednesday, December 01, 2010 1:58 AM
>> To: Alper Yegin
>> Subject: Re: Channel binding [ was Re: PANA relay draft]
>> 
>> OK.
>> 
>> Here is proposed text about channel binding, intended to be added to
>> Security Considerations section:
>> 
>> "In the relay operation, the IP address of PAA that is seen by the PaC
>> (i.e., an IP address of the PRE) is different from that is used by the
>> PAA to exchange PRY messages with the PRE.  Therefore, if an EAP
>> channel binding solution uses an IP address of PAA as part of channel
>> binding parameters, the solution must ensure that both the EAP peer
>> and the EAP server can use the same PAA address (i.e., either one of
>> the above two addresses)."
>> 
>> Yoshihiro Ohba
>> 
>> 
>> (2010/12/01 6:21), Alper Yegin wrote:
>>>> Let me create another thread specific to channel binding.
>>>> 
>>>> - In pana-relay, what PaC uses to communicate with PAA is PRE's
>>>> address, not PAA's address.
>>>> 
>>>> - At the time of channel binding, if PAA's address is part of
>> channel
>>>> binding parameter, then channel binding parameter verification will
>>>> fail because of the address difference.
>>>> 
>>>> - Rafa suggested a remedy to use PRE's address as PAA's address for
>>>> channel binding at both EAP peer and server, and Alper agreed on
>> that.
>>> 
>>> My point is, whatever channel binding solution is being used should
>> be able
>>> to handle this (what appears to be a) NAS with two IP addresses.
>>> 
>>> Alper
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> Is this correct?
>>>> 
>>>> Yoshihiro Ohba
>>>> 
>>>> 
>>>> (2010/11/29 21:06), Alper Yegin wrote:
>>>>> Hi Rafa,
>>>>> 
>>>>>>> One way to look at this is the NAS is composed of the PRE and the
>>>>>> PAA.
>>>>>>> Or, think of it as the NAS has to IP interfaces, one with the IP
>>>>>> address of
>>>>>>> PRE, the other with the IP address of PAA.
>>>>>> 
>>>>>> [Rafa] I think if that is the view I believe it should be
>> reflected
>>>>>> somehow. The reason is that until now in the I-D it seems the PRE
>> is
>>>> a
>>>>>> completely different entity from the PAA. In other words, they do
>>>> not
>>>>>> part of the same NAS. In fact, the PaC will have a PANA session
>>>> where
>>>>>> the "IP address and UDP port number of the PAA" which is actually
>>>> the
>>>>>> "IP address and UDP port number of the PRE."
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Which channel binding solution are you considering that'd have a
>>>>>> problem
>>>>>>> with this?
>>>>>> 
>>>>>> [Rafa] Basically, what I am thinking is that the PAA would send
>> its
>>>> IP
>>>>>> address for example to the AAA server as part of channel binding
>>>>>> parameter. The PaC however sees the IP address of the PRE. If the
>>>> AAA
>>>>>> informs to the PaC that PAA sent as channel binding parameter
>> PAA's
>>>> IP
>>>>>> address, the PaC will contrast this parameter with what the PaC
>> saw
>>>>>> (the PRE IP address) which basically does not match. If we follow
>>>> the
>>>>>> idea of that PRE is an interface of the PAA, most probably what
>> the
>>>> PAA
>>>>>> would have to send to the AAA is the PRE's IP address as channel
>>>>>> binding parameter.
>>>>> 
>>>>> Rafa, which specific channel binding solution are you referring to
>>>> here?
>>>>> And your proposed remedy above can handle the situation.
>>>>> My point is, whatever the channel binding solution is, it can
>> handle
>>>> this
>>>>> situation (which would also arise in the very simple case where a
>>>> simple PAA
>>>>> were using two different IP addresses -- one facing the PaC and the
>>>> one
>>>>> facing the PAA).
>>>>> 
>>>>> 
>>>>>>>> What about allowing the PAA to answer the PaC (through the
>>>>>>>> PRE) with the PAA's IP address? The PCI sent by the PaC will not
>>>>>> carry
>>>>>>>> that IP address but the PaC would see a PAR coming from a PAA
>> and
>>>> it
>>>>>>>> would engage the PANA authentication with it.
>>>>>>> 
>>>>>>> PRE sourcing IP packets with PAA's IP address, and accepting IP
>>>>>> packets
>>>>>>> destined to PAA, and PaC using its link-local address to
>>>> communicate
>>>>>> with
>>>>>>> the PAA's global IP address... these are not trivial.
>>>>>>> 
>>>>>>> I'd think a NAS with two IP addresses and using one at one phase
>>>> and
>>>>>> another
>>>>>>> at a latter phase is not such a problem.
>>>>>>> 
>>>>>>> We could have the same issue in another simpler case: consider
>> PaC
>>>>>> being
>>>>>>> authenticated on one interface of PAA, and later PaC attaches to
>>>>>> another
>>>>>>> interface of the PAA. PAA may have two different IP addresses on
>>>> each
>>>>>>> interface. Yet, the same PANa sessions shall be available thru
>> both
>>>>>>> interfaces.
>>>>>> 
>>>>>> [Rafa] But the PANA session has to change in the attribute "IP
>>>> address
>>>>>> and UDP port number of the PAA" and that change (I believe this is
>>>>>> related with the recent Yoshi's e-mail) must happen in the PaC.
>>>>> 
>>>>> We can mention that in the I-D.
>>>>> 
>>>>>> In the
>>>>>> RFC 5191 it is said: "In order to maintain the PANA session, the
>> PAA
>>>>>> needs to be notified about the change of PaC address." I would
>>>> expect
>>>>>> the same in the PaC (I will answer Yoshi's e-mail about this).
>>>>> 
>>>>> If you are suggesting this be changed on PANA RFC 5191, I don't
>> think
>>>> this
>>>>> is necessary.
>>>>> A mention of that in the relay I-D makes sense.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Alper
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Best regards.
>>>>>> 
>>>>>>> 
>>>>>>> Alper
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Best Regards,
>>>>>>>>> Yoshihiro Ohba
>>>>>>>>> 
>>>>>>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 02 Dec 2010 08:43:34 +0900

I am in favor of leave it out completely, then.  The reason is that 
the feature of changing PAA address with continuing the PANA session 
seems to have general applicability in addition to the relay use case. 
  I think "less is more" design philosophy can be applied here.

Yoshihiro Ohba

(2010/12/02 0:18), Robert Cragie wrote:
> Hi Rafa,
>
> I agree it is not relevant relevant for *switching* to non-relay
> operation but may be necessary to continue a session when
> communicating directly (in an IP sense) with the PAA.
>
> I suggest we either leave it out completely:
>
> "If direct IP routing becomes available and the PaC is notified about
> the PAA's IP address using an out-of-band mechanism that is not
> specified in this document, the PaC may choose to directly communicate
> with the PAA without use of the relay operation."
>
> or change it to the following to suggest it may still have a place:
>
> "If direct IP routing becomes available and the PaC is notified about
> the PAA's[ IP address using an out-of-band mechanism that is not
> specified in this document, the PaC may choose to directly communicate
> with the PAA without use of the relay operation. The PaC IP address
> update procedure defined in [RFC5191] may additionally need to be
> performed using[1] the directly reachable IP address of the PAA."
>
> [1] "be performed to switch to non-relay operation, using" -> "need to
> be performed using"
>
> Robert
>
> On 01/12/2010 2:30 PM, Rafa Marin Lopez wrote:
>> Hi all,
>>
>> "The PaC IP address update procedure defined in [RFC5191] may
>> additionally be performed to switch to non-relay operation, using
>> the directly reachable IP address of the PAA."
>>
>> I think that the PaC IP address update procedure defined in
>> [RFC5191] is useless for this scenario where the PAA "changes" its
>> IP address. I believe what PaC must simply do is to update the IP
>> address in the PANA session with the PAA's IP address obtained with
>> this out of band mechanism.
>>
>>> Maybe I'm missing something but switching to direct communication
>>> has nothing to do with a *change* in the PAA address. I would
>>> suggest the following:
>>>
>>> "If direct IP routing becomes available[1] and the PaC is notified
>>> about the PAA's[2] IP address using an out-of-band mechanism that
>>> is not specified in this document, the PaC may choose to directly
>>> communicate with the PAA without use of the relay operation. The
>>> PaC[3] IP address update procedure defined in [RFC5191] may
>>> additionally[4] be performed to switch to non-relay operation,
>>> using the directly reachable IP address of the PAA."
>>>
>>>>> Cc: 'Rafa Marin Lopez';[email-masked]; 'Ralph Droms';
>>>>>>> Telf: +34868888501 Fax: +34868884151 e-mail:[email-masked]
>> <mailto:[email-masked]>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 2 Dec 2010 00:59:19 +0100

Hi Robert, all

I am in favour to leave it out completely. I think the text is fine without that sentence.

Best regards.

On Dec 1, 2010, at 4:18 PM, Robert Cragie wrote:

> Hi Rafa,
> 
> I agree it is not relevant relevant for *switching* to non-relay operation but may be necessary to continue a session when     communicating directly (in an IP sense) with the PAA.
> 
> "If direct IP routing becomes available and the PaC is notified about the PAA's IP address using an out-of-band mechanism that is not specified in this document, the PaC may choose to directly communicate with the PAA without use of the relay operation."
> 
> "If direct IP routing becomes available and the PaC is notified about the PAA's[ IP address using an out-of-band mechanism that is not specified in this document, the PaC may choose to directly communicate with the PAA without use of the relay operation.  The PaC IP address update procedure defined in [RFC5191] may additionally need to be performed using[1] the directly reachable IP address of the PAA."
> 
> [1] "be performed to switch to non-relay operation, using" -> "need to be performed using"
> 
> Robert