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

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 22 Jan 2009 09:39:26 -0500

Yes, some of your comments were already raised by others and
resolution is proposed.  So let me ignore those.

Please see my comments below.

>
> *** In abstract ‘administrative domains’ but above ‘AAA domains’ are used.
>
> Are they same? The document should use a consistent terminology.

We should consistently use AAA domains.  Thanks.

>
>
> 2. Terminogy
>
> 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
>
> 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.
>
> *** Not sure I understand the relevance of this in the definition ***

I agree.  We can remove the sentence "For simplicity, ....".

>
>
> Pre-authorization: An authorization for a PaC, made by a CPAA for
>
> the PaC at the time of pre-authentication.
>
> *** Do we need for the Pac again? Alternatively we can possibly say
>
> ‘An Authorization made by CPAA for a PaC at the time of pre-authentication”

I agree, your text is better.

>
> Post-authorization: An authorization for a PaC, made by a CPAA for
>
> the PaC when the CPAA becomes the SPAA for the PaC.
>
> *** same as above ***

I agree.

>
> 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).
>
> *** the text in the parenthesis is not clear ***

The parenthesis is based on the definition of post-authorization in
section 2.

>
> 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.
>
> *** Missing ‘bit’ after ‘E’ ***

You are right, 'bit' is needed.

>
> 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.
>
> *** Not clear the purpose of the above operation. Even if PaC performs  
> IP address
> update, how long does it keep this SA? For example, if PaC moves to  
> another CPAA does
>
> it still need to maintain and continue this operation ? ***

IP address update itself does not affect the SA lifetime for CPAA.
You have a good point that maintaining the SA for a CPAA after the
movement to another CPAA does not have to be a mandatory operation.
I agree that this paragraph needs to be revised accordingly.

>
> PNR and PNA messages with 'P' (Ping) bit set is used for this purpose.
>
> *** typo: should be ‘are’ ***

OK.

>
> 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.
>
> 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.
>
> *** What will happen if Pac has multiple such pre-authorization SAs? ***

If there are multiple CPAAs, the procedure is performed per-CPAA
basis.

>
> E(PrE-authentication) When pre-authentication is performed, the 'E'
>
> (prE-authentication) bit of PANA messages are set in order to
>
> indicate whether this PANA run is for establishing a pre-
>
> authorization SA.
>
> *** Typo: should be ‘is’

OK.

>
>
> 5. Authorization and Accounting Considerations
>
> A pre-authorization and a post-authorization for the PaC may have
>
> different authorization policies. For example, the pre-authorization
>
> policy may not allow the PaC to sent or receive packets
>
> *** Typo: should be ‘send’ ***
>
> 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.
>
> *** Not sure I understand the above. How a post-authorization with the
> SPAA obtained in the first place? ***
>
>
> Also, each access network that supports pre-
>
> authentication SHOULD block pre-authentication attempts from networks
>
> from which a handover is not likely to occur.
>
> *** Is there any relationship between handover protocol and pre-auth?

There is no relationship between a specific handover protocol and PANA
pre-auth.  It's just a matter of changing from one access network to
another.  Having said that we can revise the text something like:

"
Also, each access network that supports pre-authentication SHOULD
block pre-authentication attempts from networks from which a change of
access network is not likely to occur.
"

>
> How does access network will know that handover is not likely to occur? ***
>

For example, handover is not likely to happen between an access network in Tokyo 
and an access network in NYC.

Yoshihiro Ohba

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

---

From: Subir Das <[email-masked]>
Date: Thu, 22 Jan 2009 15:34:05 -0500

"

But the question remains; how the access network will know "handover is 
not likely to occur"? Since this draft possibly can not solve this problem, 
it may be better to explicitly mention that how access network identify this, 
it is outside the scope of this work. 

Yoshihiro Ohba wrote:
> Thank you Subir for the review.  
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 23 Jan 2009 15:14:35 -0500

> Thanks. I have one suggestion on the following:
> 

I agree.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 27 Jan 2009 11:52:55 +0200

> and an access network in NYC.

I think what we really want to imply is that a given access network may be
configured to allow/disallow pre-authentication from a set of access
networks. 

"likeliness", "pre-configuration", etc. are all left to deployments...

Alper