Re: [Pana] PANA relay draft

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

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


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

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

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

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