Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-18

IANA Last Call comments:

IANA has questions.

In 10.3.1 the document says:

AVP Code 0 is not used.

Does this mean that code 0 cannot be assigned, or only that this code
isn't defined in this document but can be assigned by IANA?


In addition, the actual registry contents aren't fully
declared in the IANA Considerations section nor in the
previous sections. IANA has guessed on the contents of
the registries based on the available information.


Action 1

Upon approval of this document, the IANA will make the following assignments
in the "PORT NUMBERS" registry located at
http://www.iana.org/assignments/port-numbers
sub-registry "WELL KNOWN PORT NUMBERS"

Keyword Decimal Description References
------- ------- ----------- ----------
pana [tbd]/udp PANA Port [RFC-pana-pana-18]


Action 2

Upon approval of this document, the IANA will create the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
Initial contents of this registry will be the following sub-registries.


Action 3

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "Message Types"
Allocation Policy: IETF Consensus
Initial contents of this sub-registry will be:

Value Req/Ans Abbrev Name Reference
----- ------ ------ -------- ---------
0 available for assignment [RFC-pana-pana-18]
1 Req PCI PANA-Client-Initiation [RFC-pana-pana-18]
2 Req PAR PANA-Auth-Request [RFC-pana-pana-18]
2 Ans PAN PANA-Auth-Answer [RFC-pana-pana-18]
3 Req PTR PANA-Termination-Request [RFC-pana-pana-18]
3 Ans PTA PANA-Termination-Answer [RFC-pana-pana-18]
4 Req PNR PANA-Notification-Request [RFC-pana-pana-18]
4 Ans PNA PANA-Notification-Answer [RFC-pana-pana-18]
5-65519 available for assignment [RFC-pana-pana-18]
65520-65535 experimental values [RFC-pana-pana-18]


Action 4

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "Message Flags"
Allocation Policy: Standards Action
Initial contents of this sub-registry will be:

Bit Code Description Reference
--- ---- ----------- ---------
0 R Request [RFC-pana-pana-18]
1 S Start [RFC-pana-pana-18]
2 C Complete [RFC-pana-pana-18]
3 A re-Authentication [RFC-pana-pana-18]
4 P Ping [RFC-pana-pana-18]
5 I IP Reconfiguration [RFC-pana-pana-18]
6-15 available for assignment [RFC-pana-pana-18]


Action 5

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "AVP Codes"
Allocation Policy: Expert Review with Specification Required

IESG NOTE: Expert required

Initial contents of this sub-registry will be:

Code Attribute Name Reference
---- ---------------- ---------
0 ??? [RFC-pana-pana-18]
1 AUTH [RFC-pana-pana-18]
2 EAP-Payload [RFC-pana-pana-18]
3 Integrity-Algorithm [RFC-pana-pana-18]
4 Key-Id [RFC-pana-pana-18]
5 Nonce [RFC-pana-pana-18]
6 PRF-Algorithm [RFC-pana-pana-18]
7 Result-Code [RFC-pana-pana-18]
8 Session-Lifetime [RFC-pana-pana-18]
9 Termination-Cause [RFC-pana-pana-18]
10-65535 Available for assignment [RFC-pana-pana-18]


Action 6

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "AVP Flags"
Allocation Policy: Standards Action
Initial contents of this sub-registry will be:

Bit Code Description Reference
--- ---- ----------- ---------
0 V Vendor [RFC-pana-pana-18]
1-15 Available for Assignment [RFC-pana-pana-18]


Action 7

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "Result-Code AVP Values"
Allocation Policy: IETF Consensus
Initial contents of this sub-registry will be:


Value Meaning Reference
----- ------------- -----------
0 PANA_SUCCESS [RFC-pana-pana-18]
1 PANA_AUTHENTICATION_REJECTED [RFC-pana-pana-18]
2 PANA_AUTHORIZAZTION_REJECTED [RFC-pana-pana-18]
3-4294967295 Available for Assignment [RFC-pana-pana-18]


Action 8

Upon approval of this document, the IANA will in the following
registry "PANA Parameters" located at http://www.iana.org/assignments/TBD
create a new sub-registry "Termination-Cause AVP Values"
Allocation Policy: IETF Consensus
Initial contents of this sub-registry will be:


Value Meaning Reference
----- ------------- -----------
0 Available for Assignment [RFC-pana-pana-18]
1 LOGOUT [RFC-pana-pana-18]
2-3 Available for Assignment [RFC-pana-pana-18]
4 ADMINISTRATIVE [RFC-pana-pana-18]
5-7 Available for Assignment [RFC-pana-pana-18]
8 SESSION_TIMEOUT [RFC-pana-pana-18]
9-4294967295 Available for Assignment [RFC-pana-pana-18]

We understand the above to be the only IANA Actions for this document.

[Ballot comment]
It might be wise to change occurrences of CFWS in the formal ABNF to:
  "[CRLF WSP] *WSP"
In order to avoid whitespace-only blank lines.  While this is not
particularly important for a formal language (as opposed to a machine
parsed language), that may better reflect how it will be used.

[Ballot discuss]
Both documents refer to optionally using SNMP in the case when the server for PANA and per-packet access control entities are separate to carry information between the two entities. As a result implementation of SNMP is a MUST in both entities. The reference [I-D.ietf-pana-snmp] is Normative in the framework document and Informational in the protocol document. However this document is in status Dead.

Not having seen ietf-pana-snmp document I cannot judge to what extent this solution is viable. If the working group still considers the usage of SNMP part of the framework I would like to see the document resuscitated and reviewed by the SNMP experts in order to validate its usage.

IANA Last call Comments:


IANA HAS QUESTIONS.

Upon approval of this document, the IANA will take
the following Actions:


Action 1 (section 10.1):

Upon approval of this document, the IANA will make
the following assignments in the "PORT NUMBERS"
registry located at

http://www.iana.org/assignments/port-numbers

sub-registry "WELL KNOWN PORT NUMBERS"

Keyword Decimal Description References
------- ------- ----------- ----------
pana [tbd]/udp PANA [RFC-pana-pana-15]


Action 2 (General PANA Registry):

[ NOTE: The document never explicitly requests a
registry be created ]

Upon approval of this document, the IANA will
create the following registry "PANA Protocol
Numbers" located at

http://www.iana.org/assignments/TBD

This registry contains the following sub-registries..


Action 3 (section 10.2.1):

[ NOTE: section 10.2 is confusing. it says "two
fields" and then lists "the Version, Message Type,
and Flags fields". Unless my math is wrong, that
would be three. ]

Upon approval of this document, the IANA will
in the following registry "PANA Protocol Numbers"
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "Message Types (version 1)"

Assignment policy: IETF Consensus

Initial contents of this sub-registry will be:

Message Number Description Reference
(16-bits)
-------------- ------------- ---------
1 Client-Initiation [RFC-pana-pana-15]
2 Auth Request/Answer [RFC-pana-pana-15]
3 Termination Request/Answer [RFC-pana-pana-15]
4 Notification Request/Answer [RFC-pana-pana-15]
5-65519 Reserved to IANA [RFC-pana-pana-15]
65520-65535 Reserved for Experimental [RFC-pana-pana-15]
Messages [RFC-pana-pana-15]

[ NOTE: While this section refers back to sections
7.1-7.7, it's unclear what the actual definition of
this registry should be. This document needs to get
its IANA considerations fixed to be more clear. Perhaps
pointing back to section 7? Also, there are multiple
messages defined for each Message Number code.]

Action 4 (section 10.2.3):

Upon approval of this document, the IANA will in
the following registry "PANA Protocol Numbers"
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "Message Flags (version 1)"

Assignment policy: Standards Action

Initial contents of this sub-registry will be:

Flag Bit Code Description Reference
-------- ---- --------------------- ---------
0 R Request [RFC-pana-pana-15]
1 S Start [RFC-pana-pana-15]
2 C Complete [RFC-pana-pana-15]
3 A re-Authentication [RFC-pana-pana-15]
4 P Ping [RFC-pana-pana-15]
5-15 Reserved to IANA [RFC-pana-pana-15]


[ NOTE: this registry did not point back to a
previous section where these flags are defined.
A back-pointer to section 6.1 should be added ]


Action 5 (section 10.3.1):

Upon approval of this document, the IANA will
in the following registry "PANA Protocol Numbers"
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "AVP Codes"

Assignment policy: Designated Expert with
Specification or Standards Action

NOTE: IESG must designate an expert.

Initial contents of this sub-registry will be:

Code Bit Description Reference
-------- --------------------- ---------
0 Reserved [RFC-pana-pana-15]
1 Algorithm [RFC-pana-pana-15]
2 AUTH [RFC-pana-pana-15]
3 EAP-Payload [RFC-pana-pana-15]
4 Key-Id [RFC-pana-pana-15]
5 Nonce [RFC-pana-pana-15]
6 Result-Code [RFC-pana-pana-15]
7 Session-Lifetime [RFC-pana-pana-15]
8 Termination-Cause [RFC-pana-pana-15]
9 ??? [RFC-pana-pana-15]
10 ??? [RFC-pana-pana-15]
11-15 Reserved to IANA [RFC-pana-pana-15]

[ NOTE: Section 10.3.1 specifies codes 1-10,
but refers back to  sections 8.1-8.8 which only
define codes 1-8 ]


Action 6 (section 10.3.2):

Upon approval of this document, the IANA will
in the following registry "PANA Protocol Numbers"
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "AVP Flags"

Assignment policy: Standards Action

Initial contents of this sub-registry will be:

Flag Bit Code Description Reference
-------- ---- --------------------- ---------
0 V Vendor [RFC-pana-pana-15]
1 M Mandatory [RFC-pana-pana-15]
2-15 Reserved to IANA [RFC-pana-pana-15]


Action 7 (section 10.4.1):

Upon approval of this document, the IANA will
in the following registry "PANA Protocol Numbers"
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "Result-Code AVP
Values (AVP Code 6)"

Allocation policy: IETF Consensus

Initial contents of this sub-registry will be:

Value Description Reference
32-bit
----- ------------------ ---------
0 PANA_SUCCESS [RFC-pana-pana-15]
1 PANA_AUTHENTICATION_REJECTED [RFC-pana-pana-15]
2 PANA_AUTHORIZATION_REJECTED [RFC-pana-pana-15]
3 to Reserved to IANA [RFC-pana-pana-15]
2^32


Action 8 (section 10.4.2):

Upon approval of this document, the IANA will
in the following registry "PANA Protocol Numbers"
located at

http://www.iana.org/assignments/TBD

create a new sub-registry "Termination-Cause AVP
Values (AVP Code 8)"

Allocation policy: IETF Consensus

Initial contents of this sub-registry will be:

Value Description Reference
(32-bit)
----- ------------------ ---------
1 LOGOUT [RFC-pana-pana-15]
2-3 Reserved to IANA [RFC-pana-pana-15]
4 ADMINISTRATIVE [RFC-pana-pana-15]
5-7 Reserved to IANA [RFC-pana-pana-15]
8 SESSION_TIMEOUT [RFC-pana-pana-15]
9 to Reserved to IANA [RFC-pana-pana-15]
2^32


Action 9 (section 10.4):

[ Question: The document requests First-come,
First-serve entries into 'registries' for Values
for the other AVP Codes. Should these registries
get created now or on-demand? ]


We understand the above to be the only IANA
Actions for this document.

PROTO Questionairre

Hello Mark,



The PANA WG has completed the WG last call on the following ID:

I-D title: Protocol for Carrying Authentication for Network Access

I-D: draft-ietf-pana-pana-08



We would like to submit the ID for IESG review and IETF last call.

Below is the template that has been used for submissions in the past.



-Basavaraj



================================================================



1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to forward to the IESG

  for publication?



Yes.





2) Has the document had adequate review from both key WG members and

  key non-WG members? Do you have any concerns about the depth or

  breadth of the reviews that have been performed?



Yes. The document has been reviewed extensively by several key WG

members. The chairs have also solicited reviews of the document from

several individuals. We (chairs) are satisified with the depth and

breadth of the reviews.



3) Do you have concerns that the document needs more review from a

  particular (broader) perspective (e.g., security, operational

  complexity, someone familiar with AAA, etc.)?



No. We have attempted to ensure that the reviewers selected had varied

backgrounds and expertise and hence are comfortable that the ID has

had sufficient cross-area exposure.

 

4) Do you have any specific concerns/issues with this document that

  you believe the ADs and/or IESG should be aware of? For example,

  perhaps you are uncomfortable with certain parts of the document,

  or whether there really is a need for it, etc., but at the same

  time these issues have been discussed in the WG and the WG has

  indicated it wishes to advance the document anyway.



No specific concerns with the document.

 

5) How solid is the WG consensus behind this document?  Does it

  represent the strong concurrence of a few individuals, with others

  being silent, or does the WG as a whole understand and agree with

  it?



There is solid WG consensus behind this document. As in all WGs the

number of active individuals who are vocal and have reviewed and

commented on the spec are few. However it should be noted that there

is no dissent w.r.t the spec from any (even in the silent majority).



6) Has anyone threatened an appeal or otherwise indicated extreme

  discontent?  If so, please summarize what are they upset about.



No.

 

7) Have the chairs verified that the document adheres to _all_ of the

  ID nits?  (see http://www.ietf.org/ID-nits.html).



Yes.

 

8) Does the document a) split references into normative/informative,

  and b) are there normative references to IDs, where the IDs are not

  also ready for advancement or are otherwise in an unclear state?

  (Note: the RFC editor will not publish an RFC with normative

  references to IDs, it will delay publication until all such IDs are

  also ready for publication as RFCs.)



References have been split into normative and informative ones.



9) For Standards Track and BCP documents, the IESG approval

  announcement includes a writeup section with the following

  sections:



  - Technical Summary



This document defines the Protocol for Carrying Authentication for

Network Access (PANA), a link-layer agnostic transport for Extensible

Authentication Protocol (EAP) to enable network access authentication

between clients and access networks.  PANA can carry any

authentication method that can be specified as an EAP method, and it

can be used on any link that can carry IP.  PANA protocol

specification covers the client-to-network access authentication part

of an overall secure network access framework.



  - Working Group Summary



The working group has reviewed the document not only at the LC phase

but even earlier as well. The chairs have also solicited reviewers

from varied people with different expertise in the IETF. The draft has

also been discussed at several IETF WG meetings. The documents have

been thoroughly reviewed by multiple IETF members. In addition to

general review, we have also sought and received expert reviews in the

areas including EAP (Jari Arkko, Pasi Eronen), IPsec (Francis Dupont,

Jari Arkko, Tero Kivinen), DSL (Prakash Jayaraman, Randy Turner,

Lionel Morand), AAA (Avi Lior), general (Erik Nordmark).

Several issues identified during the last call were resolved. Currently

there are no outstanding issues on these documents. The issues were tracked

and documented in http://danforsberg.info:8080/pana-issues/



  - Protocol Quality



    - is the protocol already being implemented?

Yes. There are at least 2 known implementations of the protocol. There

are several others being implemented at this time as well. An open

source implementation of pana is available at:

http://www.opendiameter.org/



    - have a significant number of vendors indicated they plan to

      implement the spec?

Not at this time.

 

    - are there any reviewers (during the end stages) that merit

      explicit mention as having done a thorough review that resulted

      in important changes or a conclusion that the document was fine

      (except for maybe some nits?)

We believe that we have acknowledged all such reviewers.



-Chairs

Basavaraj/Alper

AD REVIEW

-------- Original Message --------
Subject: AD review of draft-ietf-pana-pana-10
Date: Sat, 17 Dec 2005 11:49:26 +0100
From: Mark Townsley
To: Basavaraj Patil , Alper Yegin
CC: Margaret Wasserman


Overall, I found the document very thorough and well-done. I still fear
the protocol itself suffers from more complexity than the problem it is
attempting to solve deserves, but the quality of the documentation here
goes a long way to make up for that.

Please see individual comments and questions inline. Forward to
authors/list as you deem appropriate. I will move this to IETF LC as
soon as I receive an updated spec and proto questionairre.

Happy Holidays,

- Mark

>PANA Working Group                                          D. Forsberg
>Internet-Draft                                                    Nokia
>Expires: January 17, 2006                                  Y. Ohba (Ed.)
>                                                                Toshiba
>                                                                B. Patil
>                                                                  Nokia
>                                                          H. Tschofenig
>                                                                Siemens
>                                                                A. Yegin
>                                                                Samsung
>                                                          July 16, 2005
>
>
>    Protocol for Carrying Authentication for Network Access (PANA)
>                        draft-ietf-pana-pana-10
>
>Status of this Memo
>
>  By submitting this Internet-Draft, each author represents that any
>  applicable patent or other IPR claims of which he or she is aware
>  have been or will be disclosed, and any of which he or she becomes
>  aware will be disclosed, in accordance with Section 6 of BCP 79.
>
>  Internet-Drafts are working documents of the Internet Engineering
>  Task Force (IETF), its areas, and its working groups.  Note that
>  other groups may also distribute working documents as Internet-
>  Drafts.
>
>  Internet-Drafts are draft documents valid for a maximum of six months
>  and may be updated, replaced, or obsoleted by other documents at any
>  time.  It is inappropriate to use Internet-Drafts as reference
>  material or to cite them other than as "work in progress."
>
>  The list of current Internet-Drafts can be accessed at
>  http://www.ietf.org/ietf/1id-abstracts.txt.
>
>  The list of Internet-Draft Shadow Directories can be accessed at
>  http://www.ietf.org/shadow.html.
>
>  This Internet-Draft will expire on January 17, 2006.
>
>Copyright Notice
>
>  Copyright (C) The Internet Society (2005).
>
>Abstract
>
>  This document defines the Protocol for Carrying Authentication for
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 1]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  Network Access (PANA), a link-layer agnostic transport for Extensible
>  Authentication Protocol (EAP) to enable network access authentication
>  between clients and access networks.  PANA protocol specification
>  covers the client-to-network access authentication part of an overall
>  secure network access framework, which additionally includes other
>  protocols and mechanisms for service provisioning, access control as
>  a result of initial authentication, and accounting.
>
>Table of Contents
>
>  1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  5
>    1.1  Specification of Requirements  . . . . . . . . . . . . . .  5
>  2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  6
>  3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . .  8
>  4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . .  10
>    4.1  Transport Layer  . . . . . . . . . . . . . . . . . . . . .  10
>    4.2  Payload Encoding . . . . . . . . . . . . . . . . . . . . .  10
>    4.3  Discovery and Handshake Phase  . . . . . . . . . . . . . .  11
>    4.4  Authentication and Authorization Phase . . . . . . . . . .  15
>    4.5  Access Phase . . . . . . . . . . . . . . . . . . . . . . .  18
>    4.6  Re-authentication Phase  . . . . . . . . . . . . . . . . .  18
>    4.7  Termination Phase  . . . . . . . . . . . . . . . . . . . .  20
>    4.8  Separate NAP and ISP Authentication  . . . . . . . . . . .  21
>      4.8.1  Negotiating Separate NAP and ISP Authentication  . . .  21
>      4.8.2  Execution of Separate NAP and ISP Authentication . . .  22
>      4.8.3  AAA-Key Calculation  . . . . . . . . . . . . . . . . .  23
>  5.  Processing Rules . . . . . . . . . . . . . . . . . . . . . .  24
>    5.1  Fragmentation  . . . . . . . . . . . . . . . . . . . . . .  24
>    5.2  Sequence Number and Retransmission . . . . . . . . . . . .  24
>    5.3  PANA Security Association  . . . . . . . . . . . . . . . .  25
>    5.4  Message Authentication Code  . . . . . . . . . . . . . . .  27
>    5.5  Message Validity Check . . . . . . . . . . . . . . . . . .  27
>    5.6  PaC-EP-Master-Key  . . . . . . . . . . . . . . . . . . . .  29
>    5.7  Device ID Choice . . . . . . . . . . . . . . . . . . . . .  29
>    5.8  PaC Updating its IP Address  . . . . . . . . . . . . . . .  30
>    5.9  Session Lifetime . . . . . . . . . . . . . . . . . . . . .  30
>    5.10  Network Selection  . . . . . . . . . . . . . . . . . . .  31
>    5.11  Error Handling . . . . . . . . . . . . . . . . . . . . .  31
>  6.  Header Format  . . . . . . . . . . . . . . . . . . . . . . .  33
>    6.1  IP and UDP Headers . . . . . . . . . . . . . . . . . . . .  33
>    6.2  PANA Header  . . . . . . . . . . . . . . . . . . . . . . .  33
>    6.3  AVP Header . . . . . . . . . . . . . . . . . . . . . . . .  35
>  7.  PANA Messages  . . . . . . . . . . . . . . . . . . . . . . .  39
>    7.1  PANA-PAA-Discover (PDI)  . . . . . . . . . . . . . . . . .  41
>    7.2  PANA-Start-Request (PSR) . . . . . . . . . . . . . . . . .  41
>    7.3  PANA-Start-Answer (PSA)  . . . . . . . . . . . . . . . . .  42
>    7.4  PANA-Auth-Request (PAR)  . . . . . . . . . . . . . . . . .  42
>    7.5  PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . . .  42
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 2]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>    7.6  PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . . .  43
>    7.7  PANA-Reauth-Answer (PRAA)  . . . . . . . . . . . . . . . .  43
>    7.8  PANA-Bind-Request (PBR)  . . . . . . . . . . . . . . . . .  43
>    7.9  PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . . .  44
>    7.10  PANA-Ping-Request (PPR)  . . . . . . . . . . . . . . . .  44
>    7.11  PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . . .  44
>    7.12  PANA-Termination-Request (PTR) . . . . . . . . . . . . .  45
>    7.13  PANA-Termination-Answer (PTA)  . . . . . . . . . . . . .  45
>    7.14  PANA-Error-Request (PER) . . . . . . . . . . . . . . . .  45
>    7.15  PANA-Error-Answer (PEA)  . . . . . . . . . . . . . . . .  46
>    7.16  PANA-FirstAuth-End-Request (PFER)  . . . . . . . . . . .  46
>    7.17  PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . . .  46
>    7.18  PANA-Update-Request (PUR)  . . . . . . . . . . . . . . .  46
>    7.19  PANA-Update-Answer (PUA) . . . . . . . . . . . . . . . .  47
>  8.  AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . .  48
>    8.1  Cookie AVP . . . . . . . . . . . . . . . . . . . . . . . .  50
>    8.2  Device-Id AVP  . . . . . . . . . . . . . . . . . . . . . .  50
>    8.3  EAP-Payload AVP  . . . . . . . . . . . . . . . . . . . . .  51
>    8.4  Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . .  51
>    8.5  ISP-Information AVP  . . . . . . . . . . . . . . . . . . .  51
>    8.6  Key-Id AVP . . . . . . . . . . . . . . . . . . . . . . . .  51
>    8.7  MAC AVP  . . . . . . . . . . . . . . . . . . . . . . . . .  51
>    8.8  NAP-Information AVP  . . . . . . . . . . . . . . . . . . .  52
>    8.9  Nonce AVP  . . . . . . . . . . . . . . . . . . . . . . . .  52
>    8.10  Notification AVP . . . . . . . . . . . . . . . . . . . .  52
>    8.11  Post-PANA-Address-Configuration (PPAC) AVP . . . . . . .  53
>    8.12  Protection-Capability AVP  . . . . . . . . . . . . . . .  54
>    8.13  Provider-Identifier AVP  . . . . . . . . . . . . . . . .  54
>    8.14  Provider-Name AVP  . . . . . . . . . . . . . . . . . . .  54
>    8.15  Result-Code AVP  . . . . . . . . . . . . . . . . . . . .  54
>      8.15.1  Authentication Results Codes . . . . . . . . . . . .  55
>      8.15.2  Protocol Error Result Codes  . . . . . . . . . . . .  55
>    8.16  Session-Id AVP . . . . . . . . . . . . . . . . . . . . .  58
>    8.17  Session-Lifetime AVP . . . . . . . . . . . . . . . . . .  58
>    8.18  Termination-Cause AVP  . . . . . . . . . . . . . . . . .  58
>  9.  Retransmission Timers  . . . . . . . . . . . . . . . . . . .  59
>    9.1  Transmission and Retransmission Parameters . . . . . . . .  60
>  10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  62
>    10.1  PANA UDP Port Number . . . . . . . . . . . . . . . . . .  62
>    10.2  PANA Multicast Address . . . . . . . . . . . . . . . . .  62
>    10.3  PANA Header  . . . . . . . . . . . . . . . . . . . . . .  62
>      10.3.1  Message Type . . . . . . . . . . . . . . . . . . . .  62
>      10.3.2  Flags  . . . . . . . . . . . . . . . . . . . . . . .  63
>    10.4  AVP Header . . . . . . . . . . . . . . . . . . . . . . .  63
>      10.4.1  AVP Code . . . . . . . . . . . . . . . . . . . . . .  63
>      10.4.2  Flags  . . . . . . . . . . . . . . . . . . . . . . .  64
>    10.5  AVP Values . . . . . . . . . . . . . . . . . . . . . . .  64
>      10.5.1  Algorithm Values of MAC AVP  . . . . . . . . . . . .  64
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 3]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>      10.5.2  Post-PANA-Address-Configuration AVP Values . . . . .  64
>      10.5.3  Protection-Capability AVP Values . . . . . . . . . .  64
>      10.5.4  Result-Code AVP Values . . . . . . . . . . . . . . .  64
>      10.5.5  Termination-Cause AVP Values . . . . . . . . . . . .  65
>  11.  Security Considerations  . . . . . . . . . . . . . . . . . .  66
>    11.1  General Security Measures  . . . . . . . . . . . . . . .  66
>    11.2  Discovery  . . . . . . . . . . . . . . . . . . . . . . .  67
>    11.3  EAP Methods  . . . . . . . . . . . . . . . . . . . . . .  68
>    11.4  Separate NAP and ISP Authentication  . . . . . . . . . .  68
>    11.5  Cryptographic Keys . . . . . . . . . . . . . . . . . . .  68
>    11.6  Per-packet Ciphering . . . . . . . . . . . . . . . . . .  69
>    11.7  PAA-to-EP Communication  . . . . . . . . . . . . . . . .  69
>    11.8  Liveness Test  . . . . . . . . . . . . . . . . . . . . .  70
>    11.9  Updating PaC's IP Address  . . . . . . . . . . . . . . .  70
>    11.10  Early Termination of a Session . . . . . . . . . . . . .  70
>  12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  71
>  13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  72
>    13.1  Normative References . . . . . . . . . . . . . . . . . .  72
>    13.2  Informative References . . . . . . . . . . . . . . . . .  72
>        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  74
>  A.  Example Sequence of Separate NAP and ISP Authentication  . .  76
>        Intellectual Property and Copyright Statements . . . . . . .  78
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 4]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>1.  Introduction
>
>  Providing secure network access service requires access control based
>  on the authentication and authorization of the clients and the access
>  networks.  Client-to-network authentication provides parameters that
>  are needed to police the traffic flow through the enforcement points.
>  A protocol is needed to carry authentication methods between the
>  client and the access network.
>
>  Currently there is no standard network-layer solution for
>  authenticating clients for network access.  Appendix A of [RFC4058]
>  describes the problem statement that led to the development of PANA.
>
>  Scope of this work is identified as designing a link-layer agnostic
>  transport for network access authentication methods.  The Extensible
>  Authentication Protocol (EAP) [RFC3748] provides such authentication
>  methods.  In other words, PANA will carry EAP which can carry various
>  authentication methods.  By the virtue of enabling transport of EAP
>  above IP, any authentication method that can be carried as an EAP
>  method is made available to PANA and hence to any link-layer
>  technology. 
>
This is not entirely true. EAP may be *transported* over any link-layer
for which IP is defined via PANA, however, there are still a number of
linkages between EAP and the link-layer (reaching around the "PANA
layer"). Some are referred to later in this document (A MAC Address
Device ID, PANA session lifetime triggered by the lower layer, etc).

>There is a clear division of labor between PANA (an EAP
>  lower layer), EAP and EAP methods as described in [RFC3748].
> 
>
This is not true either, Section 5.10 on Network Selection is a clear
case where the line between EAP and PANA is muddy indeed.

Let's be a bit more honest in the Introduction. PANA offers a common
transport for EAP over various link-layers, but it does not shield the
link-layer from defining a number of things in order to work with PANA/EAP.

>  Various environments and usage models for PANA are identified in
>  Appendix A of [RFC4058].  Potential security threats for network-
>  layer access authentication protocol are discussed in [RFC4016].
>  These have been essential in defining the requirements [RFC4058] on
>  the PANA protocol.  Note that some of these requirements are imposed
>  by the chosen payload, EAP [RFC3748].
>
>  There are components that are part of a complete secure network
>  access solution but are outside of the PANA protocol specification,
>  including IP address configuration, authentication method choice,
>  filter rule installation, data traffic protection and PAA-EP
>  protocol.  These components are described in separate documents (see
>  [I-D.ietf-pana-framework] and [I-D.ietf-pana-snmp]).  The readers are
>  recommended to go through the PANA Framework document [I-D.ietf-pana-
>  framework] prior to reading this protocol specification document.
>
>1.1  Specification of Requirements
>
>  In this document, several words are used to signify the requirements
>  of the specification.  These words are often capitalized.  The key
>  words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
>  "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
>  are to be interpreted as described in [RFC2119].
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 5]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>2.  Terminology
>
>  PANA Client (PaC):
>
>      The client side of the protocol that resides in the access device
>      (e.g., laptop, PDA, etc.).  It is responsible for providing the
>      credentials in order to prove its identity (authentication) for
>      network access authorization.  The PaC and the EAP peer are co-
>      located in the same access device.
>
>  PANA Authentication Agent (PAA):
>
>      The protocol entity in the access network whose responsibility is
>      to verify the credentials provided by a PANA client (PaC) and
>      authorize network access to the device associated with the client
>      and identified by a Device Identifier (DI).  The PAA and the EAP
>      authenticator (and optionally the EAP server) are co-located in
>      the same node.  Note the authentication and authorization
>      procedure can, according to the EAP model, be also offloaded to
>      the backend AAA infrastructure.
>
>  PANA Session:
>
>      A PANA session begins with the handshake between the PANA Client
>      (PaC) and the PANA Authentication Agent (PAA), and terminates as a
>      result of an authentication or liveness test failure, a message
>      delivery failure after retransmissions reach maximum values,
>      session lifetime expiration, or an explicit termination message.
>      A fixed session identifier is maintained throughout a session.  A
>      session cannot be shared across multiple network interfaces.  Only
>      one device identifier of the PaC is allowed to be bound to a PANA
>      session for simplicity.
>
>  Session Lifetime:
>
>      A duration that is associated with a PANA session.  For an
>      established PANA session, the session lifetime is bound to the
>      lifetime of the current authorization given to the PaC.  The
>      session lifetime can be updated by a new round of EAP
>      authentication before it expires.
>
>  Session Identifier:
>
>      This identifier is used to uniquely identify a PANA session on the
>      PAA and PaC.  It includes an identifier of the PAA, therefore it
>      cannot be shared across multiple PAAs.  It is included in PANA
>      messages to bind the message to a specific PANA session.  This
>      bidirectional identifier is allocated by the PAA following the
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 6]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>      handshake and freed when the session terminates.
>
>  PANA Security Association (PANA SA):
>
>      A PANA security association is formed between the PaC and the PAA
>      by sharing cryptographic keying material and associated context.
>      The formed duplex security association is used to protect the
>      bidirectional PANA signaling traffic between the PaC and the PAA.
>
>  Device Identifier (DI):
>
>      The identifier used by the network as a handle to control and
>      police the network access of a device.  Depending on the access
>      technology, this identifier may contain an address that is carried
>      in protocol headers (e.g., IP or link-layer address), or a locally
>      significant identifier that is made available by the local
>      protocol stack (e.g., circuit id, PPP interface id) of a connected
>      device.
>
>  Enforcement Point (EP):
>
>      A node on the access network where per-packet enforcement policies
>      (i.e., filters) are applied on the inbound and outbound traffic of
>      access devices.  Information such as the DI and (optionally)
>      cryptographic keys are provided by the PAA per client for
>      generating filters on the EP.  The EP and PAA may be co-located.
>
>  Network Access Provider (NAP):
>
>      A service provider that provides physical and link-layer
>      connectivity to an access network it manages.
>
>  AAA-Key:
>
>      A key derived by the EAP peer and EAP server and transported to
>      the authenticator [I-D.ietf-eap-keying].
>
>  For additional terminology definitions see the PANA framework
>  document [I-D.ietf-pana-framework].
>
>
>
>
>
>
>
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 7]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>3.  Protocol Overview
>
>  The PANA protocol is run between a client (PaC) and a server (PAA) in
>  order to perform authentication and authorization for the network
>  access service.
>
>  The protocol messaging consists of a series of request and responses,
>  some of which may be initiated by either ends.
>
s/ends/end

> Each message can
>  carry zero or more AVPs as payload.
>
s/as/within the

> The main payload of PANA is EAP
>  which performs authentication.  PANA helps the PaC and PAA establish
>  an EAP session.
>
>  PANA is a UDP-based protocol.  It has its own retransmission
>  mechanism to reliably deliver messages.
>
>  PANA messages are sent between the PaC and PAA as part of a PANA
>  session.  A PANA session consists of distinct phases:
>
>  o  Discovery and handshake phase: This is the phase that initiates a
>      new PANA session.  The PaC discovers the PAA(s) by either
>      explicitly soliciting advertisements for them or receiving
>      unsolicited advertisements.  The PaC's answer sent in response to
>      an advertisement starts a new session.
>
>  o  Authentication and authorization phase: Immediately following the
>      discovery and handshake phase is the EAP execution between the PAA
>      and PaC.  The EAP payload (which carry an EAP method inside) is
>      what is used for authentication.  The PAA conveys the result of
>      authentication and authorization to the PaC at the end of this
>      phase.  This phase may involve execution of two EAP sessions back-
>      to-back, one for the NAP and one for the ISP.
>
>  o  Access phase: After a successful authentication and authorization
>      the host gains access to the network and can send and receive IP
>      data traffic through the EP(s).  At any time during this phase,
>      the PaC and PAA may optionally ping each other to test liveness of
>      the PANA session on each end.
> 
>
So, is this a requirement that the PaC and PAA allow ICMP before the
authentication is complete?

>  o  Re-authentication phase: During the access phase, the PAA must
>      initiate re-authentication before the PANA session lifetime
>      expires.  EAP is carried by PANA to perform authentication.  This
>      phase may be optionally triggered by both the PaC and the PAA
>      without any respect to the session lifetime.  The session moves to
>      this phase from the access phase, and returns back there upon
>      successful re-authentication.
>
>  o  Termination phase: The PaC or PAA may choose to discontinue the
>      access service at any time.  An explicit disconnect message can be
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 8]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>      sent by either end.  If either the PaC or the PAA disconnects
>      without engaging in termination messaging, it is expected that
>      either the expiration of a finite session lifetime or failed
>      liveness tests would clean up the session at the other end.
>
>
>    PaC  PAA    Message
>  -----------------------------------------------------
>  // Discovery and handshake phase
>      ----->    PANA-PAA-Discover
>      <-----    PANA-Start-Request
>      ----->    PANA-Start-Answer
>
>  // Authentication and authorization phase
>      <-----    PANA-Auth-Request /* EAP Request */
>      ----->    PANA-Auth-Answer
>      ----->    PANA-Auth-Request /* EAP Response */
>      <-----    PANA-Auth-Answer
>      <-----    PANA-Bind-Request /* EAP Success */
>      ----->    PANA-Bind-Answer
>
>  // Access phase (IP data traffic allowed)
>      <-----    PANA-Ping-Request
>      ----->    PANA-Ping-Answer
> 
>
OK, I just learned that PANA has its own ping. If you were referring to
PANA-ping earlier, please specify, I obviously thought this was ICMP
echo request/reply.

>  // Termination phase
>      ----->    PANA-Termination-Request
>      <-----    PANA-Termination-Answer
>
>          Figure 1: Illustration of PANA messages in a session
>
>  Note that depending on the environment and deployment the protocol
>  flow depicted in Figure 1 can be abbreviated.
> 
>
How?

(e.g., ...can be abbreviated by collapsing some messages into one as
described later in section foo...)

>  Cryptographic protection of messages between the PaC and PAA is
>  possible as soon as EAP in conjunction with the EAP method exports a
>  shared key.  That shared key is used to create a PANA SA.  The PANA
>  SA helps generating
>
s/generating/generate

>per-message authentication codes that provide
>  integrity protection and authentication.
>
>  Throughout the lifetime of a session, various problems found with the
>  incoming messages can generate a PANA error message sent in response.
>
>
>
>
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006                [Page 9]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>4.  Protocol Details
>
>  The following sections explain in detail the various phases of a PANA
>  session.
>
>4.1  Transport Layer
>
>  PANA uses UDP as its transport layer protocol.  The UDP port number
>  is To Be Assigned by IANA.  All messages except for PANA-PAA-Discover
>  are always unicast.  The PANA-PAA-Discover message MAY be unicast
>  when the PaC knows the IP address of the PAA.
>
>4.2  Payload Encoding
>
>  The payload of any PANA message consists of zero or more AVPs
>  (Attribute Value Pairs).  The subsequent sections refer to these
>  AVPs, therefore the list of AVPs are provided with a brief
>  description before more extensive descriptions are included later in
>  the document.
> 
>
Please give the forward reference to the proper section here.

>  o  Cookie AVP: contains a random value that is generated by the PAA
>      and used for making PAA discovery robust against blind resource
>      consumption DoS attacks.
> 
>
This should be "cryptographically random" to be of value for blind
attacks. A normative reference to RFC 4086 should be included here.

>  o  Protection-Capability AVP: contains the type of per-packet
>      protection (link-layer vs. network-layer) when a cryptographic
>      mechanism should be enabled after PANA authentication.
>
>  o  Device-Id AVP: contains a device identifier (link-layer address or
>      an IP address) of the PaC or an EP.
>
>  o  EAP AVP: contains an EAP PDU.
>
>  o  MAC AVP: contains a Message Authentication Code that integrity
>      protects the PANA message.
> 
>
Pretty confusing to have link layer addresses being important in this
document, and redefining MAC to mean something other than an ethernet
MAC address.

>  o  Termination-Cause AVP: contains the reason of session termination.
>
>  o  Result-Code AVP: contains information about the protocol execution
>      results.
>
>  o  Session-Id AVP: contains the PANA session identifier value.
>
>  o  Session-Lifetime AVP: contains the duration of authorized access.
>
>  o  Failed-AVP: contains an offending AVP that caused a failure.
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 10]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  o  Provider-Identifier AVP: contains the identifier of a NAP or an
>      ISP.
>
>  o  Provider-Name AVP: contains a name of a NAP or an ISP.
>
>  o  NAP-Information AVP, ISP-Information AVP: contains the identifier
>      of a NAP and an ISP, respectively.
>
>  o  Key-Id AVP: contains a AAA-Key identifier.
>
>  o  PPAC AVP: Post-PANA-Address-Configuration AVP.  Used to indicate
>      the available/chosen IP address configuration methods that can be
>      used by the PaC after successful PANA authentication.
>
>  o  Nonce AVP: contains a randomly chosen value that is used in
>      cryptographic key computations.
> 
>
Ref to 4086 again.

>  o  Notification AVP: contains a displayable message.
> 
>


>
>4.3  Discovery and Handshake Phase
>
>  When a PaC attaches to a network, and it does not already know the IP
>  address of the PAA, it MUST rely on dynamic discovery methods, such
>  as a multicast-based and a traffic-driven discovery.
> 
>
For clarity, I would create subtitles for each of the methods below, and
state above that the multicast method MUST be implemented, and that the
other MAY (I believe that is what I read below as the basic guideline here).

>  The PaCs and PAAs MUST implement multicast-based discovery where the
>  PaC sends a PANA-PAA-Discover message to a well-known
>  administratively scoped multicast address (To Be Assigned by IANA)
>  and UDP port (To Be Assigned by IANA).
>
>  The network administrator MUST configure the multicast scope such
>  that the discovery messages can reach only the designated PAA(s).  In
>  case the PAA(s) is on the same link as the PaC, the administratively
>  scoped multicast messages MUST not be forwarded by the routers.
>  Details of scope configuration are discussed in [RFC2365].
>
>  The PAA(s) that receive the discovery message MUST respond with a
>  unicast PANA-Start-Request message sent to the soliciting PaC.
>
>  Alternatively, the PaC MAY also choose to start sending data packets
>  before getting authenticated.  The EP in an access network that
>  implements PANA SHOULD drop such unauthorized packets upon receipt.
>  Additionally, the EP MAY also take this traffic as an indication of
>  unauthorized PaC and notify the PAA.  The EP-to-PAA notification
>  SHOULD be sent via [I-D.ietf-pana-snmp].  In response, the PAA SHOULD
>  send an unsolicited PANA-Start-Request message to the PaC.  This is
>  called traffic-driven PAA discovery (an alternative to the PaC
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 11]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  explicitly soliciting for a PAA).  Deployment of this alternate
>  scheme is optional.
>
>  The EP-to-PAA notification MAY also be generated in response to
>  receiving a link-up event notification on the EP [I-D.ietf-dna-link-
>  information].
>
>  Alternative PAA discovery schemes may be designed (e.g., DHCP-based)
>  but they are outside the scope of this specification.
>
>  If the PaC knows the IP address of the PAA, it can send a unicast
>  PANA-PAA-Discover message and initiate the PANA exchange.
> 
>
Might want to mention this first. It basically says to me, "if you know
the address you may skip this section" - something that I would rather
know sooner than later.

>  When the PaC receives a PANA-Start-Request message from a PAA, it
>  responds with a PANA-Start-Answer message if it wishes to enter the
>  authentication and authorization phase.
>
>  There can be multiple PAAs in the access network and the PaC may
>  receive multiple PANA-Start-Request messages from those PAAs.  The
>  authentication and authorization result does not depend on which PAA
>  is chosen by the PaC.  By default the PaC MAY choose the PAA that
>  sent the first PANA-Start-Request message.
>
>  A PANA-Start-Request message MAY carry a Cookie AVP that contains a
>  random value generated by the PAA.  The random value is referred to
>  as a cookie.  The cookie is used for preventing the PAA from resource
>  consumption DoS attacks by blind attackers which bombard the PAA with
>  PANA-PAA-Discover messages.  By relying on a cookie mechanism the PAA
>  can avoid per-PaC state creation until after the PaC can produce the
>  same cookie in its PANA-Start-Answer message.
>
But the PAA-Discover still must be processed, so it should be rate-limited.

> In order to do that,
>  the cookie MUST be computed in such a way that it does not require
>  any per-session state maintenance on the PAA in order to verify the
>  cookie returned in the PANA-Start-Answer message.  The PAA discovery
>  that takes advantage of cookies is called "stateless PAA discovery".
>  The exact algorithms and syntax used by the PAA to generate cookies
>  does not affect interoperability and hence is not specified here.  An
>  example algorithm is described below.
>
>      Cookie =
>        | HMAC_SHA1(  ,  )
>
>  where  is a randomly generated secret known only to the PAA,
>    is an index used for choosing the secret for
>  generating the cookie and '|' indicates concatenation.  The secret-
>  version should be changed frequently enough to prevent replay
>  attacks.  The secret key is valid for a certain time frame.  The
>  device identifier of the PaC can be extracted from a link-layer or IP
>  header of PANA messages.
> 
>
Why even suggest this? You may simply point to RFC4086 for ways to
obtain a cryptographically random number.

>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 12]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  When the PaC sends a PANA-Start-Answer message in response to a PANA-
>  Start-Request containing a Cookie AVP, the answer MUST contain a
>  Cookie AVP with the cookie value copied from the request.
>
> 
>

>  When the PAA receives the PANA-Start-Answer message from the PaC, it
>  verifies the cookie.  The cookie is considered as valid if the
>  received cookie has the expected value.  If the computed cookie is
>  valid, the protocol enters the authentication and authorization
>  phase.  Otherwise, it MUST silently discard the received message.
> 
>
The first time I read this, coupled with the suggested algorithm using a
shared secret, I thought that you were saying the cookie was to be
calculated in advance and compared when received (by the
PANA-Start-Request). Upon closer examination, I see you are only
verifying a cookie that is echoed back. This is fine, but please make
the text more clear. Elimating the algorithm for cookie calculation
might be one way to help here (it is very tempting to believe that this
is the way one MUST calculate the cookie, and try to verify that a
received cookie matches this computation rather than simply the echo of
a cookie sent earlier).

>  The initial EAP Request message MAY be optionally carried by the
>  PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
>  message in order to reduce the number of round-trips.  This
>  optimization SHOULD NOT be used if the PAA discovery is desired to be
>  stateless since transmission of an EAP Request message creates a
>  state at EAP layer.  See [I-D.ietf-eap-statemachine] for more
>  information on the EAP state machine and the allocation of state
>  information in the respective protocol steps.
> 
>
I am worried about this kind of complexity (here and elsewhere within PANA).

Since the stateless mechanism is not the MUST to implement, could you
not strike it completely and collapse EAP support only the case with
fewer messages?

It's not that I prefer the case of fewer messages or more messages, just
that I worry about the added complexity of handling both.

I also understand that what I am suggesting is a fundamental change to
something that has been worked on for a long time, so I won't force the
issue, nor pretend to understand all of the ramifications against
whatever deployment requirements you have. Consider this friendly advice
that I can see PANA might be suffering from too many options and the
complexity associated with that. If you can chop out a few alternatives,
the end result might have less functionality but still be better overall
(less is more!).

>  A Protection-Capability AVP and a Post-PANA-Address-Configuration
>  (PPAC) AVP MAY be included in the PANA-Start-Request in order to
>  indicate required and available capabilities for the network access.
>  These AVPs MAY be used by the PaC for assessing the capability match
>  even before the authentication takes place.  Since these AVPs are
>  provided during the insecure discovery and handshake phase, there are
>  certain security risks involved in using the provided information.
>  See Section 11 for further discussion on this.
>
>  If the initial EAP Request message is carried in the PANA-Start-
>  Request message, an EAP Response message MUST be carried in the PANA-
>  Start-Answer message returned to the PAA.
>
>  The PANA-Start-Request/Answer exchange is needed before entering the
>  authentication and authorization phase even when the PaC is pre-
>  configured with the IP address of the PAA and the PANA-PAA-Discover
>  message is unicast.
>
>  A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA-
>  Auth-Answer messages in the authentication and authorization phase
>  when stateless PAA discovery is used, and in PANA-Start-Request and
>  PANA-Start-Answer messages in this phase otherwise.
>
>  A PANA-Start-Request message in stateless PAA discovery MUST NOT be
>  retransmitted as this voids the statelessness on the PAA.  Instead,
>  the PaC MUST retransmit the PANA-PAA-Discover message until it
>  receives a PANA-Start-Request message, and retransmit the PANA-Start-
>  Answer message until it receives a PANA-Auth-Request message.  The
>  PaC can determine whether the PAA is using stateless PAA discovery by
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 13]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  the presence of Cookie AVP.
>
I may have missed it, but this is the first time I have seen presence of
the Cookie equating to stateless discovery. I don't see a MUST for the
cookie if stateless discovery is being performed.

> The PANA-Start-Request message MUST be
>  retransmitted instead of the PANA-Start-Answer message when stateless
>  PAA discovery is not used.
>
>  It is possible that both the PAA and the PaC initiate the discovery
>  and handshake procedure at the same time, i.e., the PAA sends a PANA-
>  Start-Request message while the PaC sends a PANA-PAA-Discover
>  message.  To resolve the race condition, the PAA SHOULD silently
>  discard the PANA-PAA-Discover message received from the PaC after it
>  has sent a PANA-Start-Request message with creating a state (i.e., no
>  Cookie AVP is included in the message) for the PaC.  In this case the
>  PAA will retransmit the PANA-Start-Request message based on a timer,
>  if the PaC doesn't respond in time (the message was lost for
>  example).  If the PAA had sent a PANA-Start-Request message without
>  creating a state for the PaC (i.e., a Cookie AVP was included in the
>  message), then it SHOULD answer to the PANA-PAA-Discover message.
>
> 
>
It seems to me that an explicit AVP, or even a different set of message
types, for stateful vs. stateless would be more explicit, and be a lot
easier to debug than piggybacking on the Cookie AVP to determine which
mode you were operating in.

>  Figure 2 shows an example sequence for the discovery and handshake
>  phase when a PANA-PAA-Discover message is sent by the PaC.  Figure 3
>  shows an example sequence for the discovery and handshake phase with
>  traffic-driven PAA discovery.
>
>      PaC      PAA        Message(sequence number)[AVPs]
>      ------------------------------------------------------
>        ----->            PANA-PAA-Discover(0)
>        <-----            PANA-Start-Request(x)[Cookie]
>        ----->            PANA-Start-Answer(x)[Cookie]
>                          (continued to the authentication and
>                            authorization phase)
>
>  Figure 2: Example sequence for the discovery and handshake phase when
>                  PANA-PAA-Discover is sent by the PaC
>
>
>      PaC  EP      PAA    Message(sequence number)[AVPs]
>      ------------------------------------------------------
>      ---->o              (Data packet arrival or L2 trigger)
>            ------>      PAA-to-EP protocol, or another mechanism
>      <------------      PANA-Start-Request(x)[Cookie]
>      ------------>      PANA-Start-Answer(x)[Cookie]
>                          (continued to the authentication and
>                            authorization phase)
>
>  Figure 3: Example sequence for the discovery and handshake phase with
>                      traffic-driven PAA discovery
>
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 14]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>4.4  Authentication and Authorization Phase
>
>  The main task of the authentication and authorization phase is to
>  carry EAP messages between the PaC and the PAA.  EAP Request and
>  Response messages are carried in PANA-Auth-Request messages.  PANA-
>  Auth-Answer messages are simply used to acknowledge receipt of the
>  requests.  As an optimization, a PANA-Auth-Answer message MAY include
>  the EAP Response message.  This optimization MAY not be used when it
> 
>
>  takes time to generate the EAP Response message (due to, e.g.,
>  intervention of human input), in which case returning an EAP-Auth-
>  Answer message without piggybacking an EAP Response message can avoid
>  unnecessary retransmission of the PANA-Auth-Request message.  Another
>  optimization allows optionally carrying the first EAP Request/
>  Response message in PANA-Start-Request/Answer message as described in
>  Section 4.3.
>
>  When stateless PAA discovery was performed in the discovery and
>  handshake phase, a Nonce AVP MUST be included in the first PANA-Auth-
>  Request and PANA-Auth-Answer messages.
>
>  PANA allows execution of two separate authentication methods, one
>  with NAP and one with ISP under the same PANA session.  This optional
>  feature may be offered by the PAA and accepted by the PaC.  When
>  performed separately, the result of the first EAP authentication is
>  signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer
>  message exchange which delineates the first method execution from the
>  next.  See Section 4.8 for a detailed discussion on separate NAP and
>  ISP authentication.
>
>  The result of PANA authentication is carried in a PANA-Bind-Request
>  message sent from the PAA to the PaC.  This message carries the final
>  EAP authentication result (whether it is the second EAP
>  authentication result of NAP and ISP separate authentication, or the
>  sole EAP authentication result) and the result of PANA
>  authentication.  The PANA-Bind-Request message MUST be acknowledged
>  with a PANA-Bind-Answer (PBA) message.  Figure 4 shows an example
>  sequence in the authentication and authorization phase (no separate
>  authentication).
>
>
>
>
>
>
>
>
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 15]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  PaC      PAA  Message(sequence number)[AVPs]
>  --------------------------------------------------------------------
>                (continued from the discovery and handshake phase)
>      <-----    PANA-Auth-Request(x+1)
>                    [Session-Id, Nonce, EAP{Request}]
>      ----->    PANA-Auth-Answer(x+1) // No piggybacking EAP Response
>                    [Session-Id, Nonce]
>      ----->    PANA-Auth-Request(y)
>                    [Session-Id, EAP{Response}]
>      <-----    PANA-Auth-Answer(y)
>                    [Session-Id]
>      <-----    PANA-Auth-Request(x+2)
>                    [Session-Id, EAP{Request}]
>      ----->    PANA-Auth-Answer(x+2) // Piggybacking EAP Response
>                    [Session-Id, EAP{Response}]
>      <-----    PANA-Bind-Request(x+3)
>                    [Session-Id, Result-Code, EAP{Success}, Device-Id,
>                    Key-Id, Lifetime, Protection-Cap., PPAC, MAC]
>      ----->    PANA-Bind-Answer(x+3)
>                    [Session-Id, Device-Id, Key-Id, PPAC, MAC]
>
>    Figure 4: Example sequence for the authentication and authorization
>                                  phase
>
>  When an EAP method that is capable of deriving keys is used during
>  the authentication and authorization phase and the keys are
>  successfully derived, the PANA message that carries the EAP Success
>  message (i.e., a PANA-FirstAuth-End-Request or a PANA-Bind-Request
>  message) and any subsequent message MUST contain a MAC AVP.
>
>  The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
>  also used for binding device identifiers of the PaC and EP(s) to the
>  PANA SA.  To achieve this, if a Protection-Capability AVP is included
>  in the PANA-Bind-Request message, the message MUST contain the device
>  identifier in a Device-Id AVP for each EP.  Otherwise, if a
>  Protection-Capability AVP is not included in the PANA-Bind-Request
>  message, the message MUST contain the device identifier in a
>  Device-Id AVP for each EP when a link-layer or IP address is used as
>  the device identifier of the PaC.  The PANA-Bind-Answer message MUST
>  contain the PaC's device identifier in a Device-Id AVP when it is
>  already presented with that of EP(s) in the request with using the
>  same type of device identifier as contained in the request.  If the
>  PANA-Bind-Answer message sent from the PaC does not contain a
>  Device-Id AVP with the same device identifier type contained in the
>  request, the PAA sends a PANA-Error-Request message with a
>  PANA_MISSING_AVP result code, and wait for a PANA-Error-Answer
>  message to terminate the session.  The PANA-Bind-Request message with
>  a PANA_SUCCESS result code MUST also contain a Protection-Capability
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 16]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  AVP if link-layer or network-layer ciphering is enabled after the
>  authentication and authorization phase.  The PANA-Bind-Request
>  message MAY also contain a Protection-Capability AVP to indicate if
>  link-layer or network-layer ciphering should be enabled after the
>  authentication and authorization phase.  No link-layer or network-
>  layer specific information is included in the Protection-Capability
>  AVP.  It is assumed that the PAA is aware of the security
>  capabilities of the access network.  The PANA protocol does not
>  specify how the PANA SA and the Protection-Capability AVP will be
>  used to provide per-packet protection for data traffic.  When the PaC
>  does not support the protection capability indicated in the
>  Protection-Capability AVP, the PaC MUST send a PANA-Error-Request
>  message with a PANA_PROTECTION_CAPABILITY_UNSUPPORTED result code and
>  terminate the PANA session.
> 
>
The above paragraph is really at least 2, if not 3, paragraphs.

>  Additionally, the PANA-Bind-Request message with a PANA_SUCCESS
>  result code MUST include a Post-PANA-Address-Configuration (PPAC)
>  AVP, which helps the PAA to inform the PaC about whether a new IP
>  address MUST be configured and the available methods to do so.  In
>  this case, the PaC MUST include a PPAC AVP in the PANA-Bind-Answer
>  message in order to indicate its choice of method when there is a
>  match between the methods offered by the PAA and the methods
>  available on the PaC.  When there is no match, the PaC MUST send a
>  PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED
>  result code and terminate the PANA session.
>
>  EAP authentication can fail at a pass-through authenticator without
>  sending an EAP Failure message [I-D.ietf-eap-statemachine].  When
>  this occurs, the PAA SHOULD send a PANA-Error-Request message to the
>  PaC with using PANA_UNABLE_TO_COMPLY result code.  The PaC SHOULD not
>  change its state unless the error message is secured by PANA or
>  lower-layer.  In any case, a more appropriate way is to rely on a
>  timeout on the PaC.
> 
>
SHOULD or MUST is pretty important for the above, I think.

I assume the timeout referred to here is defined somewhere in this document?

>  There is a case where EAP authentication succeeds with producing an
>  EAP Success message but network access authorization fails due to,
>  e.g., authorization rejected by a AAA or authorization locally
>  rejected by the PAA.  When this occurs, the PAA MUST send a PANA-
>  Bind-Request with a result code PANA_AUTHORIZATION_REJECTED.  If a
>  AAA-Key is established between the PaC and the PAA by the time when
>  the EAP Success message is generated by the EAP server (this is the
>  case when the EAP method provides protected success indication), the
>  PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected
>  with a MAC AVP and carry a Key-Id AVP.  The AAA-Key and the PANA
>  session MUST be deleted immediately after the PANA-Bind message
>  exchange.
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 17]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>4.5  Access Phase
>
>  Once the authentication and authorization phase or the re-
>  authentication phase successfully completes, the PaC gains access to
>  the network and can send and receive IP data traffic through the
>  EP(s) and the PANA session enters the access phase.  In this phase,
>  PANA-Ping-Request and PANA-Ping-Answer messages can be used for
>  testing the liveness of the PANA session on the PANA peer.  Both the
>  PaC and the PAA are allowed to send a PANA-Ping-Request message to
>  the communicating peer whenever they need to make sure the
>  availability of the session on the peer and expect the peer to return
>  a PANA-Ping-Answer message.  Both PANA-Ping-Request and PANA-Ping-
>  Answer messages MUST be protected with a MAC AVP when a PANA SA is
>  available.
>
>  Implementations MUST limit the rate of performing this test.  The PaC
>  and the PAA can handle rate limitation on their own, they do not have
>  to perform any coordination with each other.  There is no negotiation
>  of timers for this purpose.
> 
>
How about rate limitation on responding to a PING request? Is that allowed?

>  Figure 5 and Figure 6 show liveness tests as they are initiated by
>  the PaC and the PAA respectively.
>
>  PaC      PAA    Message(sequence number)[AVPs]
>  ------------------------------------------------------
>      ----->        PANA-Ping-Request(q)[Session-Id, MAC]
>      <-----        PANA-Ping-Answer(q)[Session-Id, MAC]
>
>
>        Figure 5: Example sequence for PaC-initiated liveness test
>
>
>  PaC      PAA    Message(sequence number)[AVPs]
>  ------------------------------------------------------
>      <-----        PANA-Ping-Request(p)[Session-Id, MAC]
>      ----->        PANA-Ping-Answer(p)[Session-Id, MAC]
>
>        Figure 6: Example sequence for PAA-initiated liveness test
> 
>
I assume ping requests can overlap answers, with the sequence number
being used to match up requests with answers?

What are the ramifications of an unanswered ping request? Is it
retransmitted? Is the sequence number listed here part of the same
number space as other PANA messages (I would suggest it NOT being a part
of the same number space)?

>
>4.6  Re-authentication Phase
>
>  The PANA session in the access phase can enter the re-authentication
>  phase to extend the current session lifetime by re-executing EAP.
>  Once the re-authentication phase successfully completes, the session
>  re-enters the access phase.  Otherwise, the session is deleted.
>
>  When the PaC wants to initiate re-authentication, it sends a PANA-
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 18]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  Reauth-Request message to the PAA.  This message MUST contain a
>  Session-Id AVP which is used for identifying the PANA session on the
>  PAA.  If the PAA already has an established PANA session for the PaC
>  with the matching session identifier, it MUST first respond with a
>  PANA-Reauth-Answer message, followed by a PANA-Auth-Request that
>  starts a new EAP authentication.  If the PAA cannot identify the
>  session, it MAY respond with a PANA-Error-Request message with a
>  result code PANA_UNKNOWN_SESSION_ID.  Transmission of this error
>  request is made optional in case this behavior is leveraged for a DoS
>  attack on the PAA.
>
>  The PaC may receive a PANA-Auth-Request before receiving the answer
>  to its outstanding PANA-Reauth-Request.  This condition can arise due
>  to packet re-ordering or a race condition between the PaC and PAA
>  when they both attempt to engage in re-authentication.  The PaC MUST
>  keep discarding the received PANA-Auth-Requests until it receives the
>  answer to its request.
>
>  When the PAA initiates re-authentication, it sends a PANA-Auth-
>  Request message containing the session identifier for the PaC to
>  enter the re-authentication phase.  The PAA SHOULD initiate EAP re-
>  authentication before the current session lifetime expires.
>
>  Re-authentication of an on-going PANA session MUST maintain the
>  existing sequence numbers.
>
>  For any re-authentication, if there is an established PANA SA, PANA-
>  Auth-Request and PANA-Auth-Answer messages MUST be protected by
>  adding a MAC AVP to each message.  Any subsequent EAP authentication
>  MUST be performed with the same ISP and NAP that was selected during
>  the discovery and handshake phase.  The value of the S-flag of the
> 
>
Here is an example where this document is difficult to read due from
start to finish due to forward references. "S-flag" just showed up here,
the sequential reader (me) hasn't a clue what an S-flag is. In a
separate window, I can search and see that it is mentioned many times,
finally on page 34, I get a definition.

So, in general, please provide more forward references for the reader
when a key term is first used.

>  PANA messages exchanged in the re-authentication phase MUST be
>  inherited from the previous authentication and authorization phase or
>  re-authentication phase.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 19]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  PaC      PAA  Message(sequence number)[AVPs]
>  ------------------------------------------------------
>      ----->    PANA-Reauth-Request(q)
>                    [Session-Id, MAC]
>      <-----    PANA-Reauth-Answer(q)
>                    [Session-Id, MAC]
>      <-----    PANA-Auth-Request(p)
>                    [Session-Id, EAP{Request}, MAC]
>      ----->    PANA-Auth-Answer(p)  // No piggybacking EAP Response
>                    [Session-Id, MAC]
>      ----->    PANA-Auth-Request(q+1)
>                    [Session-Id, EAP{Response}, MAC]
>      <-----    PANA-Auth-Answer(q+1) // No piggybacking EAP Response
>                    [Session-Id, MAC]
>      <-----    PANA-Auth-Request(p+1)
>                    [Session-Id, EAP{Request}, MAC]
>      ----->    PANA-Auth-Answer(p+1) // Piggybacking EAP Response
>                    [Session-Id, EAP{Response}, MAC]
>      <-----    PANA-Bind-Request(p+2)
>                    [Session-Id, Result-Code, EAP{Success},
>                    Device-Id, Key-Id,
>                    Lifetime, Protection-Cap., PPAC, MAC]
>      ----->    PANA-Bind-Answer(p+2)
>                    [Session-Id, Device-Id, Key-Id, PPAC, MAC]
>
>  Figure 7: Example sequence for the re-authentication phase initiated
>                                  by PaC
>
>
>4.7  Termination Phase
>
>  A procedure for explicitly terminating a PANA session can be
>  initiated either from the PaC (i.e., disconnect indication) or from
>  the PAA (i.e., session revocation).  The PANA-Termination-Request and
>  PANA-Termination-Answer message exchanges are used for disconnect
>  indication and session revocation procedures.
>
>  The reason for termination is indicated in the Termination-Cause AVP.
>  When there is an established PANA SA between the PaC and the PAA, all
>  messages exchanged during the termination phase MUST be protected
>  with a MAC AVP.  When the sender of the PANA-Termination-Request
>  message receives a valid acknowledgment, all states maintained for
>  the PANA session MUST be deleted immediately.
>
>
>
>
>
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 20]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  PaC      PAA    Message(sequence number)[AVPs]
>  ------------------------------------------------------
>      ----->        PANA-Termination-Request(q)[Session-Id, MAC]
>      <-----        PANA-Termination-Answer(q)[Session-Id, MAC]
>
>  Figure 8: Example sequence for the termination phase triggered by PaC
>
>
>4.8  Separate NAP and ISP Authentication
>
>  PANA allows running at most two EAP sessions in sequence in the
>  authentication and authorization phase to support separate NAP and
>  ISP authentication as described in this section.  A typical network
>  access authentication includes execution of one EAP method with the
>  ISP.  This separation allows the PaC to perform an additional
>  authentication method for receiving differentiated services from the
>  NAP.
>
>  Currently, running multiple EAP sessions in sequence in the
>  authentication and authorization phase is designed only for separate
>  NAP and ISP authentication.  It is not for running arbitrary number
>  of EAP sessions in sequence, or giving the PaC another chance to try
>  another EAP authentication method within an integrated NAP and ISP
>  authentication when an EAP authentication method fails.
>
>  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.
>
>4.8.1  Negotiating Separate NAP and ISP Authentication
>
>  When the PaC and PAA negotiates in the discovery and handshake phase
>  to perform separate NAP and ISP authentication, the PaC and the PAA
>  operate in the following way in addition to the behavior defined in
>  Section 4.3
>
>  In the discovery and handshake phase, the PAA MAY advertise
>  availability of separate NAP and ISP authentication ([I-D.ietf-pana-
>  framework]) by setting the S-flag on the PANA header of the PANA-
>  Start-Request message.
>
>  If the S-flag of the received PANA-Start-Request message is set, the
>  PaC can indicate its desire to perform separate NAP and ISP
>  authentication by setting the S-flag in the PANA-Start-Answer
>  message.  If the S-flag of the received PANA-Start-Request message is
>  not set, the PaC MUST NOT set the S-flag in the PANA-Start-Answer
>
>
>
>Forsberg, et al.        Expires January 17, 2006              [Page 21]
>?
>Internet-Draft                    PANA                        July 2005
>
>
>  message sent back to the PAA.
>
>  If the S-flag in the PANA-Start-Answer message is not set, only one
>  authentication is performed (ISP-only) and the processing occurs as
>  described in Section 4.3.
>
>  When the S-flag is set in a PANA-Start-Request message, the initial
>  EAP Request message MUST NOT be carried in the PANA-Start-Request
>  message.  (If the initial EAP Request message were contained in the
>  PANA-Start-Request message during the S-flag negotiation, the PaC
>  cannot tell whether the EAP Request message is for NAP authentication
>  or ISP authentication.)
>
>4.8.2  Execution of Separate NAP and ISP Authentication
>
>  When the PaC and PAA have negotiated in the discovery and handshake
>  phase to perform separate NAP and ISP authentication, the PaC and the
>  PAA operate in the following way in addition to the behavior defined
>  in Section 4.4
>
>  o  The S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST
&gt