Subject: [Pana] Review of I-D: draft-ietf-pana-preauth-05

From: <[email-masked]>
Date: Fri, 12 Jun 2009 18:14:06 +0200

Hello,

My review comments on the I-D: draft-ietf-pana-preauth-05.txt

- s/to which the PANA client may move./to which the PANA client may
  move to. 

- "Serving Network:  The access network through which the host gains
   access to the Internet/intranet."

   Would it be better to say that the serving network is the network
   via which the host is currently attached. So from a PANA
   perspective the serving network is the one in which the PaC has
   been authenticated and has an active SA.

- In sec 3:
"   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."

   If the discovery of the CPAA is not specified here, would it be
   specified in another document? Or is the assumption that the CPAA
   could be discovered via DNS, DHCP etc.? Without a reference to the
   possible mechanisms, the solution has some gaps.

- "  Pre-authentication may be initiated by both a PaC and a CPAA. "

  How can the CPAA initiate pre-auth? How would the CPAA even be aware
  of a PaC that is in a handover state? CPAA initiating pre-auth does
  not appear to be a feasible option.

-  "   The PANA session between the PaC and a CPAA is deleted by entering
   the termination phase of the PANA protocol."

   When does the PaC decide to terminate a PANA session with a CPAA?
   The CPAA either transitions to the SPAA or not. Since the PaC can
   initiate the pre-auth session with several CPAAs, is it the intent
   that the PaC would terminate the sessions with other CPAAs as
   needed?

- Figure 2 shows the PAA initiated pre-auth signaling. What are the
  potential triggers at the CPAA? Would be useful to mention any
  assumptions that are made in CPAA initiated pre-auth. Or drop the
  CPAA initiated pre-auth from the I-D.

- "   When pre-authentication is initiated by CPAA, it is possible that
   multiple CPAAs simultaneously initiate pre-authentication for the
   same PaC.  In order to avoid possible resource consumption attacks on
   the PaC caused by an attacker initiating pre-authentication for the
   PaC by changing source addresses, the PaC SHOULD limit the maximum
   number of CPAAs allowed to communicate."

   I think it is better to have pre-auth always initiated by the
   PaC. In what specific scenario would you need to have the PAA
   initiate pre-auth? Is there a downside to having preauth always
   initiated by the PaC only?

- Is the assumption that the CPAA is within the same administrative
  domain as the serving network? I think it would be useful to mention
  the scenario where the serving and target networks have no security
  relationship. In such a case does the pre-auth still work?

-Raj

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 14 Jun 2009 16:36:13 -0400

Hi Basavaraj,

Thank you for the review.  Please see my comments below.

> - s/to which the PANA client may move./to which the PANA client may
OK.
>    been authenticated and has an active SA.
How about this?

"Serving Network: The access network to which the host is currently
attached."

>    possible mechanisms, the solution has some gaps.

We can refer to IEEE 802.21 Information Service as an example method for
the host to discover various network elements in neighboring networks.

>   not appear to be a feasible option.

A handover command (such as 802.21 handover command) can be used for the
CPAA to discover PaC in a handover state.

>    that the PaC would terminate the sessions with other CPAAs as
For example, when the PaC moves to other PAA, the CPAA may not be a
candidate any more nor the SPAA. In this case, the PaC may wants to
terminate the PANA session with the CPAA.
>   CPAA initiated pre-auth from the I-D.

This is related to your 4th comment. A handover command can be used as a
trigger at the CPAA.

>    initiated by the PaC only?
I could not think about a downside of not having PAA-initiated preauth
for the following reason:

- PAA-initiated preauth is for network-controlled handover that would
require a handover command as a trigger at the CPAA.

- MN (PaC) is also involved in such a handover command, which means the
command can also trigger PaC-initiated preauth.

So I do not mind dropping PAA-initiated preauth  and removing the above
security claim.

>   relationship. In such a case does the pre-auth still work?

The serving and target networks may not be in the same administrative
domain and there may not be a security relationship between them, and
PANA preauth will work for those cases as long as there is a way for the 
PaC and CPAA to discover each other. We can mention it in Introduction 
section.

Regards,
Yoshihiro Ohba

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

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 15 Jun 2009 11:43:24 +0300

> the host to discover various network elements in neighboring networks.

Yes, as an informative reference that'd be useful.

> So I do not mind dropping PAA-initiated preauth  and removing the above

PAA-initiated pre-auth raises some questions that can only be answered in an
"architecture design". If people want to drop this case, I don't care much.
But note that the PAA-initiated pre-auth is a natural consequence of the
marriage between pre-auth and the PANA -- PANA already supports
PAA-initiated auth. So, unless we do anything special (to eliminate this
case), it comes for free. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 27 Jun 2009 20:21:25 -0400

Changes:

- Revised definition of "Serving Network".

- Added an informational reference for 802.21 as an example mechanism 
for discovering PaC and CPAA to discover each other.

Basavaraj questioned about the need for PAA-initiated pre-auth, and I 
agreed with his comment. But
PAA-initiated pre-auth still remains, based on Alper's comment "PANA 
already supports PAA-initiated auth. So, unless we do anything special 
(to eliminate this case), it comes for free."

Best Regards,
Yoshihiro Ohba

---

From: <[email-masked]>
Date: Mon, 29 Jun 2009 18:22:15 +0200

Hi Yoshi,

> (to eliminate this case), it comes for free."

Even though PANA supports PAA-initiated auth, I do not believe this is
applicable in the case where the target network to which the host is not
even attached would be able to trigger authentication.
So while the PAA-initiated auth makes sense in the regular PANA use case, I
don't see this as being valid in the scenario described in the pre-auth I-D.

So I would recommend dropping this scenario from the I-D.

-Raj

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 29 Jun 2009 19:39:48 +0300

Raj,

> don't see this as being valid in the scenario described in the pre-auth

As you know, there are examples of wireless network architectures that
support network-initiated handovers. Such architectures are aware of the
mobile's target network elements (BS, authenticator, etc.) and perform a
number of signaling in the infra-side and also dictate the mobile to move.
Such architectures are potentially capable of using network-initiated
pre-auth.

I'm inclined to keep PAA-initiated pre-auth in the spec because it has some
potential use, it is harmless, removing it from spec is more work than
keeping it, and it comes for free due to its built-in nature to the base
spec. So, I don't see the benefit of removing it, or cost/complexity of
keeping it. Maybe I'm missing something.

Alper