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 pana@ietf.org with any comments. Thanks.
- Ralph
_______________________________________________
Pana mailing list
Pana@ietf.org
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: r...@um.es
-------------------------------------------------------
_______________________________________________
Pana mailing list
Pana@ietf.org
https://www.ietf.org/mailman/listinfo/pana
_______________________________________________
Pana mailing list
Pana@ietf.org
https://www.ietf.org/mailman/listinfo/pana
