Subject: [Pana] Review of draft-ietf-pana-preauth-04.txt

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 19 Jan 2009 17:38:41 +0100

Dear all,

here it is my review of draft-ietf-pana-preauth-04.txt

Initially, the document is in a good shape for me but I have some minor
questions and comments.

   This document defines an extension to the PANA protocol [RFC5191]
   used for proactively executing EAP authentication and establishing a
   PANA SA (Security Association) between a PaC in an access network and
   a PAA in another access network to which the PaC may move.  The
   proposed method operates across multiple AAA domains.  The extension
   to the PANA protocol is designed to realize direct pre-authentication
   defined in [I-D.ietf-hokey-preauth-ps].

[Rafa] I believe that an explanation of "access network" and "AAA
domain" might be added here and also in the terminology section.

<snip>

[Rafa] 2.  Terminogy --> Terminology

   The following terms are used in this document in addition to the
   terms defined in [RFC5191].

   Serving PAA (SPAA):  A PAA that resides in the serving network and

[Rafa] The definition of serving network should be provided.

      provides network access authentication for a particular PaC.  For
      simplicity, this document assumes that there is only one SPAA in
      the serving network while the pre-authentication mechanism
      described in this document is generally applicable to the case
      where there are two or more SPAAs in the serving network.
<snip>

Pre-authorization SA:  A PANA SA established between a PaC and its
      CPAA.

   Post-authorization SA:  A PANA SA established between the PaC and its
      SPAA.

[Rafa] Agree with Alper here. Pre-authorization SA and
Post-Authorization SA is the PANA SA between the PaC and the CPAA. The 
CPAA will be the SPAA but I believe that no new PANA SA is created after 
the movement; it is only an update of the PANA SA.

3.  Pre-authentication Procedure

   A PaC that supports pre-authentication may establish a PANA session
   for each CPAA.

   There may be several mechanisms for a PaC and a CPAA to discover each
   other.  However, such mechanisms are out of the scope of this
   document.

   There may be a number of criteria for CPAA selection, the timing to
   start pre-authentication and the timing to make a pre-authorization
   SA a post-authorization SA (and hence the CPAA becomes the SPAA).

[Rafa] This text may need to be revised if previous comment is accepted.

<snip>

   When a CPAA with which the PaC has a pre-authorization SA becomes the
   SPAA due to, e.g., movement of the PaC, the PaC performs an IP
   address update procedure defined in Section 5.6 of [RFC5191] in order
   to update the SPAA with the PaC's new address obtained from the new
   serving network.  PANA-Notification-Request (PNR) and PANA-
   Notification-Answer (PNA) messages with 'P' (Ping) bit set are used
   for this purpose.  The completion of the IP address update procedure
   will change the pre-authorization SA to a post-authorization SA.  In
   this case, the 'E' MUST NOT be set in the PNR and PNA messages and
   subsequent PANA messages.

   If there is another CPAA with which the PaC has a pre-authorization
   SA and the PaC wants to keep the pre-authorization SA after the
   change of SPAA, the PaC also performs an IP address update procedure
   defined in Section 5.6 of [RFC5191] in order to update the CPAA with
   the PaC's new address. PNR and PNA messages with 'P' (Ping) bit set
   is used for this purpose.  In this case, the 'E' (prE-authentication)
   bit MUST be set in the PNR and PNA messages and subsequent PANA
   messages.  The IP address update procedure with the CPAA will not
   change the pre-authorization SA to a post-authorization SA.

[Rafa] Let me understand this. It seems you're describing here two
alternatives. Either you update the PANA SA (with the CPAA) AFTER the 
movement (PNR-PNA without E bit set) or BEFORE the movement (PNR-PNA 
with E bit set). Is that correct?.

   The pre-authorization SA and the corresponding PANA session between
   the PaC and a CPAA is deleted by entering the termination phase of
   the PANA protocol.

   Example call flows for PaC-initiated pre-authentication and PAA-
   initiated pre-authentication are shown in Figure 1 and Figure 2,
   respectively.

[Rafa]. Fig 1 and Fig. 2 are rather similar except for
pre-authentication trigger and the PCI, right?
Maybe an unified figure could be better or simplify one of them.

<snip>

6.  Security Considerations

   Since the mechanism described in this document is designed to work
   across multiple access networks, each EP in the serving network
   SHOULD be configured to allow PANA messages to be forwarded between a
   PaC and a CPAA only if the PaC has a post-authorization SA with the
   SPAA in order to avoid an unauthorized PaC to initiate pre-
   authentication.

[Rafa] I think I have a similar comment as Alper's. Since PANA works
over UDP, if the EP in the serving network is configured to allow IP 
traffic to that PaC, why should we restrict the PaC to send PANA 
pre-authentication messages to other CPAA? Or in other words, why should 
we relay in the SPAA (that could belongs to a different domain than 
CPAA) to enforce this?.

Best Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Jan 2009 18:13:51 -0500

Rafa,

Thank you for reviewing the document.  Please see my response below.

> domain" might be added here and also in the terminology section.

I think these terms are popularly used in many documents and I don't
think we need to define them in this document.

> [Rafa] 2.  Terminogy --> Terminology

OK.

> [Rafa] The definition of serving network should be provided.

How about this?

"Serving Network: The access network that is currently providing
network access to the PaC."

> the movement; it is only an update of the PANA SA.

I agree.  In response to Alper's comment, I explained it is meant 
to indicate a state of the PANA session.  How about changing them to:

"
Pre-authorization state: A state to represent an established PANA
session between a PaC and its CPAA.

Post-authorization state: A state to represent an established PANA
session between the PaC and its SPAA.
"

> [Rafa] This text may need to be revised if previous comment is accepted.

Yes.  s/pre-authentication SA/pre-authentication state/.
s/post-authentication SA/post-authentication state/.

> with E bit set). Is that correct?.

No, both of two operation happens after the movement.  The difference
between the two operation is that the first paragraph describes the IP
address update procedure when CPAA changes to SPAA after the movement.
The second paragraph describes the IP address update procedure when
CPAA is still CPAA after the movement.

> Maybe an unified figure could be better or simplify one of them.

I think merging the two figures become complicated...

> we relay in the SPAA (that could belongs to a different domain than  

I agree, and revised text is proposed in response to Alper's comment.

Thanks,
Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 20 Jan 2009 19:16:24 +0100

Hi Yoshi,

thanks for the answers. Please see inline.
> think we need to define them in this document.
[Rafa] OK.
> network access to the PaC."
[Rafa] OK.
> session between the PaC and its SPAA.
[Rafa] How about ?

Pre-authorization state: The PANA SA state that represents an established PANA
session between a PaC and its CPAA.

Post-authorization state: The PANA SA state that represents an established PANA
session between the PaC and its SPAA.

> CPAA is still CPAA after the movement.
[Rafa] Oh I see. I understand. However, in that case, I am assuming that 
the PANA SA of a CPAA should be updated whenever a PaC's IP address 
change happens and the CPAA is still a CPAA, even when the SPAA remains 
the same, right?.

This would mean that the paragraph:

"If there is another CPAA with which the PaC has a pre-authorization SA 
and the PaC wants to keep the pre-authorization SA after the change of 
SPAA..."

should read

"If there is another CPAA with which the PaC has a pre-authorization SA 
and the PaC wants to keep the pre-authorization SA after a change of 
PaC's IP address in the serving network..."

what do you think?

> I think merging the two figures become complicated...
[Rafa] Ok, no problem.
> I agree, and revised text is proposed in response to Alper's comment.
[Rafa] Ok. I just read it. It is fine for me.

Thanks.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 20 Jan 2009 13:47:58 -0500

Rafa,

On Tue, Jan 20, 2009 at 07:16:24PM +0100, Rafa Marin Lopez wrote:

(snip)

>> I agree.  In response to Alper's comment, I explained it is meant to 
>> indicate a state of the PANA session.  How about changing them to:
>>
>> "

The difference between yours and mine is basically whether the "state"
is in terms of a PANA SA or a PANA session.  Given that any state
belongs to a PANA session, it should be sufficient to describe the
"state" here in terms of a PANA session, IMO.

> change happens and the CPAA is still a CPAA, even when the SPAA remains  

Yes, you are right.

> PaC's IP address in the serving network..."

I agree with your suggested text since it also covers the case of IP
address change without chaning SPAA.

Thanks,
Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 20 Jan 2009 20:45:01 +0100

> "state" here in terms of a PANA session, IMO.
[Rafa] That's ok for me.
> address change without chaning SPAA.
[Rafa] Ok, perfect.

Thanks.