Protocol Action: 'Protocol for Carrying Authentication for Network Access (PANA)' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following documents:

- 'Protocol for Carrying Authentication for Network Access (PANA) '
   <draft-ietf-pana-pana-18.txt> as a Proposed Standard
- 'Protocol for Carrying Authentication for Network Access (PANA) 
   Framework '
   <draft-ietf-pana-framework-10.txt> as an Informational RFC

These documents are products of the Protocol for carrying Authentication 
for Network Access Working Group. 

The IESG contact persons are Mark Townsley and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-18.txt

Technical Summary

   This document defines the Protocol for Carrying Authentication for
   Network Access (PANA), a network-layer transport for Extensible
   Authentication Protocol (EAP) to enable network access authentication
   between clients and access networks.  In EAP terms, PANA is a UDP-
   based EAP lower layer that runs between the EAP peer and the EAP
   authenticator. 

Working Group Summary
 
  This working group has had an uphill battle since inception, and has
  persevered through it all. In May 2006, during IETF Last Call, there 
  was a rather significant backlash against the documents, with 
  constructive comments boiling down mostly to questions of scope 
  and level of complexity in the protocol for the task at hand. The WG 
  has since hunkered down and rewritten the specs over the last year,
  with improved results. The documents have been through a second 
  round of IETF Last Call, pointing this out in the process. A summary 
  of changes can be found here:  

  http://panasec.org/docs/listof-changes.txt

  A second balloting by the IESG and third IETF last call was 
  performed in Sept 2007.

Protocol Quality
 
 The protocol was reviewed in depth by Mark Townsley and Jari Arkko after
 the first IETF Last Call. The protocol has improved markedly in terms of
 overall complexity.

Note to RFC Editor
 
In Section 4.1 of pana-pana, the original paragraph reads:

   The PaC may need to reconfigure IP address after successful
   authentication and authorization phase to obtain an IP address that
   is usable for exchanging data traffic through EP.  In this case, the
   PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request
   messages in the authentication and authorization phase to indicate
   the PaC the need for IP address reconfiguration.  How IP address
   reconfiguration is performed is outside the scope of this document.

Change that to (by adding a reference):

   For reasons described in Section 3 of [I-D.ietf-pana-framework], the
PaC 
   may need to reconfigure IP address after successful
   authentication and authorization phase to obtain an IP address that
   is usable for exchanging data traffic through EP.  In this case, the
   PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request
   messages in the authentication and authorization phase to indicate
   the PaC the need for IP address reconfiguration.  How IP address
   reconfiguration is performed is outside the scope of this document.

Similarly, in Section 5.6 of pana-pana, the original paragraph reads:

   A PaC's IP address used for PANA can change in certain situations,
   e.g., when IP address reconfiguration is needed for the PaC to obtain
   an IP address after successful PANA authentication (see Section 4.1)
   or when the PaC moves from one IP link to another within the same
   PAA's realm.  In order to maintain the PANA session, the PAA needs to
   be notified about the change of PaC address.

Change that to:

   A PaC's IP address used for PANA can change in certain situations,
   e.g., when IP address reconfiguration is needed for the PaC to obtain
   an IP address after successful PANA authentication (see Section 3
   of [I-D.ietf-pana-framework])
   or when the PaC moves from one IP link to another within the same
   PAA's realm.  In order to maintain the PANA session, the PAA needs to
   be notified about the change of PaC address.


Based on concerns about the reserved value "0" please make the following
changes:

From:

10.2.1.  Message Type

   The Message Type namespace is used to identify PANA messages.  The
   range of values 0 - 65,519 are for permanent, standard message types,
   allocated by IETF Consensus [IANA].  This document defines the range
   of values 1 - 4.  The same Message Type is used for both the request
   and the answer messages, except for type 1.  The Request bit
   distinguishes requests from answers.  See Section 7 for the
   assignment of the namespace in this specification.

to:

10.2.1.  Message Type

   The Message Type namespace is used to identify PANA messages.
   Message Type 0 is not used and not assigned by IANA.  The
   range of values 1 - 65,519 are for permanent, standard message types,
   allocated by IETF Consensus [IANA].  This document defines the range
   of values 1 - 4.  The same Message Type is used for both the request
   and the answer messages, except for type 1.  The Request bit
   distinguishes requests from answers.  See Section 7 for the
   assignment of the namespace in this specification.


For the same reason, the 2nd paragraph of Section
10.3.1 should be revised from:

   AVP Code 0 is not used.  This document defines the AVP Codes 1-9.
   See Section 8.1 through Section 8.9 for the assignment of the
   namespace in this specification.

to:

   AVP Code 0 is not used and not assigned by IANA.  This document
   defines the AVP Codes 1-9.
   See Section 8.1 through Section 8.9 for the assignment of the
   namespace in this specification.

IANA Note

Please note RFC Editor's note above on allocation of reserved value "0"


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce