Re: [Pana] PANA relay draft

[Yoshihiro Ohba <[e-mail]>]

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:
> 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ó:
>
>> 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 [e-mail] with any comments.  Thanks.
>>
>> - Ralph
>>
>> _______________________________________________
>> Pana mailing list
>> [e-mail]
>> 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: [phone] Fax: [phone] e-mail: [e-mail]
> -------------------------------------------------------
>
>
>
>
>
>
>
> _______________________________________________
> Pana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pana