Subject: [Pana] PANA relay draft

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Nov 2010 10:46:11 +0000

A new draft extending PANA has been published: "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", draft-ohba-pana-relay-02.  This document will be advanced to the IESG as an AD-sponsored individual submission.  As part of the process, I'd like to get external review of the document.  Please read the draft and reply to [email-masked] with any comments.  Thanks.

- Ralph

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 18 Nov 2010 20:47:05 +0100

Dear all,

I have reviewed this I-D. My comments are attached. I have mainly some doubts/questions that I would like to clarify with the authors.

My comments are labelled as [Rafa].

El 16/11/2010, a las 11:46, Ralph Droms escribió:

> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pana

-------------------------------------------------------
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: Yoshihiro Ohba <[email-masked]>
Date: Sat, 20 Nov 2010 05:57:21 +0900

Hello Rafa,

(cc: to co-authors)

Thank you very much for reviewing the pana-relay draft.  Please see my 
comments below.

> [Rafa] parent router --> parent node?

Yes.  We will change the name accordingly.

>    (c) The source IP address and UDP port number of the PRY is
> stored in
> a new PANA session attribute "IP address and UDP port number of the
>    PRE".  A PANA session is referred to as a relayed PANA session if
>    this attribute has a non-null value.
>
> [Rafa] Why is "source IP address and UDP port number of the PRY"
> required? In other words, why is this session (relayed PANA
> session) required?

The source IP address and UDP port number of the PRY is required so 
that the PAA can send a PRY message (encapsulating a PANA message to 
be delivered to the PaC) to the PRE.  Note that the PAA may send a PRY 
not in response to receiving another PRY sent by the PRE, e.g., for 
PAA-initiated PANA-ping or termination phase or when the PAA sends a 
PAR after returning a PAN with no-piggybacking EAP in response to the 
previous PAR sent by the PaC.

>   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.

> 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] So basically PaC believes that it is contacting with a "PAA"
> (actually it is a PRE) with IP address IP2a:716, right?
> Related with PANA security association, the PaC believes that the
> MSK is used to is to communicate with the PRE (which the PaC sees
> as its PAA). However it is not, it is to communicate with the real
> PAA. If some channel binding mechanism is enabled this mechanism
> may fail I believe.
>
>
> [Rafa] Another question is: is there no way that PaC knows about
> the real PAA's IP address (IP3).?

We don't assume that the PaC know the real PAA's IP address until PANA 
authentication is successful.

Regarding channel binding, you are right that in the case where IP 
address of PAA is used as part of channel binding parameters, then 
there is an issue because PRE and PAA use different IP addresses.
I don't have an easy solution to address this issue in my mind, but we 
could perhaps add some text in Security Considerations section to 
discourage use of IP address of PAA for channel binding parameters 
when PANA relay is used with channel binding.  What do you think?

Best Regards,
Yoshihiro Ohba

(2010/11/19 4:47), Rafa Marin Lopez wrote:
> El 16/11/2010, a las 11:46, Ralph Droms escribiÃ³:
>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 24 Nov 2010 11:37:46 +0100

Hi Yoshi,

thanks for your answers. Please see below mine.

El 19/11/2010, a las 21:57, Yoshihiro Ohba escribió:

> Hello Rafa,
> 
> (cc: to co-authors)
> 
> Thank you very much for reviewing the pana-relay draft.  Please see my comments below.
> 
> 
> The source IP address and UDP port number of the PRY is required so that the PAA can send a PRY message (encapsulating a PANA message to be delivered to the PaC) to the PRE.  Note that the PAA may send a PRY not in response to receiving another PRY sent by the PRE, e.g., for PAA-initiated PANA-ping or termination phase or when the PAA sends a PAR after returning a PAN with no-piggybacking EAP in response to the previous PAR sent by the PaC.

[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.

> 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?.

> An EP may reside in the PRE, or it could be a separate entity from the PRE.
> 
>> the PaC may choose
> 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 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)

> We don't assume that the PaC know the real PAA's IP address until PANA authentication is successful.
> 
> Regarding channel binding, you are right that in the case where IP address of PAA is used as part of channel binding parameters, then there is an issue because PRE and PAA use different IP addresses.
> I don't have an easy solution to address this issue in my mind, but we could perhaps add some text in Security Considerations section to discourage use of IP address of PAA for channel binding parameters when PANA relay is used with channel binding.  What do you think?

[Rafa] One problem I see is that, very likely, the IP address of a NAS (in particular the PAA) will be used as channel binding parameter.  I think the problem arises because the PaC believes he is talking to the PAA that is performing the authentication when actually it is not (it is the PRE). 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.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 24 Nov 2010 14:32:58 +0200

Hi Rafa,

Thanks for the review.

Let me inject my own input while we are also waiting for Yoshi's.

> that the PAA can send a PRY message (encapsulating a PANA message to be
> delivered to the PaC) to the PRE.  Note that the PAA may send a PRY not
> in response to receiving another PRY sent by the PRE, e.g., for PAA-
> initiated PANA-ping or termination phase or when the PAA sends a PAR
> after returning a PAN with no-piggybacking EAP in response to the
> [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.

> [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.

> [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.

> > I don't have an easy solution to address this issue in my mind, but
> we could perhaps add some text in Security Considerations section to
> discourage use of IP address of PAA for channel binding parameters when
> PANA relay is used with channel binding.  What do you think?
> 
> [Rafa] One problem I see is that, very likely, the IP address of a NAS
> (in particular the PAA) will be used as channel binding parameter.  I
> think the problem arises because the PaC believes he is talking to the
> PAA that is performing the authentication when actually it is not (it
> is the PRE). 

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. 

Which channel binding solution are you considering that'd have a problem
with this?

> 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.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Nov 2010 08:27:38 +0900

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

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 Nov 2010 09:21:39 +0200

> but does not support change of PAA's address.

Yes, RFC 5191 has an explicit support for that.

> 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.

Alper

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 26 Nov 2010 10:50:37 +0100

Hi Alper,

> Let me inject my own input while we are also waiting for Yoshi's.

[Rafa] Sure.

> 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

[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.

> interface. Yet, the same PANa sessions shall be available thru both

[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. 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).

Best regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 26 Nov 2010 12:26:07 +0100

Hi Alper, Yoshi

> scope mechanism, then it can start using that IP address. And that's the

[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. 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."

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 29 Nov 2010 14:06:49 +0200

Hi Rafa,

> [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."
> 
> 
> >
> [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). 

> [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

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 29 Nov 2010 14:10:43 +0200

Rafa,

> [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

> >>>> able to contact directly the PAA without the assistance of the
> PRE.
> >> If
> >>> I think this spec shall not mandate or prohibit use of PRE after
> the
> >> first
> >>>>> An EP may reside in the PRE, or it could be a separate entity
> from
> >>>> the PRE.
> >>>>>
> >>>>>> the PaC may choose
> >>>>> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Nov 2010 10:52:06 +0900

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Nov 2010 11:07:46 +0900

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.

Is this correct?

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 30 Nov 2010 23:20:38 +0200

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]
> 
> >>> 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.
> >>
> >>>>>> I assume that after the successful PAA authentication the PaC
> will
> >>>> be
> >>>>> I think the spec shall say "direct IP routing MAY be available".
> In
> >>>> the
> >>>>>> 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.
> >>>>>
> >>>
> >>>
> >>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 30 Nov 2010 23:21:40 +0200

> 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

> >>> destined to PAA, and PaC using its link-local address to
> communicate
> >> with
> >>> I'd think a NAS with two IP addresses and using one at one phase
> and
> >> another

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 01 Dec 2010 08:58:15 +0900

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

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 1 Dec 2010 09:47:40 +0200

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.
> 
> >>>> somehow. The reason is that until now in the I-D it seems the PRE
> is
> >> a
> >>>> [Rafa] Basically, what I am thinking is that the PAA would send
> its
> >> IP
> >>>> informs to the PaC that PAA sent as channel binding parameter
> PAA's
> >> IP
> >>>> idea of that PRE is an interface of the PAA, most probably what
> the
> >> PAA
> >>> My point is, whatever the channel binding solution is, it can
> handle
> >> this
> >>>>>> that IP address but the PaC would see a PAR coming from a PAA
> and
> >> it
> >>>>> We could have the same issue in another simpler case: consider
> PaC
> >>>> being
> >>> If you are suggesting this be changed on PANA RFC 5191, I don't
> think
> >> this
> >>> is necessary.