Subject: [Pana] Comments on the draft on the Network Selection

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 23 Nov 2007 12:54:31 +0100

Hi Yoshi,

Please find here a feedback after a brief review of the draft
draft-ohba-pana-netsel-00.

I would be in favor to separate NAP-ISP separate authentication aspects
from ISP selection.
In particular, I don't see why the ISP selection should rely on the
presence/absence of the "N" bit in the Flags field.

I think the "N" flag should just indicate to the pana client that there
is an explicite NAP authentication in addition to the ISP
authentication. The indication will be therefore clear for the pac
receiving the message.

Moreover, we should describe that, if the pac doesn't support the new
feature "NAP-ISP authentication", it will likely ignore the new flag
even if set to 1 (otherwise we should clearly state the correct
behaviour) and will not set the flag in the PNA-Auth-Answer. When this
occurs, what is the behaviour of the PAA? We may assume that if NAP
authentication is locally required (and not supported by the pana
client), the PAA may send the last PANA-Auth-Request with a result code
PANA_AUTHORIZATION_REJECTED, as a network configuration option. This can
be only an optional behaviour as we should consider separate NAP and ISP
authentication as two independent procedures, as it was stated in
previous versions of the pana draft:

   "Within separate NAP and ISP authentication, the NAP authentication
   and the ISP authentication are considered completely independent.
   Presence or success of one should not effect the other.  Making a
   network access authorization decision based on the success or failure
   of each authentication is a network policy issue."
 
Both above points should be taken into account in the draft.

For the ISP selection, as said above, we should just rely on the support
and the use of the new "ISP-Information" AVP, specifically by the
presence of this AVP in messages sent by the pana client. The "N" flag
seems to be not needed for this procedure.
By the way, we should indicate that if the pana client inserts more than
one ISP-Information AVP, the PAA should reject the request. For now, it
is just stated that:

"The PANA-Auth-Answer message sent in response to this PANA-Auth-Request
message carries at most one ISP-Information AVP to indicate the ISP
chosen by the PaC"

Final comment: if the "N" flag only to advertise explicite NAP
authentication, the following restriction described in section 2.1 will
not be needed: "The PANA session used for ISP authentication MUST NOT
carry a NAP-Information AVP.". Both AVPs could be therefore used at any
time, even if useless or just for information. Even if only one ISP is
available, even if separate NAP-ISP authentication is not performed.
This could be easier from a implementation point of view. It would be
also useful to have an update of the AVP occurrence table provided in
the pana protocol specification.

I hope that my review was not too brief ;)

Best Regards,

Lionel Morand
Orange Labs

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 23 Nov 2007 12:35:19 -0500

Hi Lionel,

Thank you for reviewing the draft.  Please see my comments inline.

> authentication. The indication will be therefore clear for the pac

If we don't use 'N' bit for ISP selection, then the PaC that does not
support ISP selection will silently discard PAR that contains a new
AVP defined in this draft without falling back to the base protocol
operation without ISP selection.  That is why the draft uses 'N' bit
for both ISP selection as well as NAP and ISP separate authentication.

> occurs, what is the behaviour of the PAA? We may assume that if NAP

If the PaC does not support the new feature, the PAA will detect it
based on 'N' bit of the PAN returned by the PaC, the PANA session
should continue without the new feature (i.e., neither NAP and ISP
separate authentication nor ISP selection is used).  (This behavior
corresponds to older revisions of PANA that had NAP and ISP separate
authentication.)  We can add clarification text on this in the next
revision.

>    of each authentication is a network policy issue."

I agree that when NAP and ISP separate authentication is used, the NAP
authentication and ISP authentication should be completely
independent.  We can add the clarification text on this in the next
revision.

> seems to be not needed for this procedure.

The issue with your suggestion is that if the PaC does not understand
ISP-Information AVP, it will discard the entire message according to
Section 5.5 of PANA specification.  I believe that not including new
AVPs until negotiation on extended features that use the new AVPs is
completed is the way to maintain backwards compability.  Since PANA
does not have a Version field or Mandatory flag in AVP header, use of
bits in Flags field would be the only way to negotiate on any extended
feature.

> message carries at most one ISP-Information AVP to indicate the ISP

OK.

> the pana protocol specification.

As I commented above, the 'N' bit should be used for advertising
network selection function including both NAP and ISP separate
authentication and ISP selection.

Best Regards,
Yoshihiro Ohba