Re: [Pana] PANA relay draft

[Rafa Marin Lopez <[e-mail]>]

Hi Alper,


El 24/11/2010, a las 13:32, Alper Yegin escribió:

> Hi Rafa,
> 
> Thanks for the review.
> 
> Let me inject my own input while we are also waiting for Yoshi's.

[Rafa] Sure.

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

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

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

> 
> Alper
> 
> 
>> 
>>> 
>>> Best Regards,
>>> Yoshihiro Ohba
>>> 
>> 
>> -------------------------------------------------------
>> Rafael Marin Lopez, PhD
>> Dept. Information and Communications Engineering (DIIC)
>> Faculty of Computer Science-University of Murcia
>> 30100 Murcia - Spain
>> Telf: [phone] Fax: [phone] e-mail: [e-mail]
>> -------------------------------------------------------
>> 
>> 
> 
> 

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: [phone] Fax: [phone] e-mail: [e-mail]
-------------------------------------------------------