draft-ietf-pana-pana-07a.txt		draft-ietf-pana-pana-07b.txt
PANA Working Group D. Forsberg		PANA Working Group D. Forsberg
Internet-Draft Nokia		Internet-Draft Nokia
Expires: June 1, 2005 Y. Ohba (Ed.)		Expires: June 12, 2005 Y. Ohba (Ed.)
Toshiba		Toshiba
B. Patil		B. Patil
Nokia		Nokia
H. Tschofenig		H. Tschofenig
Siemens		Siemens
A. Yegin		A. Yegin
Samsung		Samsung
December 1, 2004		December 12, 2004
Protocol for Carrying Authentication for Network Access (PANA)		Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-07a		draft-ietf-pana-pana-07b
Status of this Memo		Status of this Memo
By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
RFC 3668.		RFC 3668.
Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
Skipping to change at page 1, line 41:
and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2005.		This Internet-Draft will expire on June 12, 2005.
Copyright Notice		Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract		Abstract
This document defines the Protocol for Carrying Authentication for		This document defines the Protocol for Carrying Authentication for
Network Access (PANA), a link-layer agnostic transport for Extensible		Network Access (PANA), a link-layer agnostic transport for Extensible
Authentication Protocol (EAP) to enable network access authentication		Authentication Protocol (EAP) to enable network access authentication
Skipping to change at page 2, line 22:
Table of Contents		Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Specification of Requirements . . . . . . . . . . . . . . 5		1.1 Specification of Requirements . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9		3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11		4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 11		4.1 Payload Encoding . . . . . . . . . . . . . . . . . . . . . 11
4.2 Discovery and Handshake Phase . . . . . . . . . . . . . . 12		4.2 Discovery and Handshake Phase . . . . . . . . . . . . . . 12
4.3 Authentication Phase . . . . . . . . . . . . . . . . . . . 15		4.3 Authentication and Authorization Phase . . . . . . . . . . 15
4.4 Authorization Phase . . . . . . . . . . . . . . . . . . . 17		4.4 Access Phase . . . . . . . . . . . . . . . . . . . . . . . 17
4.5 Re-authentication Phase . . . . . . . . . . . . . . . . . 18		4.5 Re-authentication Phase . . . . . . . . . . . . . . . . . 18
4.6 Termination Phase . . . . . . . . . . . . . . . . . . . . 19		4.6 Termination Phase . . . . . . . . . . . . . . . . . . . . 20
4.7 Separate NAP and ISP Authentication . . . . . . . . . . . 20		4.7 Separate NAP and ISP Authentication . . . . . . . . . . . 21
4.7.1 Negotiating Separate NAP and ISP Authentication . . . 20		4.7.1 Negotiating Separate NAP and ISP Authentication . . . 21
4.7.2 Execution of Separate NAP and ISP Authentication . . . 21		4.7.2 Execution of Separate NAP and ISP Authentication . . . 22
4.7.3 AAA-Key Calculation . . . . . . . . . . . . . . . . . 22		4.7.3 AAA-Key Calculation . . . . . . . . . . . . . . . . . 23
5. Protocol Design Details and Processing Rules . . . . . . . . 23		5. Protocol Design Details and Processing Rules . . . . . . . . 24
5.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 23		5.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 24
5.1.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 23		5.1.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 24
5.2 Sequence Number and Retransmission . . . . . . . . . . . . 23		5.2 Sequence Number and Retransmission . . . . . . . . . . . . 24
5.3 PANA Security Association . . . . . . . . . . . . . . . . 24		5.3 PANA Security Association . . . . . . . . . . . . . . . . 25
5.4 Message Authentication Code . . . . . . . . . . . . . . . 26		5.4 Message Authentication Code . . . . . . . . . . . . . . . 27
5.5 Message Validity Check . . . . . . . . . . . . . . . . . . 27		5.5 Message Validity Check . . . . . . . . . . . . . . . . . . 28
5.6 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 28		5.6 Device ID Choice . . . . . . . . . . . . . . . . . . . . . 29
5.7 PaC Updating its IP Address . . . . . . . . . . . . . . . 29		5.7 PaC Updating its IP Address . . . . . . . . . . . . . . . 30
5.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 29		5.8 Session Lifetime . . . . . . . . . . . . . . . . . . . . . 30
5.9 Network Selection . . . . . . . . . . . . . . . . . . . . 30		5.9 Network Selection . . . . . . . . . . . . . . . . . . . . 31
5.10 Error Handling . . . . . . . . . . . . . . . . . . . . . 30		5.10 Error Handling . . . . . . . . . . . . . . . . . . . . . 32
6. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 32		6. PANA Headers and Formats . . . . . . . . . . . . . . . . . . 33
7. PANA Headers and Formats . . . . . . . . . . . . . . . . . . 34		6.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 33
7.1 IP and UDP Headers . . . . . . . . . . . . . . . . . . . . 34		6.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 34		6.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 36		7. PANA Messages, Message Specifications and AVPs . . . . . . . 38
8. PANA Messages, Message Specifications and AVPs . . . . . . . 39		7.1 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 38
8.1 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 39		7.2 PANA Message ABNF Specification . . . . . . . . . . . . . 38
8.2 Message Specifications . . . . . . . . . . . . . . . . . . 39		7.2.1 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . 40
8.2.1 PANA-PAA-Discover (PDI) . . . . . . . . . . . . . . . 40		7.2.2 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . 41
8.2.2 PANA-Start-Request (PSR) . . . . . . . . . . . . . . . 40		7.2.3 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . 41
8.2.3 PANA-Start-Answer (PSA) . . . . . . . . . . . . . . . 40		7.2.4 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . 41
8.2.4 PANA-Auth-Request (PAR) . . . . . . . . . . . . . . . 41		7.2.5 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . 41
8.2.5 PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . . 41		7.2.6 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . 42
8.2.6 PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . . 41		7.2.7 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . 42
8.2.7 PANA-Reauth-Answer (PRAA) . . . . . . . . . . . . . . 41		7.2.8 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . 42
8.2.8 PANA-Bind-Request (PBR) . . . . . . . . . . . . . . . 42		7.2.9 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . 43
8.2.9 PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . . 42		7.2.10 PANA-Ping-Request (PPR) . . . . . . . . . . . . . . 43
8.2.10 PANA-Ping-Request (PPR) . . . . . . . . . . . . . . 42		7.2.11 PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . 43
8.2.11 PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . . 42		7.2.12 PANA-Termination-Request (PTR) . . . . . . . . . . . 43
8.2.12 PANA-Termination-Request (PTR) . . . . . . . . . . . 43		7.2.13 PANA-Termination-Answer (PTA) . . . . . . . . . . . 44
8.2.13 PANA-Termination-Answer (PTA) . . . . . . . . . . . 43		7.2.14 PANA-Error-Request (PER) . . . . . . . . . . . . . . 44
8.2.14 PANA-Error-Request (PER) . . . . . . . . . . . . . . 43		7.2.15 PANA-Error-Answer (PEA) . . . . . . . . . . . . . . 44
8.2.15 PANA-Error-Answer (PEA) . . . . . . . . . . . . . . 43		7.2.16 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . 44
8.2.16 PANA-FirstAuth-End-Request (PFER) . . . . . . . . . 44		7.2.17 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . 45
8.2.17 PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . . 44		7.2.18 PANA-Update-Request (PUR) . . . . . . . . . . . . . 45
8.2.18 PANA-Update-Request (PUR) . . . . . . . . . . . . . 44		7.2.19 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . 45
8.2.19 PANA-Update-Answer (PUA) . . . . . . . . . . . . . . 44		7.3 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 45
8.3 AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . . 45		7.3.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . 48
8.3.1 MAC AVP . . . . . . . . . . . . . . . . . . . . . . . 48		7.3.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . 49
8.3.2 Device-Id AVP . . . . . . . . . . . . . . . . . . . . 49		7.3.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . 49
8.3.3 Session-Id AVP . . . . . . . . . . . . . . . . . . . . 49		7.3.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . 49
8.3.4 Cookie AVP . . . . . . . . . . . . . . . . . . . . . . 49		7.3.5 Protection-Capability AVP . . . . . . . . . . . . . . 49
8.3.5 Protection-Capability AVP . . . . . . . . . . . . . . 49		7.3.6 Termination-Cause AVP . . . . . . . . . . . . . . . . 50
8.3.6 Termination-Cause AVP . . . . . . . . . . . . . . . . 50		7.3.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . 50
8.3.7 Result-Code AVP . . . . . . . . . . . . . . . . . . . 50		7.3.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 53
8.3.8 EAP-Payload AVP . . . . . . . . . . . . . . . . . . . 53		7.3.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . 54
8.3.9 Session-Lifetime AVP . . . . . . . . . . . . . . . . . 54		7.3.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . 54
8.3.10 Failed-AVP AVP . . . . . . . . . . . . . . . . . . . 54		7.3.11 NAP-Information AVP . . . . . . . . . . . . . . . . 54
8.3.11 NAP-Information AVP . . . . . . . . . . . . . . . . 54		7.3.12 ISP-Information AVP . . . . . . . . . . . . . . . . 54
8.3.12 ISP-Information AVP . . . . . . . . . . . . . . . . 54		7.3.13 Provider-Identifier AVP . . . . . . . . . . . . . . 54
8.3.13 Provider-Identifier AVP . . . . . . . . . . . . . . 54		7.3.14 Provider-Name AVP . . . . . . . . . . . . . . . . . 54
8.3.14 Provider-Name AVP . . . . . . . . . . . . . . . . . 54		7.3.15 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . 55
8.3.15 Key-Id AVP . . . . . . . . . . . . . . . . . . . . . 55		7.3.16 Post-PANA-Address-Configuration (PPAC) AVP . . . . . 55
8.3.16 Post-PANA-Address-Configuration (PPAC) AVP . . . . . 55		7.3.17 Nonce AVP . . . . . . . . . . . . . . . . . . . . . 56
8.3.17 Nonce AVP . . . . . . . . . . . . . . . . . . . . . 56		7.3.18 IP-Address AVP . . . . . . . . . . . . . . . . . . . 56
8.3.18 IP-Address AVP . . . . . . . . . . . . . . . . . . . 56		8. Retransmission Timers . . . . . . . . . . . . . . . . . . . 57
9. Retransmission Timers . . . . . . . . . . . . . . . . . . . 57		8.1 Transmission and Retransmission Parameters . . . . . . . . 58
9.1 Transmission and Retransmission Parameters . . . . . . . . 58		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 60
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 60		9.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . . 60
10.1 PANA UDP Port Number . . . . . . . . . . . . . . . . . . 60		9.2 PANA Multicast Address . . . . . . . . . . . . . . . . . . 60
10.2 PANA Multicast Address . . . . . . . . . . . . . . . . . 60		9.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . . 60
10.3 PANA Header . . . . . . . . . . . . . . . . . . . . . . 60		9.3.1 Message Type . . . . . . . . . . . . . . . . . . . . . 60
10.3.1 Message Type . . . . . . . . . . . . . . . . . . . . 60		9.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 61
10.3.2 Flags . . . . . . . . . . . . . . . . . . . . . . . 61		9.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . . 61
10.4 AVP Header . . . . . . . . . . . . . . . . . . . . . . . 61		9.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . . 61
10.4.1 AVP Code . . . . . . . . . . . . . . . . . . . . . . 61		9.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 62
10.4.2 Flags . . . . . . . . . . . . . . . . . . . . . . . 62		9.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 62
10.5 AVP Values . . . . . . . . . . . . . . . . . . . . . . . 62		9.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . . 62
10.5.1 Algorithm Values of MAC AVP . . . . . . . . . . . . 62		9.5.2 Protection-Capability AVP Values . . . . . . . . . . . 62
10.5.2 Protection-Capability AVP Values . . . . . . . . . . 62		9.5.3 Termination-Cause AVP Values . . . . . . . . . . . . . 62
10.5.3 Termination-Cause AVP Values . . . . . . . . . . . . 62		9.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . . 62
10.5.4 Result-Code AVP Values . . . . . . . . . . . . . . . 62		9.5.5 Post-PANA-Address-Configuration AVP Values . . . . . . 63
10.5.5 Post-PANA-Address-Configuration AVP Values . . . . . 63		10. Security Considerations . . . . . . . . . . . . . . . . . . 64
11. Security Considerations . . . . . . . . . . . . . . . . . . 64		10.1 General Security Measures . . . . . . . . . . . . . . . 64
11.1 General Security Measures . . . . . . . . . . . . . . . 64		10.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . 65
11.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . 65		10.3 EAP Methods . . . . . . . . . . . . . . . . . . . . . . 66
11.3 EAP Methods . . . . . . . . . . . . . . . . . . . . . . 66		10.4 Separate NAP and ISP Authentication . . . . . . . . . . 66
11.4 Separate NAP and ISP Authentication . . . . . . . . . . 66		10.5 Cryptographic Keys . . . . . . . . . . . . . . . . . . . 66
11.5 Cryptographic Keys . . . . . . . . . . . . . . . . . . . 66		10.6 Per-packet Ciphering . . . . . . . . . . . . . . . . . . 67
11.6 Per-packet Ciphering . . . . . . . . . . . . . . . . . . 67		10.7 PAA-to-EP Communication . . . . . . . . . . . . . . . . 67
11.7 PAA-to-EP Communication . . . . . . . . . . . . . . . . 67		10.8 Liveness Test . . . . . . . . . . . . . . . . . . . . . 68
11.8 Livenes Test . . . . . . . . . . . . . . . . . . . . . . 68		10.9 Updating PaC's IP Address . . . . . . . . . . . . . . . 68
11.9 Mobility Optimization . . . . . . . . . . . . . . . . . 68		10.10 Early Termination of a Session . . . . . . . . . . . . . 68
11.10 Updating PaC's IP Address . . . . . . . . . . . . . . . 68		11. Open Issues and Change History . . . . . . . . . . . . . . . 69
11.11 Early Termination of a Session . . . . . . . . . . . . . 69
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 70		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 70
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 71		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.1 Normative References . . . . . . . . . . . . . . . . . . . 71		13.1 Normative References . . . . . . . . . . . . . . . . . . . 71
13.2 Informative References . . . . . . . . . . . . . . . . . . 72		13.2 Informative References . . . . . . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 73		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 74
A. Example Sequence of Separate NAP and ISP Authentication . . 75		A. Example Sequence of Separate NAP and ISP Authentication . . 76
Intellectual Property and Copyright Statements . . . . . . . 77		Intellectual Property and Copyright Statements . . . . . . . 78
1. Introduction		1. Introduction
Providing secure network access service requires access control based		Providing secure network access service requires access control based
on the authentication and authorization of the clients and the access		on the authentication and authorization of the clients and the access
networks. Client-to-network authentication provides parameters that		networks. Client-to-network authentication provides parameters that
are needed to police the traffic flow through the enforcement points.		are needed to police the traffic flow through the enforcement points.
A protocol is needed to carry authentication methods between the		A protocol is needed to carry authentication methods between the
client and the access network.		client and the access network.
Skipping to change at page 7, line 11:
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document		"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].		are to be interpreted as described in [RFC2119].
2. Terminology		2. Terminology
PANA Client (PaC):		PANA Client (PaC):
The client side of the protocol that resides in the access device		The client side of the protocol that resides in the access device
(e.g., laptop, PDA, etc.). It is responsible for providing the		(e.g., laptop, PDA, etc.). It is responsible for providing the
credentials in order to prove its identity for network access		credentials in order to prove its identity (authentication) for
authorization.		network access authorization.
PANA Authentication Agent (PAA):		PANA Authentication Agent (PAA):
The protocol entity in the access network whose responsibility is		The protocol entity in the access network whose responsibility is
to verify the credentials provided by a PANA client (PaC) and		to verify the credentials provided by a PANA client (PaC) and
authorize network access to the device associated with the client		authorize network access to the device associated with the client
and identified by a Device Identifier (DI). Note the		and identified by a Device Identifier (DI). Note the
authentication and authorization procedure can, according to the		authentication and authorization procedure can, according to the
EAP model, be also offloaded to the backend AAA infrastructure.		EAP model, be also offloaded to the backend AAA infrastructure.
Skipping to change at page 7, line 43:
This identifier is used to uniquely identify a PANA session on the		This identifier is used to uniquely identify a PANA session on the
PAA and PaC. It includes an identifier of the PAA, therefore it		PAA and PaC. It includes an identifier of the PAA, therefore it
cannot be shared across multiple PAAs. It is included in PANA		cannot be shared across multiple PAAs. It is included in PANA
messages to bind the message to a specific PANA session. This		messages to bind the message to a specific PANA session. This
bidirectional identifier is allocated by the PAA following the		bidirectional identifier is allocated by the PAA following the
handshake and freed when the session terminates.		handshake and freed when the session terminates.
PANA Security Association (PANA SA):		PANA Security Association (PANA SA):
A PANA security association is a relationship between the PaC and		A PANA security association is formed between the PaC and the PAA
PAA, formed by the sharing of cryptographic keying material and		by sharing cryptographic keying material and associated context.
associated context. Security associations are duplex. That is,		The formed duplex security association is used to protect the
one security association is needed to protect the bidirectional		bidirectional PANA signaling traffic between the PaC and the PAA.
traffic between the PaC and the PAA.
Device Identifier (DI):		Device Identifier (DI):
The identifier used by the network as a handle to control and		The identifier used by the network as a handle to control and
police the network access of a client. Depending on the access		police the network access of a device. Depending on the access
technology, this identifier may contain an address that is carried		technology, this identifier may contain an address that is carried
in protocol headers (e.g., IP or link-layer address), or a locally		in protocol headers (e.g., IP or link-layer address), or a locally
significant identifier that is made available by the local		significant identifier that is made available by the local
protocol stack (e.g., circuit id, PPP interface id) of a connected		protocol stack (e.g., circuit id, PPP interface id) of a connected
device.		device.
Enforcement Point (EP):		Enforcement Point (EP):
A node on the access network where per-packet enforcement policies		A node on the access network where per-packet enforcement policies
(i.e., filters) are applied on the inbound and outbound traffic of		(i.e., filters) are applied on the inbound and outbound traffic of
client devices. Information such as the DI and (optionally)		access devices. Information such as the DI and (optionally)
cryptographic keys are provided by the PAA per client for		cryptographic keys are provided by the PAA per client for
generating filters on the EP. EP and PAA may be co-located.		generating filters on the EP. The EP and PAA may be co-located.
Network Access Provider (NAP):		Network Access Provider (NAP):
A service provider that provides physical and link-layer		A service provider that provides physical and link-layer
connectivity to an access network it manages.		connectivity to an access network it manages.
AAA-Key:		AAA-Key:
A key derived by the EAP peer and EAP server and transported to		A key derived by the EAP peer and EAP server and transported to
the authenticator [I-D.ietf-eap-keying].		the authenticator [I-D.ietf-eap-keying].
		For additional terminology definitions see the PANA framework
		document [I-D.ietf-pana-framework].
3. Protocol Overview		3. Protocol Overview
The PANA protocol is run between a client (PaC) and a server (PAA) in		The PANA protocol is run between a client (PaC) and a server (PAA) in
order to perform authentication and authorization for the network		order to perform authentication and authorization for the network
access service.		access service.
The protocol messaging consists of a series of request and responses,		The protocol messaging consists of a series of request and responses,
some of which may be initiated by either ends. Each message can		some of which may be initiated by either ends. Each message can
carry zero or more AVPs as payload. The main payload of PANA is EAP		carry zero or more AVPs as payload. The main payload of PANA is EAP
which performs authentication. PANA helps PaC and PAA establish an		which performs authentication. PANA helps PaC and PAA establish an
Skipping to change at page 9, line 29:
PANA messages are sent between a PaC and PAA as part of a PANA		PANA messages are sent between a PaC and PAA as part of a PANA
session. A PANA session consists of distinct phases:		session. A PANA session consists of distinct phases:
o Discovery and handshake phase: This is the phase that initiates a		o Discovery and handshake phase: This is the phase that initiates a
new PANA session. The PaC discovers the PAA(s) by either		new PANA session. The PaC discovers the PAA(s) by either
explicitly soliciting advertisements for them or receiving		explicitly soliciting advertisements for them or receiving
unsolicited advertisements. The PaC's answer sent in response to		unsolicited advertisements. The PaC's answer sent in response to
an advertisement starts a new session.		an advertisement starts a new session.
o Authentication phase: Immediately following the handshake phase is		o Authentication and authorization phase: Immediately following the
the EAP execution between the PAA and PaC. The EAP payloads		discovery and handshake phase is the EAP execution between the PAA
(which carry an EAP method inside) is what is used for		and PaC. The EAP payload (which carry an EAP method inside) is
authentication. Authentication phase may involve execution of two		what is used for authentication. The PAA conveys the result of
EAP sessions back-to-back, one for the NAP and one for the ISP.		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 Authorization phase: Following a successful PANA authentication		o Access phase: After a successful authentication and authorization
phase, the PaC gains access to the network and can send and		the host gains access to the network and can send and receive IP
receive IP data traffic through EP. During this phase, the PaC		data traffic through the EP(s). At any time during this phase,
and PAA may optionally ping each other to test liveness of the		the PaC and PAA may optionally ping each other to test liveness of
PANA session on each end.		the PANA session on each end.
o Re-authentication phase: Following an authorization phase, the PAA		o Re-authentication phase: Following the access phase, the PAA must
must initiate re-authentication before the PANA session lifetime		initiate re-authentication before the PANA session lifetime
expires. Again EAP is carried by PANA to perform authentication.		expires. Again EAP is carried by PANA to perform authentication.
This phase may be optionally triggered by both the PaC and the PAA		This phase may be optionally triggered by both the PaC and the PAA
without any respect to the session lifetime. The session moves to		without any respect to the session lifetime. The session moves to
this phase from authorized phase, and returns back there upon		this phase from the access phase, and returns back there upon
successful re-authentication.		successful re-authentication.
o Termination phase: The PaC or PAA may choose to discontinue the		o Termination phase: The PaC or PAA may choose to discontinue the
access service at any time. An explicit disconnect message can be		access service at any time. An explicit disconnect message can be
sent by either end. If either the PaC or the PAA disconnects		sent by either end. If either the PaC or the PAA disconnects
without engaging in termination messaging, it is expected that		without engaging in termination messaging, it is expected that
either the expiration of a finite session lifetime or failed		either the expiration of a finite session lifetime or failed
liveness tests would do the job.		liveness tests would do the job.
PaC PAA Message		PaC PAA Message
-----------------------------------------------------		-----------------------------------------------------
// Discovery and handshake phase		// Discovery and handshake phase
-----> PANA-PAA-Discover		-----> PANA-PAA-Discover
<----- PANA-Start-Request		<----- PANA-Start-Request
-----> PANA-Start-Answer		-----> PANA-Start-Answer
// Authentication phase		// Authentication and authorization phase
<----- PANA-Auth-Request /* EAP Request */		<----- PANA-Auth-Request /* EAP Request */
-----> PANA-Auth-Answer		-----> PANA-Auth-Answer
-----> PANA-Auth-Request /* EAP Response */		-----> PANA-Auth-Request /* EAP Response */
<----- PANA-Auth-Answer		<----- PANA-Auth-Answer
<----- PANA-Bind-Request /* EAP Success */		<----- PANA-Bind-Request /* EAP Success */
-----> PANA-Bind-Answer		-----> PANA-Bind-Answer
// Authorization phase (IP data traffic allowed)		// Access phase (IP data traffic allowed)
<----- PANA-Ping-Request		<----- PANA-Ping-Request
-----> PANA-Ping-Answer		-----> PANA-Ping-Answer
// Termination phase		// Termination phase
-----> PANA-Termination-Request		-----> PANA-Termination-Request
<----- PANA-Termination-Answer		<----- PANA-Termination-Answer
Figure 1: Illustration of PANA Messages in a Session		Figure 1: Illustration of PANA Messages in a Session
Note that depending on the environment and deployment the protocol		Note that depending on the environment and deployment the protocol
flow depicted in Figure 1 can be abbreviated.		flow depicted in Figure 1 can be abbreviated.
Cryptographic protection of messages between the PaC and PAA is		Cryptographic protection of messages between the PaC and PAA is
possible as soon as EAP in conjunction with the EAP method exports a		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		shared key. That shared key is used to create a PANA SA. The PANA
SA helps generating per-message authentication codes that provide		SA helps generating per-message authentication codes that provide
integrity protection and authentication.		integrity protection and authentication.
PANA also allows creation of a new PANA session with a new PAA out of
an existing session with another PAA. This optimization allows PaC
achieve quicker authorization without having to run EAP upon movement
(changing PAAs).
Throughout the lifetime of a session, various problems found with the		Throughout the lifetime of a session, various problems found with the
incoming messages can generate a PANA error message sent in response.		incoming messages can generate a PANA error message sent in response.
4. Protocol Details		4. Protocol Details
The following sections explain in detail the various phases of a PANA		The following sections explain in detail the various phases of a PANA
session.		session.
4.1 Payload Encoding		4.1 Payload Encoding
The payload of any PANA message consists of zero or more AVPs		The payload of any PANA message consists of zero or more AVPs
(Attribute Value Pairs). The subsequent sections refer to these		(Attribute Value Pairs). The subsequent sections refer to these
AVPs, therefore the list of AVPs are provided with a brief		AVPs, therefore the list of AVPs are provided with a brief
description before more extensive descriptions are included later in		description before more extensive descriptions are included later in
the document.		the document.
o Cookie AVP: contains a random value that is used for making PAA		o Cookie AVP: contains a random value that is generated by a PAA and
discovery robust against blind resource consumption DoS attacks.		used for making PAA discovery robust against blind resource
		consumption DoS attacks.
o Protection-Capability AVP: contains the type of per-packet		o Protection-Capability AVP: contains the type of per-packet
protection (link-layer vs. network-layer) when a cryptographic		protection (link-layer vs. network-layer) when a cryptographic
mechanism should be enabled after PANA authentication.		mechanism should be enabled after PANA authentication.
o Device-Id AVP: contains a device identifier (link-layer address or		o Device-Id AVP: contains a device identifier (link-layer address or
an IP address) of the PaC or an EP.		an IP address) of the PaC or an EP.
o EAP AVP: contains an EAP PDU.		o EAP AVP: contains an EAP PDU.
Skipping to change at page 11, line 44:
o Result-Code AVP: contains information about the protocol execution		o Result-Code AVP: contains information about the protocol execution
results.		results.
o Session-Id AVP: contains the PANA session identifier value.		o Session-Id AVP: contains the PANA session identifier value.
o Session-Lifetime AVP: contains the duration of authorized access.		o Session-Lifetime AVP: contains the duration of authorized access.
o Failed-AVP: contains an offending AVP that caused a failure.		o Failed-AVP: contains an offending AVP that caused a failure.
		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		o NAP-Information AVP, ISP-Information AVP: contains the identifier
of a NAP and an ISP, respectively.		of a NAP and an ISP, respectively.
o Key-Id AVP: contains a AAA-Key identifier.		o Key-Id AVP: contains a AAA-Key identifier.
o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate		o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate
the available/chosen IP address configuration methods that can be		the available/chosen IP address configuration methods that can be
used by the PaC after successful PANA authentication.		used by the PaC after successful PANA authentication.
o Nonce AVP: contains a randomly chosen value that is used in		o Nonce AVP: contains a randomly chosen value that is used in
cyrptographic key computations.		cyrptographic key computations.
o IP-Address AVP: contains an IP Address of the PaC.		o IP-Address AVP: contains an IP Address of the PaC.
4.2 Discovery and Handshake Phase		4.2 Discovery and Handshake Phase
When a PaC attaches to a network, and knows that it has to discover a		When a PaC attaches to a network, and knows that it has to discover a
PAA, it SHOULD send a PANA-PAA-Discover message to a well-known link		PAA, it SHOULD send a PANA-PAA-Discover message to a well-known link
local multicast address (TBD) and UDP port (TBD). The PAA discovery		local multicast address (TBD) and UDP port (TBD). The PAA discovery
assumes that the PaC and the PAA are one hop away from each other.		assumes that the PaC and the PAA are one IP hop away from each other.
If the PaC knows the IP address of the PAA (based on		If the PaC knows the IP address of the PAA (based on
pre-configuration), it MAY unicast the PANA-PAA-Discover message to		pre-configuration), it MAY unicast the PANA-PAA-Discover message to
that address.		that address.
When the PAA receives a PANA-PAA-Discover message from a PaC, the PAA		When the PAA receives a PANA-PAA-Discover message from a PaC, the PAA
SHOULD unicast a PANA-Start-Request message to the PaC.		SHOULD unicast a PANA-Start-Request message to the PaC.
The PaC MAY also choose to start sending data packets before getting		The PaC MAY also choose to start sending data packets before getting
authenticated. The EP in an access network that implements PANA		authenticated. The EP in an access network that implements PANA
SHOULD drop unauthorized packets upon receipt. Additionally, the EP		SHOULD drop unauthorized packets upon receipt. Additionally, the EP
MAY also take this traffic as an indication of unauthorized PaC and		MAY also take this traffic as an indication of unauthorized PaC and
notify the PAA. The EP-to-PAA notification SHOULD be sent via		notify the PAA. The EP-to-PAA notification SHOULD be sent via
[I-D.ietf-pana-snmp]. In response, the PAA SHOULD send an		[I-D.ietf-pana-snmp]. In response, the PAA SHOULD send an
unsolicited PANA-Start-Request message to the PaC. This is called		unsolicited PANA-Start-Request message to the PaC. This is called
"traffic-driven PAA discovery" (an alternative to PaC explicitly		"traffic-driven PAA discovery" (an alternative to PaC explicitly
soliciting for PAA). Note that this optional feature MAY NOT be		soliciting for PAA). Note that this optional feature MAY NOT be
present in all deployments, therefore PaCs MUST NOT assume its		present in all deployments, therefore PaCs MUST NOT assume its
availability.		availability. 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].
When a PaC receives a PANA-Start-Request message from a PAA, it		When a PaC receives a PANA-Start-Request message from a PAA, it
responds with a PANA-Start-Answer message if it wishes to enter an		responds with a PANA-Start-Answer message if it wishes to enter the
authentication phase.		authentication and authorization phase.
There can be multiple PAAs on the link and a PaC may receive multiple		There can be multiple PAAs on the link and a PaC may receive multiple
PANA-Start-Request messages from those PAAs. The authentication and		PANA-Start-Request messages from those PAAs. The authentication and
authorization result does not depend on which PAA is chosen by the		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		PaC. By default the PaC MAY choose the PAA that sent the first
response.		response.
A PANA-Start-Request message MAY carry a Cookie AVP that contains a		A PANA-Start-Request message MAY carry a Cookie AVP that contains a
cookie. The cookie is used for preventing the PAA from resource		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		consumption DoS attacks by blind attackers which bombard the PAA with
PANA-PAA-Discover messages. By relying on a cookie mechanism the PAA		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		can avoid per-PaC state creation until after the PaC can produce the
same cookie in its PANA-Start-Answer message. In order to do that,		same cookie in its PANA-Start-Answer message. In order to do that,
the cookie MUST be computed in such a way that it does not require		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		any per-session state maintenance on the PAA in order to verify the
cookie returned in a PANA-Start-Answer message. The PAA discovery		cookie returned in a PANA-Start-Answer message. The PAA discovery
that takes advantage of cookies is called "stateless PAA discovery".		that takes advantage of cookies is called "stateless PAA discovery".
The exact algorithms and syntax used for generating cookies does not		The exact algorithms and syntax used by the PAA to generate cookies
affect interoperability and hence is not specified here. An example		does not affect interoperability and hence is not specified here. An
algorithm is described below.		example algorithm is described below.
Cookie =		Cookie =
<secret-version> | HMAC_SHA1( <Device-Id of PaC> , <secret> )		<secret-version> | HMAC_SHA1( <Device-Id of PaC> , <secret> )
where <secret> is a randomly generated secret known only to the PAA,		where <secret> is a randomly generated secret known only to the PAA,
<secret-version> is an index used for choosing the secret for		<secret-version> is an index used for choosing the secret for
generating the cookie and '|' indicates concatenation. The		generating the cookie and '|' indicates concatenation. The
secret-version should be changed frequently enough to prevent replay		secret-version should be changed frequently enough to prevent replay
attacks. The secret key is valid for a certain time frame.		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.
When the PaC sends a PANA-Start-Answer message in response to a		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		PANA-Start-Request containing a Cookie AVP, the answer MUST contain a
Cookie AVP with the cookie value copied from the request.		Cookie AVP with the cookie value copied from the request.
When the PAA receives the PANA-Start-Answer message from the PaC, it		When the PAA receives the PANA-Start-Answer message from the PaC, it
verifies the cookie. The cookie is considered as valid if the		verifies the cookie. The cookie is considered as valid if the
received cookie has the expected value. If the computed cookie is		received cookie has the expected value. If the computed cookie is
valid, the protocol enters the authentication phase. Otherwise, it		valid, the protocol enters the authentication and authorization
MUST silently discard the received message.		phase. Otherwise, it MUST silently discard the received message.
Initial EAP Request MAY be optionally carried by the		Initial EAP Request MAY be optionally carried by the
PANA-Start-Request (as opposed to by a later PANA-Auth-Request)		PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
message in order to reduce the number of round-trips. This		message in order to reduce the number of round-trips. This
optimization SHOULD NOT be used if the PAA discovery is desired to be		optimization SHOULD NOT be used if the PAA discovery is desired to be
stateless.		stateless since transmission of an EAP request creates state at EAP
		layer [I-D.ietf-eap-statemachine].
A Protection-Capability AVP and a Post-PANA-Address-Configuration		A Protection-Capability AVP and a Post-PANA-Address-Configuration
(PPAC) AVP MAY be included in the PANA-Start-Request in order to		(PPAC) AVP MAY be included in the PANA-Start-Request in order to
indicate required and available capabilities for the network access.		indicate required and available capabilities for the network access.
These AVPs MAY be used by the PaC for assessing the capability match		These AVPs MAY be used by the PaC for assessing the capability match
even before the authentication takes place. Since these AVPs are		even before the authentication takes place. Since these AVPs are
provided during the insecure discovery and handshake phase, there are		provided during the insecure discovery and handshake phase, there are
certain security risks involved in using the provided information.		certain security risks involved in using the provided information.
See Section 11 for further discussion on this.		See Section 10 for further discussion on this.
If the initial EAP Request message is carried in the		If the initial EAP Request message is carried in the
PANA-Start-Request message, an EAP Response message MUST be carried		PANA-Start-Request message, an EAP Response message MUST be carried
in the PANA-Start-Answer message returned to the PAA.		in the PANA-Start-Answer message returned to the PAA.
The PANA-Start-Request/Answer exchange is needed before entering an		The PANA-Start-Request/Answer exchange is needed before entering the
authentication phase even when the PaC is pre-configured with PAAs IP		authentication and authorization phase even when the PaC is
address and the PANA-PAA-Discover message is unicast.		pre-configured with PAAs IP address and the PANA-PAA-Discover message
		is unicast.
A Nonce AVP MUST be included in PANA-Start-Request and		A Nonce AVP MUST be included in PANA-Start-Request and
PANA-Start-Answer messages. The nonces are used to establish a PANA		PANA-Start-Answer messages. The nonces are used to establish a fresh
SA.		PANA_MAC_KEY (see Section 5.3) which is a transient session key in
		the EAP key hierarchy [I-D.ietf-eap-keying] and is used only in the
		PANA protocol. A Nonce AVP MUST be included in PANA-Start-Request
		and PANA-Start-Answer messages. The nonces are used to establish a
		PANA SA.
A PANA-Start-Request message of a stateless PAA discovery MUST NOT be		A PANA-Start-Request message of a stateless PAA discovery MUST NOT be
on a retransmission timer as this voids the statelessness on the PAA.		retransmitted as this voids the statelessness on the PAA. Instead,
Instead, the PaC MUST retransmit the PANA-PAA-Discover until it		the PaC MUST retransmit the PANA-PAA-Discover until it receives a
receives a PANA-Start-Request message, and retransmit the		PANA-Start-Request message, and retransmit the PANA-Start-Answer
PANA-Start-Answer message until it receives a PANA-Auth-Request		message until it receives a PANA-Auth-Request message. The PaC can
message. The PaC can determine whether the PAA is using stateless		determine whether the PAA is using stateless discovery by the
discovery by the presence of Cookie AVP. The PANA-Start-Request		presence of Cookie AVP. The PANA-Start-Request message MUST be
message MUST be retransmitted instead of the PANA-Start-Answer		retransmitted instead of the PANA-Start-Answer message when stateful
message when stateful PAA discovery is used.		PAA discovery is used.
It is possible that both the PAA and the PaC initiate the discovery		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		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		PANA-Start-Request message while the PaC sends a PANA-PAA-Discover
message. To resolve the race condition, the PAA SHOULD silently		message. To resolve the race condition, the PAA SHOULD silently
discard the PANA-PAA-Discover message received from the PaC after it		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		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		Cookie AVP is included in the message) for the PaC. In this case the
PAA will retransmit PANA-Start-Request based on a timer, if the PaC		PAA will retransmit PANA-Start-Request based on a timer, if the PaC
doesn't respond in time (message was lost for example). If the PAA		doesn't respond in time (message was lost for example). If the PAA
Skipping to change at page 14, line 42:
Figure 2 shows an example sequence for the discovery and handshake		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		phase when a PANA-PAA-Discover message is sent by the PaC. Figure 3
shows an example sequence for the discovery and handshake phase that		shows an example sequence for the discovery and handshake phase that
is triggered by data traffic.		is triggered by data traffic.
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(seqno)[AVPs]
------------------------------------------------------		------------------------------------------------------
-----> PANA-PAA-Discover(0)		-----> PANA-PAA-Discover(0)
<----- PANA-Start-Request(x)[Nonce, Cookie]		<----- PANA-Start-Request(x)[Nonce, Cookie]
-----> PANA-Start-Answer(x)[Nonce, Cookie]		-----> PANA-Start-Answer(x)[Nonce, Cookie]
(continued to authentication phase)		(continued to the authentication and
		authorization phase)
Figure 2: Example Sequence for Discovery and Handshake Phase when		Figure 2: Example Sequence for Discovery and Handshake Phase when
PANA-PAA-Discover is sent by PaC		PANA-PAA-Discover is sent by PaC
PaC EP PAA Message(seqno)[AVPs]		PaC EP PAA Message(seqno)[AVPs]
------------------------------------------------------		------------------------------------------------------
---->o (Data packet arrival or L2 trigger)		---->o (Data packet arrival or L2 trigger)
------> PAA-to-EP protocol, or another mechanism		------> PAA-to-EP protocol, or another mechanism
<------------ PANA-Start-Request(x)[Nonce, Cookie]		<------------ PANA-Start-Request(x)[Nonce, Cookie]
------------> PANA-Start-Answer(x)[Nonce, Cookie]		------------> PANA-Start-Answer(x)[Nonce, Cookie]
(continued to authentication phase)		(continued to the authentication and
		authorization phase)
Figure 3: Example Sequence for Discovery and Handshake when discovery		Figure 3: Example Sequence for Discovery and Handshake when discovery
is triggered by data traffic		is triggered by data traffic
4.3 Authentication Phase		4.3 Authentication and Authorization Phase
The main task in authentication phase is to carry EAP messages		The main task in the authentication and authorization phase is to
between the PaC and the PAA. EAP Request and Response messages are		carry EAP messages between the PaC and the PAA. EAP Request and
carried in PANA-Auth-Request messages. PANA-Auth-Answer messages are		Response messages are carried in PANA-Auth-Request messages.
simply used to acknowledge receipt of the requests. As an		PANA-Auth-Answer messages are simply used to acknowledge receipt of
optimization, a PANA-Auth-Answer message MAY include the EAP		the requests. As an optimization, a PANA-Auth-Answer message MAY
Response. Another optimization allows optionally carrying the first		include the EAP Response. Another optimization allows optionally
EAP Request/Response in PANA-Start-Request/Answer message as		carrying the first EAP Request/Response in PANA-Start-Request/Answer
described in Section 4.2		message as described in Section 4.2
PANA allows execution of two separate authentication methods, one		PANA allows execution of two separate authentication methods, one
with NAP and one with ISP under the same PANA session. This optional		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		feature may be offered by the PAA and accepted by the PaC. When
performed separately, the result of first EAP authentication is		performed separately, the result of the first EAP authentication is
signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer		signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer
message exchange which delineates the first method execution from the		message exchange which delineates the first method execution from the
next. See Section 4.7 for a detailed discussion on NAP/ISP separate		next. See Section 4.7 for a detailed discussion on separate NAP and
authentication.		ISP authentication.
The result of PANA authentication is carried in a PANA-Bind-Request		The result of PANA authentication is carried in a PANA-Bind-Request
message sent from PAA to PaC. This message carries the final EAP		message sent from PAA to PaC. This message carries the final EAP
authentication method message (whether it is the second method of NAP		authentication result (whether it is the second EAP authentication
and ISP separate authentication, or the sole authentication method)		result of NAP and ISP separate authentication, or the sole EAP
and the result of PANA authentication. The PANA-Bind-Request message		authentication result) and the result of PANA authentication. The
MUST be acknowledged with a PANA-Bind-Answer (PBA) message. Figure 4		PANA-Bind-Request message MUST be acknowledged with a
shows an example sequence in an authentication phase (no separate		PANA-Bind-Answer (PBA) message. Figure 4 shows an example sequence
		in the authentication and authorization phase (no separate
authentication).		authentication).
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(seqno)[AVPs]
--------------------------------------------------------------------		--------------------------------------------------------------------
(continued from discovery and handshake phase)		(continued from the discovery and handshake phase)
<----- PANA-Auth-Request(x+1)		<----- PANA-Auth-Request(x+1)
[Session-Id, EAP{Request}]		[Session-Id, EAP{Request}]
-----> PANA-Auth-Answer(x+1) // No piggybacking EAP-Response		-----> PANA-Auth-Answer(x+1) // No piggybacking EAP-Response
[Session-Id]		[Session-Id]
-----> PANA-Auth-Request(y)		-----> PANA-Auth-Request(y)
[Session-Id, EAP{Response}]		[Session-Id, EAP{Response}]
<----- PANA-Auth-Answer(y)		<----- PANA-Auth-Answer(y)
[Session-Id]		[Session-Id]
<----- PANA-Auth-Request(x+2)		<----- PANA-Auth-Request(x+2)
[Session-Id, EAP{Request}]		[Session-Id, EAP{Request}]
-----> PANA-Auth-Answer(x+2) // Piggybacking EAP-Response		-----> PANA-Auth-Answer(x+2) // Piggybacking EAP-Response
[Session-Id, EAP{Response}]		[Session-Id, EAP{Response}]
<----- PANA-Bind-Request(x+3)		<----- PANA-Bind-Request(x+3)
[Session-Id, EAP{Success}, Device-Id,		[Session-Id, EAP{Success}, Device-Id,
Lifetime, Protection-Cap., PPAC, MAC]		Lifetime, Protection-Cap., PPAC, MAC]
-----> PANA-Bind-Answer(x+3)		-----> PANA-Bind-Answer(x+3)
[Session-Id, Device-Id, PPAC, MAC]		[Session-Id, Device-Id, PPAC, MAC]
Figure 4: Example Sequence in Authentication Phase		Figure 4: Example Sequence in Authentication and Authorization Phase
When an EAP method that is capable of deriving keys is used during		When an EAP method that is capable of deriving keys is used during
the authentication phase and the keys are successfully derived, the		the authentication and authorization phase and the keys are
PANA message that carries the EAP Success		successfully derived, the PANA message that carries the EAP Success
(PANA-FirstAuth-End-Request, PANA-Bind-Request) and any subsequent		(PANA-FirstAuth-End-Request, PANA-Bind-Request) and any subsequent
message MUST contain a MAC AVP.		message MUST contain a MAC AVP.
The PANA-Bind-Request and the PANA-Bind-Answer message exchange is		The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
also used for binding device identifiers of the PaC and EP(s), and		also used for binding device identifiers of the PaC and EP(s), and
the IP address of the PAA to the PANA SA. To achieve this, the		the IP address of the PAA to the PANA SA. To achieve this, the
PANA-Bind-Request SHOULD contain the device identifier(s) of the		PANA-Bind-Request SHOULD contain the device identifier(s) of the
EP(s) in Device-Id AVP(s) when they are either MAC or IP address(es),		EP(s) in Device-Id AVP(s) when they are either MAC or IP address(es),
and the IP address of the PAA in an IP-Address AVP. PANA-Bind-Answer		and the IP address of the PAA in an IP-Address AVP. PANA-Bind-Answer
SHOULD contain PaC's device identifier in a Device-Id AVP when it is		SHOULD contain PaC's device identifier in a Device-Id AVP when it is
Skipping to change at page 17, line 5:
This exchange when protected by a MAC AVP prevents man-in-the-middle		This exchange when protected by a MAC AVP prevents man-in-the-middle
attacks. The PANA-Bind-Request message MAY also contain a		attacks. The PANA-Bind-Request message MAY also contain a
Protection-Capability AVP to indicate if link-layer or network-layer		Protection-Capability AVP to indicate if link-layer or network-layer
ciphering should be initiated after PANA. No link-layer or		ciphering should be initiated after PANA. No link-layer or
network-layer specific information is included in the		network-layer specific information is included in the
Protection-Capability AVP. It is assumed that the PAA is aware of		Protection-Capability AVP. It is assumed that the PAA is aware of
the security capabilities of the access network. The PANA protocol		the security capabilities of the access network. The PANA protocol
does not specify how the PANA SA and the Protection-Capability AVP		does not specify how the PANA SA and the Protection-Capability AVP
will be used to provide per-packet protection for data traffic.		will be used to provide per-packet protection for data traffic.
Additionally, the PANA-Bind-Request message MUST include a		Additionally, the PANA-Bind-Request message with a PANA_SUCCESS
Post-PANA-Address-Configuration (PPAC) AVP, which helps the PAA to		result code MUST include a Post-PANA-Address-Configuration (PPAC)
inform the PaC about whether a new IP address MUST be configured and		AVP, which helps the PAA to inform the PaC about whether a new IP
the available methods to do so. The PaC MUST include a PPAC AVP in		address MUST be configured and the available methods to do so. The
order to indicate its choice of method when there is a match between		PaC MUST include a PPAC AVP in order to indicate its choice of method
the methods offered by the PAA and the methods available on the PaC.		when there is a match between the methods offered by the PAA and the
When there is no match, a PPAC AVP MUST NOT be included and the		methods available on the PaC. When there is no match, the PaC MUST
Result-Code AVP MUST be set to PANA_PPAC_CAPABILITY_UNSUPPORTED in		send a PANA-Error-Request message with a
the PANA-Bind-Answer message.		PANA_PPAC_CAPABILITY_UNSUPPORTED result code and terminate the PANA
		session.
PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted		PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted
based on the retransmission rule described in Section 5.2.		based on the retransmission rule described in Section 5.2.
EAP authentication can fail at a pass-through authenticator without		EAP authentication can fail at a pass-through authenticator without
sending an EAP-Failure message [I-D.ietf-eap-statemachine]. When		sending an EAP-Failure message [I-D.ietf-eap-statemachine]. When
this occurs, the PAA SHOULD send a PANA-Error-Request message to the		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		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		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		layer. In any case, a more appropriate way is to rely on a timeout
on the PaC.		on the PaC.
There is a case where EAP authentication succeeds with producing an		There is a case where EAP authentication succeeds with producing an
EAP-Success message but network access authorization fails due to,		EAP-Success message but network access authorization fails due to,
e.g., authorization rejected by a AAA proxy or authorization locally		e.g., authorization rejected by a AAA or authorization locally
rejected by the PAA. When this occurs, the PAA MUST send		rejected by the PAA. When this occurs, the PAA MUST send
PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED. If		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		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		the EAP-Success message is generated by the EAP server (this is the
case when the EAP method provides protected success indication), this		case when the EAP method provides protected success indication), this
PANA-Bind message exchange MUST be protected with a MAC AVP and carry		PANA-Bind message exchange MUST be protected with a MAC AVP and carry
a Key-Id AVP. The AAA-Key and the PANA session MUST be deleted		a Key-Id AVP. The AAA-Key and the PANA session MUST be deleted
immediately after the PANA-Bind message exchange.		immediately after the PANA-Bind message exchange.
4.4 Authorization Phase		4.4 Access Phase
Once an authentication phase or a re-authentication phase		Once the authentication and authorization phase or the
successfully completes, the PaC gains access to the network and can		re-authentication phase successfully completes, the PaC gains access
send and receive IP data traffic through EP and the PANA session		to the network and can send and receive IP data traffic through EP
enters an authorization phase. In this phase, PANA-Ping-Request and		and the PANA session enters the access phase. In this phase,
PANA-Ping-Answer messages can be used for testing the liveness of the		PANA-Ping-Request and PANA-Ping-Answer messages can be used for
PANA session on the PANA peer. Both the PaC and the PAA are allowed		testing the liveness of the PANA session on the PANA peer. Both the
to send a PANA-Ping-Request message to the communicating peer		PaC and the PAA are allowed to send a PANA-Ping-Request message to
whenever they need to make sure the availability of the session on		the communicating peer whenever they need to make sure the
the peer and expect the peer to return a PANA-Ping-Answer message.		availability of the session on the peer and expect the peer to return
Both PANA-Ping-Request and PANA-Ping-Answer messages MUST be		a PANA-Ping-Answer message. Both PANA-Ping-Request and
protected with a MAC AVP when a PANA SA is available.		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		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		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		to perform any coordination with each other. There is no negotiation
of timers for this purpose.		of timers for this purpose.
Figure 5 and Figure 6 show liveness tests as they are initiated by		Figure 5 and Figure 6 show liveness tests as they are initiated by
the PaC and the PAA respectively.		the PaC and the PAA respectively.
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(seqno)[AVPs]
Skipping to change at page 18, line 27:
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(seqno)[AVPs]
------------------------------------------------------		------------------------------------------------------
<----- PANA-Ping-Request(p)[Session-Id, MAC]		<----- PANA-Ping-Request(p)[Session-Id, MAC]
-----> PANA-Ping-Answer(p)[Session-Id, MAC]		-----> PANA-Ping-Answer(p)[Session-Id, MAC]
Figure 6: Example Sequence for PAA-initiated liveness test		Figure 6: Example Sequence for PAA-initiated liveness test
4.5 Re-authentication Phase		4.5 Re-authentication Phase
A PANA session in an authorization phase can enter a		A PANA session in the access phase can enter the re-authentication
re-authentication phase to extend the current session lifetime by		phase to extend the current session lifetime by re-executing EAP.
re-executing EAP. Once the re-authentication phase successfully		Once the re-authentication phase successfully completes, the session
completes, the session re-enters the authorization phase. Otherwise,		re-enters the access phase. Otherwise, the session is deleted.
the session is deleted.
When a PaC wants to initiate re-authentication, it sends a		When a PaC wants to initiate re-authentication, it sends a
PANA-Reauth-Request message to the PAA. This message MUST contain a		PANA-Reauth-Request message to the PAA. This message MUST contain a
Session-Id AVP which is used for identifying the PANA session on the		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		PAA. If the PAA already has an established PANA session for the PaC
with the matching identifier, it MUST first respond with a		with the matching identifier, it MUST first respond with a
PANA-Reauth-Answer, followed by a PANA-Auth-Request that starts a new		PANA-Reauth-Answer, followed by a PANA-Auth-Request that starts a new
EAP authentication. If PAA cannot identify the session, it MUST		EAP authentication. If PAA cannot identify the session, it MUST
respond with a PANA-Error-Request with the error code		respond with a PANA-Error-Request with the error code
PANA_UNKNOWN_SESSION_ID. PANA-Reauth-Request/Answer messages MUST		PANA_UNKNOWN_SESSION_ID. PANA-Reauth-Request/Answer messages MUST
Skipping to change at page 19, line 8:
PaC may receive a PANA-Auth-Request before receiving the answer to		PaC may receive a PANA-Auth-Request before receiving the answer to
its outstanding PANA-Reauth-Request. This condition can arise due 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		packet re-ordering or a race condition between the PaC and PAA when
they both attempt to engage in re-authentication. PaC MUST keep		they both attempt to engage in re-authentication. PaC MUST keep
discarding the received PANA-Auth-Requests until it receives the		discarding the received PANA-Auth-Requests until it receives the
answer to its request.		answer to its request.
When the PAA initiates re-authentication, it sends a		When the PAA initiates re-authentication, it sends a
PANA-Auth-Request message containing the session identifier for the		PANA-Auth-Request message containing the session identifier for the
PaC to enter an authentication phase. PAA SHOULD initiate EAP		PaC to enter the re-authentication phase. PAA SHOULD initiate EAP
authentication before the current session lifetime expires.		re-authentication before the current session lifetime expires.
Re-authentication of an on-going PANA session MUST maintain the		Re-authentication of an on-going PANA session MUST maintain the
existing sequence numbers.		existing sequence numbers.
For any re-authentication, if there is an established PANA SA,		For any re-authentication, if there is an established PANA SA,
PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by		PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by
adding a MAC AVP to each message. Any subsequent EAP-based		adding a MAC AVP to each message. Any subsequent EAP-based
authentication MUST be performed with the same ISP and NAP that was		authentication MUST be performed with the same ISP and NAP that was
selected during the initial authentication. An example sequence for		selected during the initial authentication. An example sequence for
a re-authentication initiated by a PaC is shown in Figure 7.		a re-authentication initiated by a PaC is shown in Figure 7.
Skipping to change at page 20, line 20:
the PAA, all messages exchanged during the termination phase MUST be		the PAA, all messages exchanged during the termination phase MUST be
protected with a MAC AVP. When the sender of the		protected with a MAC AVP. When the sender of the
PANA-Termination-Request receives a valid acknowledgment, all states		PANA-Termination-Request receives a valid acknowledgment, all states
maintained for the PANA session MUST be deleted immediately.		maintained for the PANA session MUST be deleted immediately.
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(seqno)[AVPs]
------------------------------------------------------		------------------------------------------------------
-----> PANA-Termination-Request(q)[Session-Id, MAC]		-----> PANA-Termination-Request(q)[Session-Id, MAC]
<----- PANA-Termination-Answer(q)[Session-Id, MAC]		<----- PANA-Termination-Answer(q)[Session-Id, MAC]
Figure 8: Example Sequence for Session Termination		Figure 8: Example Sequence for Session Termination Triggered by PaC
4.7 Separate NAP and ISP Authentication		4.7 Separate NAP and ISP Authentication
PANA allows running at most two EAP sessions in sequence in an		PANA allows running at most two EAP sessions in sequence in the
authentication phase to support separate NAP and ISP authentication		authentication and authorization phase to support separate NAP and
as described in this section. A typical network access		ISP authentication as described in this section. A typical network
authentication includes execution of one EAP method with the ISP.		access authentication includes execution of one EAP method with the
This separation allows PaC to perform an additional authentication		ISP. This separation allows PaC to perform an additional
method for receiving differentiated services from the NAP.		authentication method for receiving differentiated services from the
		NAP.
Currently, running multiple EAP sessions in sequence in an		Currently, running multiple EAP sessions in sequence in the
authentication phase is designed only for separate NAP and ISP		authentication and authorization phase is designed only for separate
authentication. It is not for running arbitrary number of EAP		NAP and ISP authentication. It is not for running arbitrary number
sessions in sequence, or giving the PaC another chance to try another		of EAP sessions in sequence, or giving the PaC another chance to try
EAP authentication method within an integrated NAP and ISP		another EAP authentication method within an integrated NAP and ISP
authentication when an EAP authentication method fails.		authentication when an EAP authentication method fails.
Within separate NAP and ISP authentication, the NAP authentication		Within separate NAP and ISP authentication, the NAP authentication
and the ISP authentication are considered completely independent.		and the ISP authentication are considered completely independent.
Presence or success of one should not effect the other. Making a		Presence or success of one should not effect the other. Making a
network access authorization decision based on the success or failure		network access authorization decision based on the success or failure
of each authentication is a network policy issue.		of each authentication is a network policy issue.
4.7.1 Negotiating Separate NAP and ISP Authentication		4.7.1 Negotiating Separate NAP and ISP Authentication
Skipping to change at page 22, line 36:
When the PaC and PAA have negotiated in the discovery and handshake		When the PaC and PAA have negotiated in the discovery and handshake
phase to perform separate NAP and ISP authentication, if the		phase to perform separate NAP and ISP authentication, if the
lower-layer is insecure, the two EAP authentication methods used in		lower-layer is insecure, the two EAP authentication methods used in
the separate authentication MUST be capable of deriving keys. In		the separate authentication MUST be capable of deriving keys. In
this case, if the first EAP authentication is successful, the		this case, if the first EAP authentication is successful, the
PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as		PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as
well as PANA-Auth-Request and PANA-Auth-Answer messages in the second		well as PANA-Auth-Request and PANA-Auth-Answer messages in the second
EAP authentication MUST be protected with the key derived from the		EAP authentication MUST be protected with the key derived from the
AAA-Key for the first EAP authentication. The PANA-Bind-Request and		AAA-Key for the first EAP authentication. The PANA-Bind-Request and
PANA-Bind-Answer messages and all subsequent PANA messages exchanged		PANA-Bind-Answer messages and all subsequent PANA messages exchanged
in authorized phase, re-authentication phase and termination phase		in the access phase, re-authentication phase and termination phase
MUST be protected either with the AAA-Key for the first EAP		MUST be protected either with the AAA-Key for the first EAP
authentication if the first EAP authentication succeeds and the		authentication if the first EAP authentication succeeds and the
second EAP authentication fails, or with the AAA-Key for the second		second EAP authentication fails, or with the AAA-Key for the second
EAP authentication if the first EAP authentication fails and the		EAP authentication if the first EAP authentication fails and the
second EAP authentication succeeds, or with the compound AAA-Key		second EAP authentication succeeds, or with the compound AAA-Key
derived from the two AAA-Keys, one for the first EAP authentication		derived from the two AAA-Keys, one for the first EAP authentication
and the other from the second EAP authentication, if both the first		and the other from the second EAP authentication, if both the first
and second EAP authentications succeed.		and second EAP authentications succeed.
5. Protocol Design Details and Processing Rules		5. Protocol Design Details and Processing Rules
Skipping to change at page 23, line 31:
PANA uses sequence numbers to provide ordered and reliable delivery		PANA uses sequence numbers to provide ordered and reliable delivery
of messages.		of messages.
PaC and PAA maintain two sequence numbers: the next one to be used		PaC and PAA maintain two sequence numbers: the next one to be used
for a request it initiates and the next one it expects to see in a		for a request it initiates and the next one it expects to see in a
request from the other end. These sequence numbers are 32-bit		request from the other end. These sequence numbers are 32-bit
unsigned numbers. They are monotonically incremented by 1 as new		unsigned numbers. They are monotonically incremented by 1 as new
requests are generated and received, and wrapped to zero on the next		requests are generated and received, and wrapped to zero on the next
message after 2^32-1. Answers always contain the same sequence		message after 2^32-1. Answers always contain the same sequence
number as the corresponding request. Retransmissions maintain the		number as the corresponding request. Retransmissions reuse the
same sequence number.		sequence number contained in the original packet.
The initial sequence numbers (ISN) are randomly picked by PaC and PAA		The initial sequence numbers (ISN) are randomly picked by PaC and PAA
as they send their very first request messages. PANA-PAA-Discover		as they send their very first request messages. PANA-PAA-Discover
message carries sequence number 0.		message carries sequence number 0.
When a request message is received, it is considered valid in terms		When a request message is received, it is considered valid in terms
of sequence numbers if and only if its sequence number matches the		of sequence numbers if and only if its sequence number matches the
expected value. This check does not apply to PANA-PAA-Discover, and		expected value. This check does not apply to PANA-PAA-Discover, and
the very first request messages.		the very first request messages.
When an answer message is received, it is considered valid in terms		When an answer message is received, it is considered valid in terms
of sequence numbers if and only if its sequence number matches that		of sequence numbers if and only if its sequence number matches that
of the currently outstanding request. A peer can only have one		of the currently outstanding request. A peer can only have one
outstanding request at a time.		outstanding request at a time.
PANA request messages are retransmitted based on a timer until a		PANA messages are retransmitted based on a timer until a response is
response is received (in which case the retransmission timer is		received (in which case the retransmission timer is stopped) or the
stopped) or the number of retransmission reaches the maximum value		number of retransmission reaches the maximum value (in which case the
(in which case the PANA session MUST be deleted immediately).		PANA session MUST be deleted immediately).
The initial discovery and handshake phase requires special handling.		The initial discovery and handshake phase requires special handling.
PaC MUST retransmit PANA-PAA-Discover if a subsequent		PaC MUST retransmit PANA-PAA-Discover if a subsequent
PANA-Start-Request is not received in time. Even though a		PANA-Start-Request is not received in time. Even though a
PANA-Start-Request is received, PANA-PAA-Discover may still have to		PANA-Start-Request is received, PANA-PAA-Discover may still have to
be retransmitted. This is because a stateless PAA discovery requires		be retransmitted. This is because a stateless PAA discovery requires
one time transmission of a solicited PANA-Start-Request. PAA MUST		one time transmission of a solicited PANA-Start-Request. PAA MUST
NOT start a timer and retransmit the request in order to avoid state		NOT start a timer and retransmit the request in order to avoid state
creation. If the received PANA-Start-Request included a Cookie AVP		creation. If the received PANA-Start-Request included a Cookie AVP
(an indication of stateless discovery), PaC MUST retransmit		(an indication of stateless discovery), PaC MUST retransmit
PANA-PAA-Discover until the first PANA-Auth-Request is received.		PANA-PAA-Discover until the first PANA-Auth-Request is received.
Otherwise, PaC can rely on PAA to retransmit the PANA-Start-Requests		Otherwise, PaC can rely on PAA to retransmit the PANA-Start-Requests
as soon as PaC receives the first one (i.e., PaC can stop sending		as soon as PaC receives the first one (i.e., PaC can stop sending
PANA-PAA-Discover).		PANA-PAA-Discover).
The retransmission timers SHOULD be calculated as described in		The retransmission timers SHOULD be calculated as described in
[RFC2988] to provide congestion control. See Section 9 for default		[RFC2988] to provide congestion control. See Section 8 for default
timer and maximum retransmission count parameters.		timer and maximum retransmission count parameters.
PaC and PAA MUST respond to duplicate requests. Last transmitted		PaC and PAA MUST respond to duplicate requests. Last transmitted
PANA answer MAY be cached in case it is not received by the peer and		PANA answer MAY be cached in case it is not received by the peer and
that generates a retransmission of the last request. When available,		that generates a retransmission of the last request. When available,
a cached answer can be used instead of fully processing the		a cached answer can be used instead of fully processing the
retransmitted request and forming a new answer from scratch.		retransmitted request and forming a new answer from scratch.
PANA MUST NOT generate EAP message duplication. EAP payload of a		PANA MUST NOT generate EAP message duplication. EAP payload of a
retransmitted PANA message MUST NOT be passed to the EAP layer.		retransmitted PANA message MUST NOT be passed to the EAP layer.
5.3 PANA Security Association		5.3 PANA Security Association
A PANA SA is created as an attribute of a PANA session when EAP		A PANA SA is created as an attribute of a PANA session when EAP
authentication succeeds with a creation of a AAA-Key. A PANA SA is		authentication succeeds with a creation of a AAA-Key. A PANA SA is
not created when the PANA authentication fails or no AAA-Key is		not created when the PANA authentication fails or no AAA-Key is
produced by any EAP authentication method. In the case where two EAP		produced by any EAP authentication method. In the case where two EAP
authentications are performed in sequence in a single PANA		authentications are performed in sequence in the PANA authentication
authentication phase, it is possible that two AAA-Keys are derived.		and authorization phase, it is possible that two AAA-Keys are
If this happens, the PANA SA MUST be generated from both AAA-Keys.		derived. If this happens, the PANA SA MUST be generated from both
When a new AAA-Key is derived as a result of EAP-based		AAA-Keys. When a new AAA-Key is derived as a result of EAP-based
re-authentication, any key derived from the old AAA-Key MUST be		re-authentication, any key derived from the old AAA-Key MUST be
updated to a new one that is derived from the new AAA-Key. In order		updated to a new one that is derived from the new AAA-Key. In order
to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be		to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be
carried in PANA-Bind-Request and PANA-Bind-Answer messages or		carried in PANA-Bind-Request and PANA-Bind-Answer messages or
PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at		PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at
the end of the EAP authentication which resulted in deriving a new		the end of the EAP authentication which resulted in deriving a new
AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a		AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a
value that uniquely identifies the AAA-Key within the PANA session.		value that uniquely identifies the AAA-Key within the PANA session.
The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer		The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer
message) sent in response to a PANA-Bind-Request message (or a		message) sent in response to a PANA-Bind-Request message (or a
PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a		PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a
Key-Id AVP with the same AAA-Key identifier carried in the request.		Key-Id AVP with the same AAA-Key identifier carried in the request.
PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and		PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and
PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry		PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry
a MAC AVP whose value is computed by using the new PANA-MAC-KEY		a MAC AVP whose value is computed by using the new PANA_MAC_KEY
derived from the new AAA-Key (or the new pair of AAA-Keys when the		derived from the new AAA-Key (or the new pair of AAA-Keys when the
PANA_MAC_KEY is derived from two AAA-Keys). Although the		PANA_MAC_KEY is derived from two AAA-Keys). Although the
specification does not mandate a particular method for calculation of		specification does not mandate a particular method for calculation of
Key-Id AVP value, a simple method is to use monotonically increasing		Key-Id AVP value, a simple method is to use monotonically increasing
numbers.		numbers.
The created PANA SA is deleted when the corresponding PANA session is		The PANA session lifetime is bounded by the lifetime granted by the
deleted. The lifetime of the PANA SA is the same as the lifetime of		authentication server (same as AAA-Key lifetime). The lifetime of
the PANA session for simplicity.		the PANA SA (hence the PANA_MAC_KEY) is the same as the lifetime of
		the PANA session. The created PANA SA is deleted when the
		corresponding PANA session is deleted.
PANA SA attributes as well as PANA session attributes are listed		PANA SA attributes as well as PANA session attributes are listed
below:		below:
PANA Session attributes:		PANA Session attributes:
* Session-Id		* Session-Id
* Device-Id of PaC		* Device-Id of PaC
Skipping to change at page 27, line 17:
When a PANA message is received, the message is considered to be		When a PANA message is received, the message is considered to be
invalid at least when one of the following conditions are not met:		invalid at least when one of the following conditions are not met:
o The IP Hop Limit (or TTL) field has a value of 255, i.e., the		o The IP Hop Limit (or TTL) field has a value of 255, i.e., the
packet could not possibly have been forwarded by a router.		packet could not possibly have been forwarded by a router.
o Each field in the message header contains a valid value including		o Each field in the message header contains a valid value including
sequence number, message length, message type, version number,		sequence number, message length, message type, version number,
flags, etc.		flags, etc.
o When a device identifier of the PaC is bound to the PANA session,
it matches the device identifier carried in MAC or or IP header,
or other locally-significant identifier provided by the
lower-layers (e.g., circuit ID) unless the message is a
PANA-Update-Request with an IP-Address AVP.
o The message type is one of the expected types in the current		o The message type is one of the expected types in the current
state. Specifically the following messages are unexpected and		state. Specifically the following messages are unexpected and
invalid:		invalid:
* In discovery and handshake phase:		* In the discovery and handshake phase:
+ PANA-Termination-Request and PANA-Ping-Request.		+ PANA-Termination-Request and PANA-Ping-Request.
+ PANA-Bind-Request.		+ PANA-Bind-Request.
+ PANA-Update-Request.		+ PANA-Update-Request.
* In authentication phase:		* In the authentication and authorization phase:
+ PANA-PAA-Discover.		+ PANA-PAA-Discover.
+ PANA-Update-Request.		+ PANA-Update-Request.
+ PANA-Start-Request after a PaC receives the first valid		+ PANA-Start-Request after a PaC receives the first valid
PANA-Auth-Request.		PANA-Auth-Request.
+ PANA-Termination-Request before the PaC receives the first		+ PANA-Termination-Request before the PaC receives the first
successful PANA-Bind-Request.		successful PANA-Bind-Request.
* Authorized phase:		* In the access phase:
+ PANA-Start-Request as well as a non-duplicate		+ PANA-Start-Request as well as a non-duplicate
PANA-Bind-Request.		PANA-Bind-Request.
+ PANA-PAA-Discover.		+ PANA-PAA-Discover.
* In termination phase:		* In the termination phase:
+ PANA-PAA-Discover.		+ PANA-PAA-Discover.
+ All requests but PANA-Termination-Request.		+ All requests but PANA-Termination-Request.
o The message payload contains a valid set of AVPs allowed for the		o The message payload contains a valid set of AVPs allowed for the
message type and there is no missing AVP that needs to be included		message type and there is no missing AVP that needs to be included
in the payload.		in the payload.
o Each AVP is decoded correctly.		o Each AVP is decoded correctly.
Skipping to change at page 29, line 36:
new PaC address in an IP-Address AVP. If the address contained in		new PaC address in an IP-Address AVP. If the address contained in
the request is invalid, the PAA MUST send a PANA-Error message with		the request is invalid, the PAA MUST send a PANA-Error message with
the result code PANA_INVALID_IP_ADDRESS. Otherwise, the PAA MUST		the result code PANA_INVALID_IP_ADDRESS. Otherwise, the PAA MUST
update the PANA session with the new PaC address and return a		update the PANA session with the new PaC address and return a
PANA-Update-Answer message. If there is an established PANA SA, both		PANA-Update-Answer message. If there is an established PANA SA, both
PANA-Update-Request and PANA-Update-Answer messages MUST be protected		PANA-Update-Request and PANA-Update-Answer messages MUST be protected
with a MAC AVP.		with a MAC AVP.
5.8 Session Lifetime		5.8 Session Lifetime
The authentication phase determines the PANA session lifetime when		The authentication and authorization phase determines the PANA
the network access authorization succeeds. The Session-Lifetime AVP		session lifetime when the network access authorization succeeds. The
MAY be optionally included in the PANA-Bind-Request message to inform		Session-Lifetime AVP MAY be optionally included in the
PaC about the valid lifetime of the PANA session. It MUST be ignored		PANA-Bind-Request message to inform PaC about the valid lifetime of
when included in other PANA messages.		the PANA session. It MUST be ignored when included in other PANA
		messages.
The lifetime is a non-negotiable parameter that can be used by PaC to		The lifetime is a non-negotiable parameter that can be used by PaC to
manage PANA-related state. PaC does not have to perform any actions		manage PANA-related state. PaC does not have to perform any actions
when the lifetime expires, other than optionally purging local state.		when the lifetime expires, other than optionally purging local state.
PAA SHOULD initiate EAP authentication before the current session		PAA SHOULD initiate EAP re-authentication before the current session
lifetime expires.		lifetime expires.
PaC and PAA MAY optionally rely on lower-layer indications to		PaC and PAA MAY optionally rely on lower-layer indications to
expedite the detection of a disconnected peer. Availability and		expedite the detection of a disconnected peer. Availability and
reliability of such indications depend on the specific access		reliability of such indications depend on the specific access
technologies. PANA peer can use PANA-Ping-Request message to verify		technologies. PANA peer can use PANA-Ping-Request message to verify
the disconnection before taking an action.		the disconnection before taking an action.
The session lifetime parameter is not related to the transmission of		The session lifetime parameter is not related to the transmission of
PANA-Ping-Request messages. These messages can be used for		PANA-Ping-Request messages. These messages can be used for
asynchronously verifying the liveness of the peer. The decision to		asynchronously verifying the liveness of the peer. The decision to
send PANA-Ping-Request message is taken locally and does not require		send PANA-Ping-Request message is taken locally and does not require
coordination between the peers.		coordination between the peers.
When separate ISP and NAP authentication is performed, it is possible		When separate ISP and NAP authentication is performed, it is possible
that different authorization lifetime values are associated with the		that different authorization lifetime values are associated with the
two authentications. In this case, the smaller authorization		two authentications. In this case, the smaller authorization
lifetime value MUST be used for calculating the PANA Session-Lifetime		lifetime value MUST be used for calculating the PANA Session-Lifetime
value. As a result, when entering a re-authentication phase, both		value. As a result, both NAP and ISP authentication will be
NAP and ISP authentication will be performed in the same		performed in the re-authentication phase.
re-authentication phase.
5.9 Network Selection		5.9 Network Selection
In a discovery and handshake phase, a PANA-Start-Request message sent		In the discovery and handshake phase, a PANA-Start-Request message
from the PAA MAY contain zero or one NAP-Information AVP and zero or		sent from the PAA MAY contain zero or one NAP-Information AVP and
more ISP-Information AVPs to advertise the information on the NAP		zero or more ISP-Information AVPs to advertise the information on the
and/or ISPs. The PaC MAY indicate its choice of ISP by including an		NAP and/or ISPs. The PaC MAY indicate its choice of ISP by including
ISP-Information AVP in the PANA-Start-Answer message. When a AAA		an ISP-Information AVP in the PANA-Start-Answer message. The PaC can
backend is used, the identity of the destination AAA server or realm		choose an ISP and contain an ISP-Information AVP for the chosen ISP
MUST be determined based on the explicitly chosen ISP. When the		in a PANA-Start-Answer message even when there is no ISP-Information
ISP-Information AVP is not present, the access network MAY rely on		AVP contained in the PANA-Start-Request message. When an
the client identifier carried in the EAP authentication method to		ISP-Information AVP is not present in the PANA-Start-Answer message,
make this determination. The PaC can choose an ISP and contain an		a default ISP is automatically chosen by the PAA.
ISP-Information AVP for the chosen ISP in a PANA-Start-Answer message
even when there is no ISP-Information AVP contained in the		The identity of the destination AAA server or realm MAY be determined
PANA-Start-Request message.		based on the the client identifier (e.g., an NAI) carried in the EAP
		authentication method. Note that AAA typically uses the client's NAI
		to route the request to an appropriate home server. PANA's ISP
		selection mechanism does not preclude the use of roaming. That is,
		the realm provided in the NAI may not match the chosen ISP; all that
		is required is that the chosen ISP is capable of routing the request
		to the realm in the NAI. As a result, PANA's ISP selection feature
		does not affect the NAI but rather the next hop AAA entity from the
		PAA. Note that this may limit the ability of the access network to
		use a local AAA proxy for all outgoing traffic, assuming ISP
		selection is needed. This is because the PAA can only affect the
		next hop selection at the PAA, and it may not have means to present a
		"source route" to the next hop proxy for doing it in the next step.
		In the roaming case, the PAA MAY carry ISP-Information AVPs only for
		ISPs that are directly connected to the access network it resides,
		not for all possible home ISPs.
		In addition to performing network selection by using PANA for
		choosing an ISP, another level of network selection may be performed
		by using EAP for choosing AAA intermediaries
		[I-D.adrangi-eap-network-discovery]. The latter network selection
		occurs over EAP in the authentication and authorization phase after
		completion of the former network selection in the discovery and
		handshake phase, possibly in the scope of the chosen ISP.
5.10 Error Handling		5.10 Error Handling
A PANA-Error-Request message MAY be sent by either the PaC or the PAA		A PANA-Error-Request message MAY be sent by either the PaC or the PAA
when a badly formed PANA message is received or in case of other		when a badly formed PANA message is received or in case of other
errors. The receiver of this request MUST respond with a		errors. The receiver of this request MUST respond with a
PANA-Error-Answer message. If the cause of this error message was a		PANA-Error-Answer message. If the cause of this error message was a
request message (e.g., PANA-PAA-Discover or *-Request), then the		request message (e.g., PANA-PAA-Discover or *-Request), then the
request MAY be retransmitted immediately without waiting for its		request MAY be retransmitted immediately without waiting for its
retransmission timer to go off. If the cause of the error was a		retransmission timer to go off. If the cause of the error was a
Skipping to change at page 32, line 5:
having tp respond to bogus packets. Limiting the number of error		having tp respond to bogus packets. Limiting the number of error
notifications sent to a given peer during a (configurable) period of		notifications sent to a given peer during a (configurable) period of
time may be useful.		time may be useful.
When an error message is sent unprotected (i.e., no MAC AVP) and the		When an error message is sent unprotected (i.e., no MAC AVP) and the
lower-layer is insecure, the error message is treated as an		lower-layer is insecure, the error message is treated as an
informational message. The receiver of such an error message MUST		informational message. The receiver of such an error message MUST
NOT change its state unless the error persists and the PANA session		NOT change its state unless the error persists and the PANA session
is not making any progress.		is not making any progress.
6. Mobility		6. PANA Headers and Formats
A mobile PaC's network access authentication performance can be
enhanced by deploying a context-transfer-based mechanism, where some
session attributes are transferred from the previous PAA to the new
one in order to avoid performing a full EAP authentication (reactive
approach). Additional mechanisms that are based on the proactive AAA
state establishment at one or more candidate PAAs may be developed in
the future [I-D.irtf-aaaarch-handoff]. The details of a
context-transfer-based mechanism is provided in this section.
Upon changing its point of attachment, a PaC that wants to quickly
resume its ongoing PANA session without running EAP MAY send its
unexpired PANA session identifier in its PANA-Start-Answer message.
Along with the Session-Id AVP, a MAC AVP MUST be included in this
message. The MAC AVP is computed by using the PANA_MAC_KEY shared
between the PaC and its previous PAA that has an unexpired PANA
session with the PaC. This action signals PaC's desire to perform
the mobility optimization. In the absence of a Session-Id AVP in
this message, the PANA session takes its usual course (i.e.,
EAP-based authentication is performed).
If a PAA receives a session identifier in the PANA-Start-Answer
message, and it is configured to enable this optimization, it SHOULD
retrieve the PANA session attributes from the previous PAA. Current
PAA determines the identity of the previous PAA by looking at the
DiameterIdentity part of the PANA session identifier. The MAC AVP
can only be verified by the previous PAA, therefore a copy of the
PANA message MUST be provided to the previous PAA. The mechanism
required to send a copy of the PANA-Start-Answer message from current
PAA to the previous PAA, and retrieve the session attributes is
outside the scope of PANA protocol. The Context Transfer Protocol
[I-D.ietf-seamoby-ctp] might be useful for this purpose.
When the previous or current PAA is not configured to enable this
optimization, the current PAA can not retrieve the PANA session
attributes, or the PANA session has already expired (i.e., session
lifetime is zero), the PAA MUST send the PANA-Auth-Request message
with a new session identifier and let the PANA exchange take its
usual course. This action will engage EAP-based authentication and
create a fresh PANA session from scratch.
In case the current PAA can retrieve the on-going PANA session
attributes from the previous PAA, the PANA session continues with a
PANA-Bind exchange.
As part of the context transfer, an intermediate AAA-Key material is
provided by the previous PAA to the current PAA.
AAA-Key-int = The first N bits of
HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)
The value of N depends on the integrity protection algorithm in use,
i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the
current PAA. Session-ID is the identifier of the PaC's PANA session
with the previous PAA.
The current PAA and PaC compute the new AAA-Key by using the nonce
values and the AAA-Key-int.
AAA-Key-new = The first N bits of
HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce)
New PANA_MAC_KEY is computed based on the algorithm described in
Section 5.3, by using the new AAA-Key and the new Session-ID assigned
by the current PAA. The MAC AVP contained in the PANA-Bind-Request
and PANA-Bind-Answer messages MUST be generated and verified by using
the new PANA_MAC_KEY. The Session-ID AVP MUST include a new session
identifier assigned by the current PAA. A new PANA session is
created upon successful completion of this exchange.
Note that correct operation of this optimization relies on many
factors, including applicability of authorization state from one
network attachment to another. [I-D.ietf-eap-keying] identifies this
operation as "fast handoff" and provides deployment considerations.
Operators are recommended to take those guidelines into account when
using this optimization in their networks.
7. PANA Headers and Formats
This section defines message formats for PANA protocol.		This section defines message formats for PANA protocol.
7.1 IP and UDP Headers		6.1 IP and UDP Headers
The Hop Limit (or TTL) field of the IP header MUST be set to 255.		The Hop Limit (or TTL) field of the IP header MUST be set to 255.
When a PANA-PAA-Discover message is multicast, IP destination address		When a PANA-PAA-Discover message is multicast, IP destination address
of the message is set to a well-known link-local multicast address		of the message is set to a well-known link-local multicast address
(TBD). A PANA-PAA-Discover message MAY be unicast in some cases as		(TBD). A PANA-PAA-Discover message MAY be unicast in some cases as
specified in Section 4.2. Any other PANA packet is unicast between		specified in Section 4.2. Any other PANA packet is unicast between
the PaC and the PAA. The source and destination addresses SHOULD be		the PaC and the PAA. The source and destination addresses SHOULD be
set to the addresses on the interfaces from which the message will be		set to the addresses on the interfaces from which the message will be
sent and received, respectively.		sent and received, respectively.
When the PANA packet is sent in response to a request, the UDP source		When the PANA packet is sent in response to a request, the UDP source
and destination ports of the response packet MUST be copied from the		and destination ports of the response packet MUST be copied from the
destination and source ports of the request packet, respectively.		destination and source ports of the request packet, respectively.
The destination port of an unsolicited PANA packet MUST be set to an		The destination port of an unsolicited PANA packet MUST be set to an
assigned value (TBD), and the source port MUST be set to a value		assigned value (TBD), and the source port MUST be set to a value
chosen by the sender.		chosen by the sender.
7.2 PANA Header		The maximum PANA packet size is limited by the maximum UDP payload.
		6.2 PANA Header
A summary of the PANA header format is shown below. The fields are		A summary of the PANA header format is shown below. The fields are
transmitted in network byte order.		transmitted in network byte order.
0 1 2 3		0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Length |		| Version | Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Message Type |		| Flags | Message Type |
Skipping to change at page 35, line 17:
This 8-bit field is reserved for future use, and MUST be set to		This 8-bit field is reserved for future use, and MUST be set to
zero, and ignored by the receiver.		zero, and ignored by the receiver.
Message Length		Message Length
The Message Length field is three octets and indicates the length		The Message Length field is three octets and indicates the length
of the PANA message including the header fields.		of the PANA message including the header fields.
Flags		Flags
The Flags field is eight bits. The following bits are assigned:		The Flags field is two octets. The following bits are assigned:
0 1		0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R S N r r r r r r r r r r r r r|		|R S N r r r r r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R(equest)		R(equest)
If set, the message is a request. If cleared, the message is		If set, the message is a request. If cleared, the message is
Skipping to change at page 35, line 40:
S(eparate)		S(eparate)
When the S-flag is set in a PANA-Start-Request message it		When the S-flag is set in a PANA-Start-Request message it
indicates that PAA is willing to offer separate NAP and ISP		indicates that PAA is willing to offer separate NAP and ISP
authentication. When the S-flag is set in a PANA-Start-Answer		authentication. When the S-flag is set in a PANA-Start-Answer
message it indicates that the PaC accepts on performing		message it indicates that the PaC accepts on performing
separate NAP and ISP authentication. When the S-flag is set in		separate NAP and ISP authentication. When the S-flag is set in
a PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer		a PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer
and PANA-Bind-Request/Answer messages it indicates that		and PANA-Bind-Request/Answer messages it indicates that
separate NAP and ISP authentication is being performed in the		separate NAP and ISP authentication is being performed in the
authentication phase. For other cases, S-flag MUST NOT be set.		authentication and authorization phase. For other cases,
		S-flag MUST NOT be set.
N(AP authentication)		N(AP authentication)
When the N-flag is set in a PANA-Auth-Request message, it		When the N-flag is set in a PANA-Auth-Request message, it
indicates that the current EAP authentication is for NAP		indicates that the current EAP authentication is for NAP
authentication. When the N-flag is unset in a		authentication. When the N-flag is unset in a
PANA-Auth-Request message, it indicates that the current EAP		PANA-Auth-Request message, it indicates that the current EAP
authentication is for ISP authentication. The PaC MUST copy		authentication is for ISP authentication. The PaC MUST copy
the value of the flag in its requests from the last received		the value of the flag in its requests from the last received
request of the PAA. The value of the flag on an answer MUST be		request of the PAA. The value of the flag on an answer MUST be
Skipping to change at page 36, line 25:
space is managed by IANA [ianaweb]. PANA uses its own address		space is managed by IANA [ianaweb]. PANA uses its own address
space for this field.		space for this field.
Sequence Number		Sequence Number
The Sequence Number field contains a 32 bit value.		The Sequence Number field contains a 32 bit value.
AVPs		AVPs
AVPs are a method of encapsulating information relevant to the		AVPs are a method of encapsulating information relevant to the
PANA message. See section Section 7.3 for more information on		PANA message. See section Section 6.3 for more information on
AVPs.		AVPs.
7.3 AVP Header		6.3 AVP Header
Each AVP of type OctetString MUST be padded to align on a 32-bit		Each AVP of type OctetString MUST be padded to align on a 32-bit
boundary, while other AVP types align naturally. A number of		boundary, while other AVP types align naturally. A number of
zero-valued bytes are added to the end of the AVP Data field till a		zero-valued bytes are added to the end of the AVP Data field till a
word boundary is reached. The length of the padding is not reflected		word boundary is reached. The length of the padding is not reflected
in the AVP Length field [RFC3588].		in the AVP Length field [RFC3588].
The fields in the AVP header MUST be sent in network byte order. The		The fields in the AVP header are sent in network byte order. The
format of the header is:		format of the header is:
0 1 2 3		0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Flags |		| AVP Code | AVP Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |		| AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id (opt) |		| Vendor-Id (opt) |
Skipping to change at page 37, line 26:
0 1		0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r r r r r r r r r|		|V M r r r r r r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M(andatory)		M(andatory)
The 'M' Bit, known as the Mandatory bit, indicates whether		The 'M' Bit, known as the Mandatory bit, indicates whether
support of the AVP is required.		support of the AVP is required.
		If an AVP with the 'M' bit set is received by a PaC or PAA and
		either the AVP or its value is unrecognized, the message MUST
		be rejected and the receiver MUST send a PANA-Error message.
		If the AVP was unrecognized the PANA-Error message result code
		MUST be PANA_AVP_UNSUPPORTED. If the AVP value was
		unrecognized the PANA-Error message result code MUST be
		PANA_INVALID_AVP_DATA. In either case the PANA-Error message
		MUST carry a Failed-AVP AVP containing the offending mandatory
		AVP.
		AVPs with the 'M' bit cleared are informational only and a
		receiver that receives a message with such an AVP that is not
		supported, or whose value is not supported, MAY simply ignore
		the AVP.
V(endor)		V(endor)
The 'V' bit, known as the Vendor-Specific bit, indicates		The 'V' bit, known as the Vendor-Specific bit, indicates
whether the optional Vendor-Id field is present in the AVP		whether the optional Vendor-Id field is present in the AVP
header.		header. When set the AVP Code belongs to the specific vendor
		code address space.
r(eserved)		r(eserved)
These flag bits are reserved for future use, and MUST be set to		These flag bits are reserved for future use, and MUST be set to
zero, and ignored by the receiver.		zero, and ignored by the receiver.
		Unless otherwise noted, AVPs defined in this document will have
		the following default AVP Flags field settings: The 'M' bit MUST
		be set. The 'V' bit MUST NOT be set.
AVP Length		AVP Length
The AVP Length field is four octets, and indicates the number of		The AVP Length field is four octets, and indicates the number of
octets in this AVP including the AVP Code, AVP Length, AVP Flags,		octets in this AVP including the AVP Code, AVP Length, AVP Flags,
and the AVP data.		and the AVP data.
Reserved		Reserved
This two-octet field is reserved for future use, and MUST be set		This two-octet field is reserved for future use, and MUST be set
Skipping to change at page 39, line 5:
Vendor-Id along with their privately managed AVP address space,		Vendor-Id along with their privately managed AVP address space,
guaranteeing that they will not collide with any other vendor's		guaranteeing that they will not collide with any other vendor's
vendor-specific AVP(s), nor with future IETF applications.		vendor-specific AVP(s), nor with future IETF applications.
Data		Data
The Data field is zero or more octets and contains information		The Data field is zero or more octets and contains information
specific to the Attribute. The format and length of the Data		specific to the Attribute. The format and length of the Data
field is determined by the AVP Code and AVP Length fields.		field is determined by the AVP Code and AVP Length fields.
8. PANA Messages, Message Specifications and AVPs		7. PANA Messages, Message Specifications and AVPs
8.1 PANA Messages		7.1 PANA Messages
Figure 9 lists all PANA messages defined in this document.		Each Request/Answer message pair is assigned a message ID, and the
		sub-type (i.e., request or answer) is identified via the 'R' bit in
		the Message Flags field of the PANA header.
Message Direction: PaC---PAA		Every PANA message MUST contain a message ID in its header's
----------------------------------------		Message-Id field, which is used to determine the action that is to be
PANA-PAA-Discover -------->		taken for a particular message. Figure 9 lists all PANA messages
		defined in this document:
PANA-Start-Request <--------		Message-Name Abbrev. ID PaC<->PAA Ref.
PANA-Start-Answer -------->		-----------------------------------------------------------
		PANA-PAA-Discover PDI 1 --------> 7.2.1
		PANA-Start-Request PSR 2 <-------- 7.2.2
		PANA-Start-Answer PSA 2 --------> 7.2.3
		PANA-Auth-Request PAR 3 <-------> 7.2.4
		PANA-Auth-Answer PAN 3 <-------> 7.2.5
		PANA-Reauth-Request PRAR 4 --------> 7.2.6
		PANA-Reauth-Answer PRAA 4 <-------- 7.2.7
		PANA-Bind-Request PBR 5 <-------- 7.2.8
		PANA-Bind-Answer PBA 5 --------> 7.2.9
		PANA-Ping-Request PPR 6 <-------> 7.2.10
		PANA-Ping-Answer PPA 6 <-------> 7.2.11
		PANA-Termination-Request PTR 7 <-------> 7.2.12
		PANA-Termination-Answer PTA 7 <-------> 7.2.13
		PANA-Error-Request PER 8 <-------> 7.2.14
		PANA-Error-Answer PEA 8 <-------> 7.2.15
		PANA-FirstAuth-End-Request PFER 9 <-------- 7.2.16
		PANA-FirstAuth-End-Answer PFEA 9 --------> 7.2.17
		PANA-Update-Request PUR 10 --------> 7.2.18
		PANA-Update-Answer PUA 10 <-------- 7.2.19
		-----------------------------------------------------------
PANA-Auth-Request <------->		Figure 9: Table of PANA Messages
PANA-Auth-Answer <------->
PANA-Reauth-Request -------->		7.2 PANA Message ABNF Specification
PANA-Reauth-Answer <--------
PANA-FirstAuth-End-Request <--------		Every PANA message defined MUST include a corresponding ABNF
PANA-FirstAuth-End-Answer -------->		[RFC2234] specification, which is used to define the AVPs that MUST
		or MAY be present. The following format is used in the definition:
PANA-Bind-Request <--------		message-def = Message-Name "::=" PANA-message
PANA-Bind-Answer -------->
PANA-Ping-Request <------->		message-name = PANA-name
PANA-Ping-Answer <------->		PANA-name = ALPHA *(ALPHA / DIGIT / "-")
PANA-Termination-Request <------->		PANA-message = header [ *fixed] [ *required] [ *optional]
PANA-Termination-Answer <------->		[ *fixed]
PANA-Update-Request -------->		header = "< PANA-Header: " Message-Id
PANA-Update-Answer <--------		[r-bit] [s-bit] [n-bit] ">"
PANA-Error-Request <------->		Message-Id = 1*DIGIT
PANA-Error-Answer <------->		; The message code assigned to the message
Figure 9: PANA Message Overview		r-bit = ", REQ"
		; If present, the 'R' bit in the Message
		; Flags is set, indicating that the message
		; is a request, as opposed to an answer.
8.2 Message Specifications		s-bit = ", SEP"
		; If present, the 'S' bit in the Message
		; Flags is set, indicating support for
		; separate NAP and ISP authentication.
Every PANA message MUST include a corresponding ABNF [RFC2234]		n-bit = ", NAP"
specification found in [RFC3588].		; If present, the 'N' bit in the Message
		; Flags is set, indicating that current
		; EAP authentication is for NAP authentication.
Example:		fixed = [qual] "<" avp-spec ">"
		; Defines the fixed position of an AVP
message ::= < PANA-Header: <Message type>, [REQ] [SEP] >		required = [qual] "{" avp-spec "}"
		; The AVP MUST be present and can appear
		; anywhere in the message.
		optional = [qual] "[" avp-name "]"
		; The avp-name in the 'optional' rule cannot
		; evaluate to any AVP Name which is included
		; in a fixed or required rule. The AVP can
		; appear anywhere in the message.
		qual = [min] "*" [max]
		; See ABNF conventions, RFC 2234 Section 6.6.
		; The absence of any qualifiers depends on whether
		; it precedes a fixed, required, or optional
		; rule. If a fixed or required rule has no
		; qualifier, then exactly one such AVP MUST
		; be present. If an optional rule has no
		; qualifier, then 0 or 1 such AVP may be
		; present.
		;
		; NOTE: "[" and "]" have a different meaning
		; than in ABNF (see the optional rule, above).
		; These braces cannot be used to express
		; optional fixed rules (such as an optional
		; ICV at the end). To do this, the convention
		; is '0*1fixed'.
		min = 1*DIGIT
		; The minimum number of times the element may
		; be present. The default value is zero.
		max = 1*DIGIT
		; The maximum number of times the element may
		; be present. The default value is infinity. A
		; value of zero implies the AVP MUST NOT be
		; present.
		avp-spec = PANA-name
		; The avp-spec has to be an AVP Name, defined
		; in the base or extended PANA protocol
		; specifications.
		avp-name = avp-spec / "AVP"
		; The string "AVP" stands for *any* arbitrary
		; AVP Name, which does not conflict with the
		; required or fixed position AVPs defined in
		; the message definition.
		Example-Request ::= < "PANA-Header: 9999999, REQ >
		< Session-Id >
		{ Result-Code }
* [ AVP ]		* [ AVP ]
		0*1 < MAC >
8.2.1 PANA-PAA-Discover (PDI)		7.2.1 PANA-PAA-Discover (PDI)
The PANA-PAA-Discover (PDI) message is used to discover the address		The PANA-PAA-Discover (PDI) message is used to discover the address
of PAA(s). The sequence number in this message is always set to zero		of PAA(s). The sequence number in this message is always set to zero
(0).		(0).
PANA-PAA-Discover ::= < PANA-Header: 1 >		PANA-PAA-Discover ::= < PANA-Header: 1 >
* [ AVP ]		* [ AVP ]
8.2.2 PANA-Start-Request (PSR)		7.2.2 PANA-Start-Request (PSR)
PANA-Start-Request (PSR) is sent by the PAA to the PaC to advertise		PANA-Start-Request (PSR) is sent by the PAA to the PaC to advertise
availability of the PAA and start PANA authentication. The PAA sets		availability of the PAA and start PANA authentication. The PAA sets
the sequence number to an initial random value.		the sequence number to an initial random value.
PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] >		PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] >
{ Nonce }		{ Nonce }
[ Cookie ]		[ Cookie ]
[ EAP-Payload ]		[ EAP-Payload ]
[ NAP-Information ]		[ NAP-Information ]
* [ ISP-Information ]		* [ ISP-Information ]
[ Protection-Capability]		[ Protection-Capability]
[ PPAC ]		[ PPAC ]
* [ AVP ]		* [ AVP ]
8.2.3 PANA-Start-Answer (PSA)		7.2.3 PANA-Start-Answer (PSA)
PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to		PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to
a PANA-Start-Request message. This message completes the handshake		a PANA-Start-Request message. This message completes the handshake
to start PANA authentication.		to start PANA authentication.
PANA-Start-Answer ::= < PANA-Header: 2 [SEP] >		PANA-Start-Answer ::= < PANA-Header: 2 [SEP] >
{ Nonce }		{ Nonce }
[ Session-Id ]
[ Cookie ]		[ Cookie ]
[ EAP-Payload ]		[ EAP-Payload ]
[ ISP-Information ]		[ ISP-Information ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.4 PANA-Auth-Request (PAR)		7.2.4 PANA-Auth-Request (PAR)
PANA-Auth-Request (PAR) is either sent by the PAA or the PaC. Its		PANA-Auth-Request (PAR) is either sent by the PAA or the PaC. Its
main task is to carry an EAP-Payload AVP.		main task is to carry an EAP-Payload AVP.
PANA-Auth-Request ::= < PANA-Header: 3, REQ [SEP] [NAP] >		PANA-Auth-Request ::= < PANA-Header: 3, REQ [SEP] [NAP] >
< Session-Id >		< Session-Id >
< EAP-Payload >		< EAP-Payload >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.5 PANA-Auth-Answer (PAN)		7.2.5 PANA-Auth-Answer (PAN)
PANA-Auth-Answer (PAN) is sent by either the PaC or the PAA in		PANA-Auth-Answer (PAN) is sent by either the PaC or the PAA in
response to a PANA-Auth-Request message. It MAY optionally carry an		response to a PANA-Auth-Request message. It MAY carry an EAP-Payload
EAP-Payload AVP.		AVP.
PANA-Auth-Answer ::= < PANA-Header: 3 [SEP] [NAP] >		PANA-Auth-Answer ::= < PANA-Header: 3 [SEP] [NAP] >
< Session-Id >		< Session-Id >
[ EAP-Payload ]		[ EAP-Payload ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.6 PANA-Reauth-Request (PRAR)		7.2.6 PANA-Reauth-Request (PRAR)
PANA-Reauth-Request (PRAR) is sent by the PaC to the PAA to		PANA-Reauth-Request (PRAR) is sent by the PaC to the PAA to
re-initiate EAP authentication.		re-initiate EAP authentication.
PANA-Reauth-Request ::= < PANA-Header: 4, REQ >		PANA-Reauth-Request ::= < PANA-Header: 4, REQ >
< Session-Id >		< Session-Id >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.7 PANA-Reauth-Answer (PRAA)		7.2.7 PANA-Reauth-Answer (PRAA)
PANA-Reauth-Answer (PRAA) is sent by the PAA to the PaC in response		PANA-Reauth-Answer (PRAA) is sent by the PAA to the PaC in response
to a PANA-Reauth-Request message.		to a PANA-Reauth-Request message.
PANA-Reauth-Answer ::= < PANA-Header: 4 >		PANA-Reauth-Answer ::= < PANA-Header: 4 >
< Session-Id >		< Session-Id >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.8 PANA-Bind-Request (PBR)		7.2.8 PANA-Bind-Request (PBR)
PANA-Bind-Request (PBR) is sent by the PAA to the PaC to deliver the		PANA-Bind-Request (PBR) is sent by the PAA to the PaC to deliver the
result of PANA authentication.		result of PANA authentication.
PANA-Bind-Request ::= < PANA-Header: 5, REQ [SEP] [NAP] >		PANA-Bind-Request ::= < PANA-Header: 5, REQ [SEP] [NAP] >
< Session-Id >		< Session-Id >
{ Result-Code }		{ Result-Code }
{ PPAC }		{ PPAC }
{ IP-Address }		{ IP-Address }
[ EAP-Payload ]		[ EAP-Payload ]
[ Session-Lifetime ]		[ Session-Lifetime ]
[ Protection-Capability ]		[ Protection-Capability ]
[ Key-Id ]		[ Key-Id ]
* [ Device-Id ]		* [ Device-Id ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.9 PANA-Bind-Answer (PBA)		7.2.9 PANA-Bind-Answer (PBA)
PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a		PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a
PANA-Result-Request message.		PANA-Bind-Request message.
PANA-Bind-Answer ::= < PANA-Header: 5 [,SEP] [NAP] >		PANA-Bind-Answer ::= < PANA-Header: 5 [,SEP] [NAP] >
< Session-Id >		< Session-Id >
{ Result-Code }		{ Result-Code }
[ PPAC ]		[ PPAC ]
[ Device-Id ]		[ Device-Id ]
[ Key-Id ]		[ Key-Id ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.10 PANA-Ping-Request (PPR)		7.2.10 PANA-Ping-Request (PPR)
PANA-Ping-Request (PPR) is either sent by the PaC or the PAA for		PANA-Ping-Request (PPR) is either sent by the PaC or the PAA for
performing liveness test.		performing liveness test.
PANA-Ping-Request ::= < PANA-Header: 6, REQ >		PANA-Ping-Request ::= < PANA-Header: 6, REQ >
< Session-Id >		< Session-Id >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.11 PANA-Ping-Answer (PPA)		7.2.11 PANA-Ping-Answer (PPA)
PANA-Ping-Answer (PPA) is sent in response to a PANA-Ping-Request.		PANA-Ping-Answer (PPA) is sent in response to a PANA-Ping-Request.
PANA-Ping-Answer ::= < PANA-Header: 6 >		PANA-Ping-Answer ::= < PANA-Header: 6 >
< Session-Id >		< Session-Id >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.12 PANA-Termination-Request (PTR)		7.2.12 PANA-Termination-Request (PTR)
PANA-Termination-Request (PTR) is sent either by the PaC or the PAA		PANA-Termination-Request (PTR) is sent either by the PaC or the PAA
to terminate a PANA session.		to terminate a PANA session.
PANA-Termination-Request ::= < PANA-Header: 7, REQ >		PANA-Termination-Request ::= < PANA-Header: 7, REQ >
< Session-Id >		< Session-Id >
< Termination-Cause >		< Termination-Cause >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.13 PANA-Termination-Answer (PTA)		7.2.13 PANA-Termination-Answer (PTA)
PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in		PANA-Termination-Answer (PTA) is sent either by the PaC or the PAA in
response to PANA-Termination-Request.		response to PANA-Termination-Request.
PANA-Termination-Answer ::= < PANA-Header: 7 >		PANA-Termination-Answer ::= < PANA-Header: 7 >
< Session-Id >		< Session-Id >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.14 PANA-Error-Request (PER)		7.2.14 PANA-Error-Request (PER)
PANA-Error is sent either by the PaC or the PAA to report an error		PANA-Error is sent either by the PaC or the PAA to report an error
with the last received PANA message.		with the last received PANA message.
PANA-Error-Request ::= < PANA-Header: 8 REQ >		PANA-Error-Request ::= < PANA-Header: 8 REQ >
< Session-Id >		< Session-Id >
< Result-Code >		< Result-Code >
{ Failed-AVP }		{ Failed-AVP }
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.15 PANA-Error-Answer (PEA)		7.2.15 PANA-Error-Answer (PEA)
PANA-Error-Answer is sent in response to a PANA-Error-Request.		PANA-Error-Answer is sent in response to a PANA-Error-Request.
PANA-Error-Answer ::= < PANA-Header: 8 >		PANA-Error-Answer ::= < PANA-Header: 8 >
< Session-Id >		< Session-Id >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.16 PANA-FirstAuth-End-Request (PFER)		7.2.16 PANA-FirstAuth-End-Request (PFER)
PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC to		PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC to
signal the result of the first EAP authentication method when		signal the result of the first EAP authentication method when
separate NAP and ISP authentication is performed.		separate NAP and ISP authentication is performed.
PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [SEP] [NAP] >		PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [SEP] [NAP] >
< Session-Id >		< Session-Id >
{ EAP-Payload }		{ EAP-Payload }
{ Result-Code }		{ Result-Code }
[ Key-Id ]		[ Key-Id ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.17 PANA-FirstAuth-End-Answer (PFEA)		7.2.17 PANA-FirstAuth-End-Answer (PFEA)
PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in		PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in
response to a PANA-FirstAuth-End-Request message.		response to a PANA-FirstAuth-End-Request message.
PANA-FirstAuth-End-Answer ::= < PANA-Header: 9, REQ [SEP] [NAP] >		PANA-FirstAuth-End-Answer ::= < PANA-Header: 9, REQ [SEP] [NAP] >
< Session-Id >		< Session-Id >
[ Key-Id ]		[ Key-Id ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.18 PANA-Update-Request (PUR)		7.2.18 PANA-Update-Request (PUR)
PANA-Update-Request (PUR) is sent by the PaC to the PAA to update the		PANA-Update-Request (PUR) is sent by the PaC to the PAA to update the
attributes of the PANA session. Currently only the PaC IP address		attributes of the PANA session. Currently only the PaC IP address
attribute can be updated via this mechanism.		attribute can be updated via this mechanism.
PANA-Update-Request ::= < PANA-Header: 10, REQ >		PANA-Update-Request ::= < PANA-Header: 10, REQ >
< Session-Id >		< Session-Id >
< IP-Address >		< IP-Address >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.2.19 PANA-Update-Answer (PUA)		7.2.19 PANA-Update-Answer (PUA)
PANA-Update-Answer (PUA) is sent by the PAA to the PaC in response to		PANA-Update-Answer (PUA) is sent by the PAA to the PaC in response to
a PANA-Update-Request.		a PANA-Update-Request.
PANA-Update-Answer ::= < PANA-Header: 10 >		PANA-Update-Answer ::= < PANA-Header: 10 >
< Session-Id >		< Session-Id >
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
8.3 AVPs in PANA		7.3 AVPs in PANA
PANA defines several AVPs that are specific to the protocol. A		PANA defines several AVPs that are specific to the protocol. A
number of others AVPs are reused. These are specified in other		number of others AVPs are reused. These are specified in other
documents such as [RFC3588].		documents such as [RFC3588].
The following tables lists the AVPs used in this document, and		The following tables lists the AVPs used in this document, and
specifies in which PANA messages they MAY, or MAY NOT be present.		specifies in which PANA messages they MAY, or MAY NOT be present.
The table uses the following symbols:		The table uses the following symbols:
Skipping to change at page 46, line 12:
1+ At least one instance of the AVP MUST be present in the		1+ At least one instance of the AVP MUST be present in the
message.		message.
+-----------------------------------------+		+-----------------------------------------+
| Message |		| Message |
| Type |		| Type |
+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+
Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI |		Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
--------------------+-----+-----+-----+-----+-----+-----+-----+		--------------------+-----+-----+-----+-----+-----+-----+-----+
Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 |		Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
Session-Id | 0 | 0-1 | 1 | 1 | 1 | 1 | 0 |		Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 |
Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
EAP-Payload | 0-1 | 0-1 | 1 | 0-1 | 0-1 | 0 | 0 |		EAP-Payload | 0-1 | 0-1 | 1 | 0-1 | 0-1 | 0 | 0 |
MAC | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0 |		MAC | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0 |
Nonce | 1 | 1 | 0 | 0 | 0 | 0 | 0 |		Nonce | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0+ | 0-1 | 0 |		Device-Id | 0 | 0 | 0 | 0 | 0+ | 0-1 | 0 |
Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 |		Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 |		Protection-Cap. | 0-1 | 0 | 0 | 0 | 0-1 | 0 | 0 |
PPAC | 0-1 | 0 | 0 | 0 | 1 | 0-1 | 0 |		PPAC | 0-1 | 0 | 0 | 0 | 1 | 0-1 | 0 |
Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 |		Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Skipping to change at page 48, line 30:
Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 |		Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 1 | 0 | 0 | 0 |		Failed-AVP | 0 | 0 | 1 | 0 | 0 | 0 |
ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 |		ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 |
NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 |		NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 | 0 | 0 |		Key-Id | 0 | 0 | 0 | 0 | 0 | 0 |
IP-Address | 1 | 0 | 0 | 0 | 0 | 0 |		IP-Address | 1 | 0 | 0 | 0 | 0 | 0 |
--------------------+-----+-----+-----+-----+------+------+		--------------------+-----+-----+-----+-----+------+------+
Figure 12: AVP Occurrence Table (3/3)		Figure 12: AVP Occurrence Table (3/3)
8.3.1 MAC AVP		7.3.1 MAC AVP
The MAC (Message Authentication Code) AVP is used to integrity		The MAC (Message Authentication Code) AVP is used to integrity
protect PANA messages. The first octet of the this AVP (AVP Code 1)		protect PANA messages. The first octet of the this AVP (AVP Code 1)
data contains the MAC algorithm type. Rest of the AVP data payload		data contains the MAC algorithm type. Rest of the AVP data payload
contains the MAC encoded in network byte order. The 8-bit Algorithm		contains the MAC encoded in network byte order. The 8-bit Algorithm
name space is managed by IANA [ianaweb]. The AVP length varies		name space is managed by IANA [ianaweb]. The AVP length varies
depending on the used algorithm.		depending on the used algorithm.
0 1 2 3		0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Skipping to change at page 49, line 8:
| Algorithm | MAC...		| Algorithm | MAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm		Algorithm
1 HMAC-SHA1 (20 bytes)		1 HMAC-SHA1 (20 bytes)
MAC		MAC
The Message Authentication Code is encoded in network byte order.		The Message Authentication Code is encoded in network byte order.
8.3.2 Device-Id AVP		7.3.2 Device-Id AVP
The Device-Id AVP (AVP Code 2) is used for carrying device		The Device-Id AVP (AVP Code 2) is used for carrying device
identifiers of PaC and EP(s). The AVP data is of Address type		identifiers of PaC and EP(s). The AVP data is of Address type
[RFC3588]. IPv4 and IPv6 addresses are encoded as specified in		[RFC3588]. IPv4 and IPv6 addresses are encoded as specified in
[RFC3588]. The content and format of data (including byte and bit		[RFC3588]. The content and format of data (including byte and bit
ordering) for link-layer addresses is expected to be specified in		ordering) for link-layer addresses is expected to be specified in
specific documents that describe how IP operates over different		specific documents that describe how IP operates over different
link-layers. For instance, [RFC2464]. Address families other than		link-layers. For instance, [RFC2464]. Address families other than
that are defined for link-layer or IP addresses MUST NOT be used for		that are defined for link-layer or IP addresses MUST NOT be used for
this AVP.		this AVP.
8.3.3 Session-Id AVP		7.3.3 Session-Id AVP
All messages pertaining to a specific PANA session MUST include a		All messages pertaining to a specific PANA session MUST include a
Session-Id AVP (AVP Code 3) which carries a PAA-assigned fixed		Session-Id AVP (AVP Code 3) which carries a PAA-assigned fixed
session identifier value throughout the lifetime of a session. When		session identifier value throughout the lifetime of a session. When
present, the Session-Id SHOULD appear immediately following the PANA		present, the Session-Id AVP SHOULD appear immediately following the
header.		PANA header.
The Session-Id MUST be globally and eternally unique, as it is meant		The Session-Id MUST be globally and eternally unique, as it is meant
to identify a PANA Session without reference to any other		to identify a PANA session without reference to any other
information, and may be needed to correlate historical authentication		information, and may be needed to correlate historical authentication
information with accounting information. The PANA Session-Id AVP has		information with accounting information. The PANA Session-Id AVP has
the same format as the Diameter Session-Id AVP [RFC3588].		the same format as the Diameter Session-Id AVP [RFC3588].
8.3.4 Cookie AVP		7.3.4 Cookie AVP
The Cookie AVP (AVP Code 4) is used for carrying a cookie value		The Cookie AVP (AVP Code 4) is used for carrying a random value
generated by the PAA. The AVP data is of type OctetString. It is		generated by the PAA. The AVP data is of type OctetString. The
opaque and the exact content is outside the scope of this protocol.		random value is referred to as a cookie and used for making PAA
		discovery robust against blind resource consumption DoS attacks. The
		exact algorithms and syntax used by the PAA to generate a cookie does
		not affect interoperability and not specified in this document. An
		example cookie generation algorithm is shown in Section 4.2.
8.3.5 Protection-Capability AVP		7.3.5 Protection-Capability AVP
The Protection-Capability AVP (AVP Code 5) indicates the		The Protection-Capability AVP (AVP Code 5) indicates the
cryptographic data protection capability supported and required by		cryptographic data protection capability supported and required by
the EPs. The AVP data is of type Unsigned32. Below is a list of		the EPs. The AVP data is of type Unsigned32. Below is a list of
valid data values and associated protection capabilities:		valid data values and associated protection capabilities:
0 L2_PROTECTION		0 L2_PROTECTION
1 IPSEC_PROTECTION		1 IPSEC_PROTECTION
8.3.6 Termination-Cause AVP		7.3.6 Termination-Cause AVP
The Termination-Cause AVP (AVP Code 6) is used for indicating the		The Termination-Cause AVP (AVP Code 6) is used for indicating the
reason why a session is terminated by the requester. The AVP data is		reason why a session is terminated by the requester. The AVP data is
of type Enumerated. The following Termination-Cause data values are		of type Enumerated. The following Termination-Cause data values are
used with PANA.		used with PANA.
LOGOUT 1 (PaC -> PAA)		LOGOUT 1 (PaC -> PAA)
The client initiated a disconnect		The client initiated a disconnect
ADMINISTRATIVE 4 (PAA -> PaC)		ADMINISTRATIVE 4 (PAA -> PaC)
The client was not granted access, or was disconnected, due to		The client was not granted access, or was disconnected, due to
administrative reasons, such as the receipt of a		administrative reasons, such as the receipt of a
Abort-Session-Request message.		Abort-Session-Request message.
SESSION_TIMEOUT 8 (PAA -> PaC)		SESSION_TIMEOUT 8 (PAA -> PaC)
The session has timed out, and service has been terminated.		The session has timed out, and service has been terminated.
8.3.7 Result-Code AVP		7.3.7 Result-Code AVP
The Result-Code AVP (AVP Code 7) is of type Unsigned32 and indicates		The Result-Code AVP (AVP Code 7) is of type Unsigned32 and indicates
whether an EAP authentication was completed successfully or whether		whether an EAP authentication was completed successfully or whether
an error occurred. Here are Result-Code AVP values taken from		an error occurred. Here are Result-Code AVP values taken from
[RFC3588] and adapted for PANA.		[RFC3588] and adapted for PANA.
8.3.7.1 Authentication Results Codes		7.3.7.1 Authentication Results Codes
These result code values inform the PaC about the authentication and		These result code values inform the PaC about the authentication and
authorization result. The authentication result and authorization		authorization result. The authentication result and authorization
result can be different as described below, but only one result is		result can be different as described below, but only one result is
returned to the PaC. These codes are used with PANA-Bind-Request and		returned to the PaC. These codes are used with PANA-Bind-Request and
PANA-FirstAuth-End-Request messages.		PANA-FirstAuth-End-Request messages.
PANA_SUCCESS 2001		PANA_SUCCESS 2001
Both the authentication and authorization processes are		Both authentication and authorization processes are successful.
successful.
PANA_AUTHENTICATION_REJECTED 4001		PANA_AUTHENTICATION_REJECTED 4001
Authentication has failed. When this error is returned, it is		Authentication has failed. When this error is returned, it is
assumed that authorization is automatically failed.		assumed that authorization is automatically failed.
PANA_AUTHORIZATION_REJECTED 5003		PANA_AUTHORIZATION_REJECTED 5003
Authorization has failed. This error could occur when		The authorization process has failed. This error could occur when
authorization is rejected by a AAA proxy or rejected locally by a		authorization is rejected by a AAA or rejected locally by a PAA,
PAA, even if the authentication has succeeded.		even if the authentication procedure has succeeded.
8.3.7.2 Protocol Error Result Codes		7.3.7.2 Protocol Error Result Codes
These codes are used with PANA-Error-Request messages. Unless stated		These codes are used with PANA-Error-Request messages. Unless stated
otherwise, they can be generated by both the PaC and the PAA.		otherwise, they can be generated by both the PaC and the PAA.
PANA_MESSAGE_UNSUPPORTED 3001		PANA_MESSAGE_UNSUPPORTED 3001
Message type not recognized or supported.		Message type not recognized or supported.
PANA_UNABLE_TO_DELIVER 3002		PANA_UNABLE_TO_DELIVER 3002
Skipping to change at page 53, line 35:
PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016		PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016
This error is returned when the PaC receives a PANA-Bind-Request		This error is returned when the PaC receives a PANA-Bind-Request
with a Protection-Capability AVP and a valid MAC AVP but does not		with a Protection-Capability AVP and a valid MAC AVP but does not
support the protection capability specified in the		support the protection capability specified in the
Protection-Capability AVP. Only PaC can generate this code.		Protection-Capability AVP. Only PaC can generate this code.
PANA_PPAC_CAPABILITY_UNSUPPORTED 5017		PANA_PPAC_CAPABILITY_UNSUPPORTED 5017
This error is returned in a PANA-Bind-Answer message when there is		This error is returned when there is no match between the list of
no match between the list of PPAC methods offered by the PAA and		PPAC methods offered by the PAA and the ones available on the PaC.
the ones available on the PaC. Only PaC can generate this code.		Only PaC can generate this code.
PANA_INVALID_IP_ADDRESS 5018		PANA_INVALID_IP_ADDRESS 5018
This error is returned in a PANA-Error-Request message when the		This error is returned in a PANA-Error-Request message when the
IP-Address AVP in the received PANA-Update-Request message is		IP-Address AVP in the received PANA-Update-Request message is
invalid (e.g., a non-unicast address). Only PAA can generate this		invalid (e.g., a non-unicast address). Only PAA can generate this
code.		code.
8.3.8 EAP-Payload AVP		7.3.8 EAP-Payload AVP
The EAP-Payload AVP (AVP Code 8) is used for encapsulating the actual		The EAP-Payload AVP (AVP Code 8) is used for encapsulating the actual
EAP packet that is being exchanged between the EAP peer and the EAP		EAP packet that is being exchanged between the EAP peer and the EAP
authenticator. The AVP data is of type OctetString.		authenticator. The AVP data is of type OctetString.
8.3.9 Session-Lifetime AVP		7.3.9 Session-Lifetime AVP
The Session-Lifetime AVP (AVP Code 9) contains the number of seconds		The Session-Lifetime AVP (AVP Code 9) contains the number of seconds
remaining before the current session is considered expired. The AVP		remaining before the current session is considered expired. The AVP
data is of type Unsigned32.		data is of type Unsigned32.
8.3.10 Failed-AVP AVP		7.3.10 Failed-AVP AVP
The Failed-AVP AVP (AVP Code 10) provides debugging information in		The Failed-AVP AVP (AVP Code 10) provides debugging information in
cases where a request is rejected or not fully processed due to		cases where a request is rejected or not fully processed due to
erroneous information in a specific AVP. The AVP data is of type		erroneous information in a specific AVP. The AVP data is of type
Grouped. The format of the Failed-AVP AVP is defined in [RFC3588].		Grouped. The format of the Failed-AVP AVP is defined in [RFC3588].
8.3.11 NAP-Information AVP		7.3.11 NAP-Information AVP
The NAP-Information AVP (AVP Code 11) contains zero or one		The NAP-Information AVP (AVP Code 11) contains zero or one
Provider-Identifier AVP which carries the identifier of the NAP and		Provider-Identifier AVP which carries the identifier of the NAP and
one Provider-Name AVP which carries the name of the NAP. The AVP		one Provider-Name AVP which carries the name of the NAP. The AVP
data is of type Grouped, and it has the following ABNF grammar:		data is of type Grouped, and it has the following ABNF grammar:
NAP-Information ::= < AVP Header: 11 >		NAP-Information ::= < AVP Header: 11 >
0*1 { Provider-Identifier }		0*1 { Provider-Identifier }
{ Provider-Name }		{ Provider-Name }
* [ AVP ]		* [ AVP ]
8.3.12 ISP-Information AVP		7.3.12 ISP-Information AVP
The ISP-Information AVP (AVP Code 12) contains zero or one		The ISP-Information AVP (AVP Code 12) contains zero or one
Provider-Identifier AVP which carries the identifier of the ISP and		Provider-Identifier AVP which carries the identifier of the ISP and
one Provider-Name AVP which carries the name of the ISP. The AVP		one Provider-Name AVP which carries the name of the ISP. The AVP
data is of type Grouped, and it has the following ABNF grammar:		data is of type Grouped, and it has the following ABNF grammar:
ISP-Information ::= < AVP Header: 12 >		ISP-Information ::= < AVP Header: 12 >
0*1 { Provider-Identifier }		0*1 { Provider-Identifier }
{ Provider-Name }		{ Provider-Name }
* [ AVP ]		* [ AVP ]
8.3.13 Provider-Identifier AVP		7.3.13 Provider-Identifier AVP
The Provider-Identifier AVP (AVP Code 13) is of type Unsigned32, and		The Provider-Identifier AVP (AVP Code 13) is of type Unsigned32, and
contains an IANA assigned "SMI Network Management Private Enterprise		contains an IANA assigned "SMI Network Management Private Enterprise
Codes" [ianaweb] value, encoded in network byte order.		Codes" [ianaweb] value, encoded in network byte order.
8.3.14 Provider-Name AVP		7.3.14 Provider-Name AVP
The Provider-Name AVP (AVP Code 14) is of type UTF8String, and		The Provider-Name AVP (AVP Code 14) is of type UTF8String, and
contains the UTF8-encoded name of the provider.		contains the UTF8-encoded name of the provider.
8.3.15 Key-Id AVP		7.3.15 Key-Id AVP
The Key-Id AVP (AVP Code 15) is of type Integer32, and contains an		The Key-Id AVP (AVP Code 15) is of type Integer32, and contains an
AAA-Key identifier. The AAA-Key identifier is assigned by PAA and		AAA-Key identifier. The AAA-Key identifier is assigned by PAA and
MUST be unique within the PANA session.		MUST be unique within the PANA session.
8.3.16 Post-PANA-Address-Configuration (PPAC) AVP		7.3.16 Post-PANA-Address-Configuration (PPAC) AVP
The PPAC AVP (AVP Code 16) is used for conveying the available types		The PPAC AVP (AVP Code 16) is used for conveying the available types
of post-PANA IP address configuration mechanisms when sent by the		of post-PANA IP address configuration mechanisms when sent by the
PAA, and the chosen one when sent by the PaC. Each possible		PAA, and the chosen one when sent by the PaC. Each possible
mechanisms is represented by a flag. At least one or more of the		mechanisms is represented by a flag. At least one or more of the
flags MUST be set when sent by the PAA, and exactly one flag MUST be		flags MUST be set when sent by the PAA, and exactly one flag MUST be
set when sent by the PaC. The AVP data is of type Unsigned32.		set when sent by the PaC. The AVP data is of type Unsigned32.
The format of the AVP data is as follows:		The format of the AVP data is as follows:
Skipping to change at page 56, line 20:
Reserved		Reserved
These flag bits are reserved for future use, and MUST be set to		These flag bits are reserved for future use, and MUST be set to
zero, and ignored by the receiver.		zero, and ignored by the receiver.
Unless the N-flag is set, the PaC MUST configure a new IP address		Unless the N-flag is set, the PaC MUST configure a new IP address
using one of the methods indicated by the other flags. Refer to		using one of the methods indicated by the other flags. Refer to
[I-D.ietf-pana-framework] for a detailed discussion on when these		[I-D.ietf-pana-framework] for a detailed discussion on when these
methods can be used.		methods can be used.
8.3.17 Nonce AVP		7.3.17 Nonce AVP
The Nonce AVP (AVP Code 17) carries a randomly chosen value that is		The Nonce AVP (AVP Code 17) carries a randomly chosen value that is
used in cyrptographic key computations. The AVP data is of type		used in cyrptographic key computations. The AVP data is of type
OctetString and it contains a randomly generated value in opaque		OctetString and it contains a randomly generated value in opaque
format. The data length MUST be between 8 and 256 bytes inclusive.		format. The data length MUST be between 8 and 256 bytes inclusive.
8.3.18 IP-Address AVP		7.3.18 IP-Address AVP
The IP-Address AVP (AVP Code 18) contains an IP address of the PaC or		The IP-Address AVP (AVP Code 18) contains an IP address of the PaC or
PAA. When it is sent by the PaC, it is used to convey the new IP		PAA. When it is sent by the PaC, it is used to convey the new IP
address of the PaC to the PAA when the PaC reconfigures its IP		address of the PaC to the PAA when the PaC reconfigures its IP
address after the successful PANA authentication. This AVP is not		address after the successful PANA authentication. This AVP is not
used if the PaC's IP address used during the PANA authentication		used if the PaC's IP address used during the authentication and
phase is still valid. It is sent by the PAA in PANA-Bind-Request to		authorization phase is still valid. It is sent by the PAA in
bind the IP address of the PAA to the PANA session. The payload		PANA-Bind-Request to bind the IP address of the PAA to the PANA
format of the IP-Address AVP is the same as that of the Device-Id AVP		session. The payload format of the IP-Address AVP is the same as
(see See Section 8.3.2). Address families for IPv4 or IPv6 MUST be		that of the Device-Id AVP (see See Section 7.3.2). Address families
used for this AVP.		for IPv4 or IPv6 MUST be used for this AVP.
9. Retransmission Timers		8. Retransmission Timers
The PANA protocol provides retransmissions for the PANA-PAA-Discover		The PANA protocol provides retransmissions for the PANA-PAA-Discover
and request messages.		and request messages.
The rule is that the sender of the request message retransmits the		The rule is that the sender of the request message retransmits the
request if the corresponding answer is not received in time. Answer		request if the corresponding answer is not received in time. Answer
messages are sent as answers to the request messages, not based on a		messages are sent as answers to the request messages, not based on a
timer.		timer.
PANA retransmission timers are based on the model used in DHCPv6		PANA retransmission timers are based on the model used in DHCPv6
Skipping to change at page 58, line 35:
once MRD seconds have elapsed since the client first transmitted the		once MRD seconds have elapsed since the client first transmitted the
message.		message.
If both MRC and MRD are non-zero, the message exchange fails whenever		If both MRC and MRD are non-zero, the message exchange fails whenever
either of the conditions specified in the previous two paragraphs are		either of the conditions specified in the previous two paragraphs are
met.		met.
If both MRC and MRD are zero, the client continues to transmit the		If both MRC and MRD are zero, the client continues to transmit the
message until it receives a response.		message until it receives a response.
9.1 Transmission and Retransmission Parameters		8.1 Transmission and Retransmission Parameters
This section presents a table of values used to describe the message		This section presents a table of values used to describe the message
retransmission behavior of PANA requests (REQ_*) and		retransmission behavior of PANA requests (REQ_*) and
PANA-PAA-Discover message (PDI_*). The table shows default values.		PANA-PAA-Discover message (PDI_*). The table shows default values.
Parameter Default Description		Parameter Default Description
------------------------------------------------		------------------------------------------------
PDI_IRT 1 sec Initial PDI timeout.		PDI_IRT 1 sec Initial PDI timeout.
PDI_MRT 120 secs Max PDI timeout value.		PDI_MRT 120 secs Max PDI timeout value.
PDI_MRC 0 Configurable.		PDI_MRC 0 Configurable.
Skipping to change at page 60, line 5:
REQ_IRT 1 sec Initial Request timeout.		REQ_IRT 1 sec Initial Request timeout.
REQ_MRT 30 secs Max Request timeout value.		REQ_MRT 30 secs Max Request timeout value.
REQ_MRC 10 Max Request retry attempts.		REQ_MRC 10 Max Request retry attempts.
REQ_MRD 0 Configurable.		REQ_MRD 0 Configurable.
So for example the first RT for the PBR message is calculated using		So for example the first RT for the PBR message is calculated using
REQ_IRT as the IRT:		REQ_IRT as the IRT:
RT = REQ_IRT + RAND*REQ_IRT		RT = REQ_IRT + RAND*REQ_IRT
10. IANA Considerations		9. IANA Considerations
This section provides guidance to the Internet Assigned Numbers		This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the PANA		Authority (IANA) regarding registration of values related to the PANA
protocol, in accordance with BCP 26 [IANA]. The following policies		protocol, in accordance with BCP 26 [IANA]. The following policies
are used here with the meanings defined in BCP 26: "Private Use",		are used here with the meanings defined in BCP 26: "Private Use",
"First Come First Served", "Expert Review", "Specification Required",		"First Come First Served", "Expert Review", "Specification Required",
"IETF Consensus", "Standards Action".		"IETF Consensus", "Standards Action".
This section explains the criteria to be used by the IANA for		This section explains the criteria to be used by the IANA for
assignment of numbers within namespaces defined within this document.		assignment of numbers within namespaces defined within this document.
Skipping to change at page 60, line 30:
Required, the request is posted to the PANA WG mailing list (or, if		Required, the request is posted to the PANA WG mailing list (or, if
it has been disbanded, a successor designated by the Area Director)		it has been disbanded, a successor designated by the Area Director)
for comment and review, and MUST include a pointer to a public		for comment and review, and MUST include a pointer to a public
specification. Before a period of 30 days has passed, the Designated		specification. Before a period of 30 days has passed, the Designated
Expert will either approve or deny the registration request and		Expert will either approve or deny the registration request and
publish a notice of the decision to the PANA WG mailing list or its		publish a notice of the decision to the PANA WG mailing list or its
successor. A denial notice must be justified by an explanation and,		successor. A denial notice must be justified by an explanation and,
in the cases where it is possible, concrete suggestions on how the		in the cases where it is possible, concrete suggestions on how the
request can be modified so as to become acceptable.		request can be modified so as to become acceptable.
10.1 PANA UDP Port Number		9.1 PANA UDP Port Number
PANA uses one well-known UDP port number (Section 5.1, Section 4.2		PANA uses one well-known UDP port number (Section 5.1, Section 4.2
and Section 7.1), which needs to be assigned by the IANA.		and Section 6.1), which needs to be assigned by the IANA.
10.2 PANA Multicast Address		9.2 PANA Multicast Address
PANA uses one well-known IPv4 multicast address for which the scope		PANA uses one well-known IPv4 multicast address for which the scope
is limited to be link-local by setting the TTL field to 255, and one		is limited to be link-local by setting the TTL field to 255, and one
well-known IPv6 link-local scoped multicast address (Section 4.2 and		well-known IPv6 link-local scoped multicast address (Section 4.2 and
Section 7.1), which need to be assigned by the IANA.		Section 6.1), which need to be assigned by the IANA.
10.3 PANA Header		9.3 PANA Header
As defined in Section 7.2, the PANA header contains two fields that		As defined in Section 6.2, the PANA header contains two fields that
requires IANA namespace management; the Message Type and Flags field.		requires IANA namespace management; the Message Type and Flags field.
10.3.1 Message Type		9.3.1 Message Type
The Message Type namespace is used to identify PANA messages. Values		The Message Type namespace is used to identify PANA messages. Values
0-65,533 are for permanent, standard message types, allocated by IETF		0-65,533 are for permanent, standard message types, allocated by IETF
Consensus [IANA]. This document defines the Message Types 1-10. See		Consensus [IANA]. This document defines the Message Types 1-10. See
Section 8.2.1 through Section 8.2.19 for the assignment of the		Section 7.2.1 through Section 7.2.19 for the assignment of the
namespace in this specification.		namespace in this specification.
The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are		The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are
reserved for experimental messages. As these codes are only for		reserved for experimental messages. As these codes are only for
experimental and testing purposes, no guarantee is made for		experimental and testing purposes, no guarantee is made for
interoperability between communicating PaC and PAA using experimental		interoperability between communicating PaC and PAA using experimental
commands, as outlined in [IANA-EXP].		commands, as outlined in [IANA-EXP].
10.3.2 Flags		9.3.2 Flags
There are 16 bits in the Flags field of the PANA header. This		There are 16 bits in the Flags field of the PANA header. This
document assigns bit 0 ('R'equest), bit 1 ('S'eparate) and bit 2		document assigns bit 0 ('R'equest), bit 1 ('S'eparate) and bit 2
('N'AP Authentication). The remaining bits MUST only be assigned via		('N'AP Authentication). The remaining bits MUST only be assigned via
a Standards Action [IANA].		a Standards Action [IANA].
10.4 AVP Header		9.4 AVP Header
As defined in Section 7.3, the AVP header contains three fields that		As defined in Section 6.3, the AVP header contains three fields that
requires IANA namespace management; the AVP Code, AVP Flags and		requires IANA namespace management; the AVP Code, AVP Flags and
Vendor-Id fields where only the AVP Code and AVP Flags create new		Vendor-Id fields where only the AVP Code and AVP Flags create new
namespaces.		namespaces.
10.4.1 AVP Code		9.4.1 AVP Code
The AVP Code namespace is used to identify attributes. There are		The AVP Code namespace is used to identify attributes. There are
multiple namespaces. Vendors can have their own AVP Codes namespace		multiple namespaces. Vendors can have their own AVP Codes namespace
which will be identified by their Vendor-ID (also known as		which will be identified by their Vendor-ID (also known as
Enterprise-Number) and they control the assignments of their		Enterprise-Number) and they control the assignments of their
vendor-specific AVP codes within their own namespace. The absence of		vendor-specific AVP codes within their own namespace. The absence of
a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA		a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA
controlled AVP Codes namespace. The AVP Codes and sometimes also		controlled AVP Codes namespace. The AVP Codes and sometimes also
possible values in an AVP are controlled and maintained by IANA.		possible values in an AVP are controlled and maintained by IANA.
AVP Code 0 is not used. This document defines the AVP Codes 1-18.		AVP Code 0 is not used. This document defines the AVP Codes 1-18.
See Section 8.3.1 through Section 8.3.18 for the assignment of the		See Section 7.3.1 through Section 7.3.18 for the assignment of the
namespace in this specification.		namespace in this specification.
AVPs may be allocated following Designated Expert with Specification		AVPs may be allocated following Designated Expert with Specification
Required [IANA]. Release of blocks of AVPs (more than 3 at a time		Required [IANA]. Release of blocks of AVPs (more than 3 at a time
for a given purpose) should require IETF Consensus.		for a given purpose) should require IETF Consensus.
Note that PANA defines a mechanism for Vendor-Specific AVPs, where		Note that PANA defines a mechanism for Vendor-Specific AVPs, where
the Vendor-Id field in the AVP header is set to a non-zero value.		the Vendor-Id field in the AVP header is set to a non-zero value.
Vendor-Specific AVPs codes are for Private Use and should be		Vendor-Specific AVPs codes are for Private Use and should be
encouraged instead of allocation of global attribute types, for		encouraged instead of allocation of global attribute types, for
functions specific only to one vendor's implementation of PANA, where		functions specific only to one vendor's implementation of PANA, where
no interoperability is deemed useful. Where a Vendor-Specific AVP is		no interoperability is deemed useful. Where a Vendor-Specific AVP is
implemented by more than one vendor, allocation of global AVPs should		implemented by more than one vendor, allocation of global AVPs should
be encouraged instead.		be encouraged instead.
10.4.2 Flags		9.4.2 Flags
There are 16 bits in the AVP Flags field of the AVP header, defined		There are 16 bits in the AVP Flags field of the AVP header, defined
in Section 7.3. This document assigns bit 0 ('V'endor Specific) and		in Section 6.3. This document assigns bit 0 ('V'endor Specific) and
bit 1 ('M'andatory). The remaining bits should only be assigned via		bit 1 ('M'andatory). The remaining bits should only be assigned via
a Standards Action .		a Standards Action .
10.5 AVP Values		9.5 AVP Values
Certain AVPs in PANA define a list of values with various meanings.		Certain AVPs in PANA define a list of values with various meanings.
For attributes other than those specified in this section, adding		For attributes other than those specified in this section, adding
additional values to the list can be done on a First Come, First		additional values to the list can be done on a First Come, First
Served basis by IANA [IANA].		Served basis by IANA [IANA].
10.5.1 Algorithm Values of MAC AVP		9.5.1 Algorithm Values of MAC AVP
As defined in Section 8.3.1, the Algorithm field of MAC AVP (AVP Code		As defined in Section 7.3.1, the Algorithm field of MAC AVP (AVP Code
1) defines the value of 1 (one) for HMAC-SHA1.		1) defines the value of 1 (one) for HMAC-SHA1.
All remaining values are available for assignment via IETF Consensus		All remaining values are available for assignment via IETF Consensus
[IANA].		[IANA].
10.5.2 Protection-Capability AVP Values		9.5.2 Protection-Capability AVP Values
As defined in Section 8.3.5, the Protection-Capability AVP (AVP Code		As defined in Section 7.3.5, the Protection-Capability AVP (AVP Code
5) defines the values 0 and 1.		5) defines the values 0 and 1.
All remaining values are available for assignment via a Standards		All remaining values are available for assignment via a Standards
Action [IANA].		Action [IANA].
10.5.3 Termination-Cause AVP Values		9.5.3 Termination-Cause AVP Values
As defined in Section 8.3.6, the Termination-Cause AVP (AVP Code 6)		As defined in Section 7.3.6, the Termination-Cause AVP (AVP Code 6)
defines the values 1, 4 and 8.		defines the values 1, 4 and 8.
All remaining values are available for assignment via IETF Consensus		All remaining values are available for assignment via IETF Consensus
[IANA].		[IANA].
10.5.4 Result-Code AVP Values		9.5.4 Result-Code AVP Values
As defined in Section 8.3.7.1 and Section 8.3.7.2 the Result-Code AVP		As defined in Section 7.3.7.1 and Section 7.3.7.2 the Result-Code AVP
(AVP Code 7) defines the values 2001, 3001-3002, 3008-3009, 4001,		(AVP Code 7) defines the values 2001, 3001-3002, 3008-3009, 4001,
5001-5009 and 5011-5019.		5001-5009 and 5011-5019.
All remaining values are available for assignment via IETF Consensus		All remaining values are available for assignment via IETF Consensus
[IANA].		[IANA].
10.5.5 Post-PANA-Address-Configuration AVP Values		9.5.5 Post-PANA-Address-Configuration AVP Values
As defined in Section 8.3.16, the Post-PANA-Address-Configuration AVP		As defined in Section 7.3.16, the Post-PANA-Address-Configuration AVP
(AVP Code 17) defines the bits 0 ('N': no configuration), 1 ('D':		(AVP Code 17) defines the bits 0 ('N': no configuration), 1 ('D':
DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with IPsec		DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with IPsec
tunnel mode) and 4 ('I': IKEv2).		tunnel mode) and 4 ('I': IKEv2).
All remaining values are available for assignment via a Standards		All remaining values are available for assignment via a Standards
Action [IANA].		Action [IANA].
11. Security Considerations		10. Security Considerations
The PANA protocol defines a UDP-based EAP encapsulation that runs		The PANA protocol defines a UDP-based EAP encapsulation that runs
between two IP-enabled nodes on the same IP link. Various security		between two IP-enabled nodes on the same IP link. Various security
threats that are relevant to a protocol of this nature are outlined		threats that are relevant to a protocol of this nature are outlined
in [I-D.ietf-pana-threats-eval]. Security considerations stemming		in [I-D.ietf-pana-threats-eval]. Security considerations stemming
from the use of EAP and EAP methods are discussed in [RFC3748]. This		from the use of EAP and EAP methods are discussed in [RFC3748]. This
section provides a discussion on the security-related issues that are		section provides a discussion on the security-related issues that are
related to PANA framework and protocol design.		related to PANA framework and protocol design.
An important element in assessing security of PANA design and		An important element in assessing security of PANA design and
Skipping to change at page 64, line 27:
link-layer) security. In the context of this document, lower-layers		link-layer) security. In the context of this document, lower-layers
are said to be secure if they can prevent eavesdropping and spoofing		are said to be secure if they can prevent eavesdropping and spoofing
of packets. Examples of such networks are physically-secured DSL		of packets. Examples of such networks are physically-secured DSL
networks and 3GPP2 networks with crytographically-secured cdma2000		networks and 3GPP2 networks with crytographically-secured cdma2000
link-layer. In these examples, the lower-layer security is enabled		link-layer. In these examples, the lower-layer security is enabled
even before running the first PANA-based authentication. In the		even before running the first PANA-based authentication. In the
absence of such a pre-established secure channel, one needs to be		absence of such a pre-established secure channel, one needs to be
created in conjunction with PANA using a link-layer or network-layer		created in conjunction with PANA using a link-layer or network-layer
cryptographic mechanism (e.g., IPsec).		cryptographic mechanism (e.g., IPsec).
11.1 General Security Measures		10.1 General Security Measures
PANA provides multiple mechanisms to secure a PANA session.		PANA provides multiple mechanisms to secure a PANA session.
Since PaC and PAA are on the same IP link, a simple TTL check on the		Since PaC and PAA are on the same IP link, a simple TTL check on the
received PANA messages prevents off-link attacks.		received PANA messages prevents off-link attacks.
PANA messages carry sequence numbers, which are monotonically		PANA messages carry sequence numbers, which are monotonically
incremented by 1 with every new request message. These numbers are		incremented by 1 with every new request message. These numbers are
randomly initialized at the beginning of the session, and verified		randomly initialized at the beginning of the session, and verified
against expected numbers upon receipt. A message whose sequence		against expected numbers upon receipt. A message whose sequence
number is different than the expected one is silently discarded. In		number is different than the expected one is silently discarded. In
addition to accomplishing orderly delivery of EAP messages and		addition to accomplishing orderly delivery of EAP messages and
duplicate elimination, this scheme also helps prevent an adversary		duplicate elimination, this scheme also helps prevent an adversary
spoof messages to disturb ongoing PANA and EAP sessions unless it can		spoof messages to disturb ongoing PANA and EAP sessions unless it can
also eavesdrop to synchronize on the expected sequence number.		also eavesdrop to synchronize on the expected sequence number.
		Furthermore, impact of replay attacks is reduced as any stale message
		(i.e., a request or answer with an unexpected sequence number) and
		any duplicate answer are immediately discarded, and a duplicate
		request can trigger transmission of the cached answer (i.e., no need
		to process the request and generate a new answer).
The PANA framework defines EP which is ideally located on a network		The PANA framework defines EP which is ideally located on a network
device that can filter traffic from the PaCs before the traffic		device that can filter traffic from the PaCs before the traffic
enters the Internet/intranet. A set of filters can be used to		enters the Internet/intranet. A set of filters can be used to
discard unauthorized packets, such as a PANA-Start-Request message		discard unauthorized packets, such as a PANA-Start-Request message
that is received from the segment of the access network where only		that is received from the segment of the access network where only
PaCs are supposed to be connected.		PaCs are supposed to be connected.
The protocol also provides authentication and integrity protection to		The protocol also provides authentication and integrity protection to
PANA messages when the used EAP method can generate cryptographic		PANA messages when the used EAP method can generate cryptographic
Skipping to change at page 65, line 23:
earliest this protection can be enabled is when the very first		earliest this protection can be enabled is when the very first
PANA-Bind-Request or PANA-FirstAuth-End-Request that signals a		PANA-Bind-Request or PANA-FirstAuth-End-Request that signals a
successful authentication is generated. Starting with these		successful authentication is generated. Starting with these
messages, any subsequent PANA message until the session gets torn		messages, any subsequent PANA message until the session gets torn
down can be cryptographically protected.		down can be cryptographically protected.
The PANA SA enables authenticated and integrity protected exchange of		The PANA SA enables authenticated and integrity protected exchange of
the device ID information between the PaC and PAA. This ensures		the device ID information between the PaC and PAA. This ensures
there were no man-in-the-middle during the PANA authentication.		there were no man-in-the-middle during the PANA authentication.
The lifetime of the PANA SA is bounded by the AAA-authorized session		The lifetime of the PANA SA is set to PANA session lifetime which is
lifetime with an additional tolerance period. Unless PANA state is		bounded by the lifetime granted by the authentication server. An
updated by executing another EAP authentication, the PANA SA is		implementation MAY add a tolerance period to that value. Unless the
removed when the current session expires.		PANA session is extended by executing another EAP authentication, the
		PANA SA is removed when the current session expires.
The ability to use cryptographic protection within PANA is determined		The ability to use cryptographic protection within PANA is determined
by the used EAP method, which is generally dictated by the deployment		by the used EAP method, which is generally dictated by the deployment
environment. Insecure lower-layers necessitate use of key-generating		environment. Insecure lower-layers necessitate use of key-generating
EAP methods. In networks where lower-layers are already secured,		EAP methods. In networks where lower-layers are already secured,
cryptographic protection of PANA messages is not necessary.		cryptographic protection of PANA messages is not necessary.
11.2 Discovery		10.2 Discovery
The discovery and handshake phase is vulnerable to spoofing attacks		The discovery and handshake phase is vulnerable to spoofing attacks
as these messages are not authenticated and integrity protected. In		as these messages are not authenticated and integrity protected. In
order to prevent very basic denial-of service attacks an adversary		order to prevent very basic denial-of service attacks an adversary
should not be able to cause state creation by sending discovery		should not be able to cause state creation by sending discovery
messages to the PAA. This protection is achieved by using a		messages to the PAA. This protection is achieved by using a
cookie-based scheme (similar to [RFC2522] which allows the responder		cookie-based scheme (similar to [RFC2522] which allows the responder
(PAA) to be stateless in the first round of message exchange. A		(PAA) to be stateless in the first round of message exchange. A
return-routability test does not provide additional protection as		return-routability test does not provide additional protection as
PANA traffic is not routed but simply forwarded on-link. It is		PANA traffic is not routed but simply forwarded on-link. It is
Skipping to change at page 66, line 8:
In networks where lower-layers are not secured prior to running PANA,		In networks where lower-layers are not secured prior to running PANA,
the capability discovery enabled through inclusion of		the capability discovery enabled through inclusion of
Protection-Capability and Post-PANA-Address-Configuration AVPs in a		Protection-Capability and Post-PANA-Address-Configuration AVPs in a
PANA-Start-Request message is susceptible to spoofing leading to		PANA-Start-Request message is susceptible to spoofing leading to
denial-of service attacks. Therefore, usage of these AVPs during the		denial-of service attacks. Therefore, usage of these AVPs during the
discovery and handshake phase in such insecure networks is NOT		discovery and handshake phase in such insecure networks is NOT
RECOMMENDED. The same AVPs are delivered via an integrity-protected		RECOMMENDED. The same AVPs are delivered via an integrity-protected
PANA-Bind-Request upon successful authentication.		PANA-Bind-Request upon successful authentication.
11.3 EAP Methods		10.3 EAP Methods
Eavesdropping EAP packets might cause problems when the EAP method is		Eavesdropping EAP packets might cause problems when the EAP method is
weak and enables dictionary or replay attacks or even allows an		weak and enables dictionary or replay attacks or even allows an
adversary to learn the long-term password directly. Furthermore, if		adversary to learn the long-term password directly. Furthermore, if
the optional EAP Identity payload is used then it allows the		the optional EAP Identity payload is used then it allows the
adversary to learn the identity of the PaC. In such a case a privacy		adversary to learn the identity of the PaC. In such a case a privacy
problem is prevalent.		problem is prevalent.
To prevent these threats, [I-D.ietf-pana-framework] suggests using		To prevent these threats, [I-D.ietf-pana-framework] suggests using
proper EAP methods for particular environments. Depending on the		proper EAP methods for particular environments. Depending on the
deployment environment an EAP authentication which supports user		deployment environment an EAP authentication which supports user
identity confidentiality, protection against dictionary attacks and		identity confidentiality, protection against dictionary attacks and
session key establishment must be used. It is therefore the		session key establishment must be used. It is therefore the
responsibility of the network operators and users to choose a proper		responsibility of the network operators and users to choose a proper
EAP method.		EAP method.
11.4 Separate NAP and ISP Authentication		10.4 Separate NAP and ISP Authentication
The PANA design allows running two separate EAP sessions for the same		The PANA design allows running two separate EAP sessions for the same
PaC in a single authentication phase: one with the NAP, and one with		PaC in the authentication and authorization phase: one with the NAP,
the ISP. The process of arriving at the resultant authorization,		and one with the ISP. The process of arriving at the resultant
which is a combination of the individual authorizations obtained from		authorization, which is a combination of the individual
respective service providers, is outside the scope of this protocol.		authorizations obtained from respective service providers, is outside
In the absence of lower-layer security, both authentications MUST be		the scope of this protocol. In the absence of lower-layer security,
able to generate a AAA-Key, leading to generation of a PANA SA. The		both authentications MUST be able to generate a AAA-Key, leading to
resultant PANA SA cryptographically binds the two AAA-Keys together,		generation of a PANA SA. The resultant PANA SA cryptographically
hence it prevents man-in-the-middle attacks.		binds the two AAA-Keys together, hence it prevents man-in-the-middle
		attacks.
11.5 Cryptographic Keys		10.5 Cryptographic Keys
When the EAP method exports a AAA-Key, this key is used to produce a		When the EAP method exports a AAA-Key, this key is used to produce a
PANA SA with PANA_MAC_KEY with a distinct key ID. The PANA_MAC_KEY		PANA SA with PANA_MAC_KEY with a distinct key ID. The PANA_MAC_KEY
is unique to the PANA session, and takes PANA-based nonce values into		is unique to the PANA session, and takes PANA-based nonce values into
computation to cryptographically separate itself from the AAA-Key.		computation to cryptographically separate itself from the AAA-Key.
The PANA_MAC_KEY is solely used for authentication and integrity		The PANA_MAC_KEY is solely used for authentication and integrity
protection of the PANA messages within the designated session.		protection of the PANA messages within the designated session.
Two AAA-Keys may be generated as a result of separate NAP and ISP		Two AAA-Keys may be generated as a result of separate NAP and ISP
authentication. In that case, the AAA-Key used with the PANA SA is		authentication. In that case, the AAA-Key used with the PANA SA is
the combination of both keys.		the combination of both keys.
The PANA SA lifetime is bounded by the AAA-Key lifetime. Another		The PANA SA lifetime is bounded by the AAA-Key lifetime. Another
execution of EAP method yields in a new AAA-Key, and updates the PANA		execution of EAP method yields in a new AAA-Key, and updates the PANA
SA, PANA_MAC_KEY and key ID.		SA, PANA_MAC_KEY and key ID.
Upon PaC's movement to a another PAA (new PAA) and request to perform
a context transfer based optimization, the current PAA computes a
AAA-Key-int based on the AAA-Key, ID of new PAA, and the session ID.
This AAA-Key-int is delivered to the new PAA, and used in the
computation of AAA-Key-new, which further takes a pair of nonce
values into account. After this point on, the AAA-Key-new becomes
the AAA-Key between the PaC and the new PAA.
When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is		When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is
enabled as a result of successful PANA authentication, a separate		enabled as a result of successful PANA authentication, a separate
PaC-EP master key is generated based on the AAA-Key, session ID, key		PaC-EP master key is generated based on the AAA-Key, session ID, key
ID, and EP ID.		ID, and EP ID.
The lifetime of PaC-EP master key is bounded by the lifetime of the		The lifetime of PaC-EP master key is bounded by the lifetime of the
PANA SA. This key may be used with a secure association protocol		PANA SA. This key may be used with a secure association protocol
[I-D.ietf-ipsec-ikev2] to produce further cipher-specific and		[I-D.ietf-ipsec-ikev2] to produce further cipher-specific and
transient keys.		transient keys.
11.6 Per-packet Ciphering		10.6 Per-packet Ciphering
Networks that are not secured at the lower-layers prior to running		Networks that are not secured at the lower-layers prior to running
PANA can rely on enabling per-packet data traffic ciphering upon		PANA can rely on enabling per-packet data traffic ciphering upon
successful PANA session establishment. The PANA framework allows		successful PANA session establishment. The PANA framework allows
generation of a PaC-EP master key from AAA-Key for using with a		generation of a PaC-EP master key from AAA-Key for using with a
per-packet protection mechanism, such as link-layer or IPsec-based		per-packet protection mechanism, such as link-layer or IPsec-based
ciphering [I-D.ietf-pana-ipsec]. In case the master key is not		ciphering [I-D.ietf-pana-ipsec]. In case the master key is not
readily useful to the ciphering mechanism, an additional secure		readily useful to the ciphering mechanism, an additional secure
association protocol [I-D.ietf-ipsec-ikev2] may be needed to produce		association protocol [I-D.ietf-ipsec-ikev2] may be needed to produce
the required keying material. These mechanisms ultimately establish		the required keying material. These mechanisms ultimately establish
a cryptographic binding between the data traffic generated by and for		a cryptographic binding between the data traffic generated by and for
a client and the authenticated identity of the client. Data traffic		a client and the authenticated identity of the client. Data traffic
must be minimally data origin authenticated, replay and integrity		must be minimally data origin authenticated, replay and integrity
protected, and optionally encrypted.		protected, and optionally encrypted.
11.7 PAA-to-EP Communication		10.7 PAA-to-EP Communication
The PANA framework allows separation of PAA from EP(s). SNMPv3		The PANA framework allows separation of PAA from EP(s). SNMPv3
[I-D.ietf-pana-snmp] is used between the the PAA and EP for		[I-D.ietf-pana-snmp] is used between the PAA and EP for provisioning
provisioning authorized PaC information on the EP. This exchange		authorized PaC information on the EP. This exchange MUST be always
MUST be always physically or cryptographically protected for		physically or cryptographically protected for authentication,
authentication, integrity and replay protection. It MUST also be		integrity and replay protection. It MUST also be privacy-protected
privacy-protected when PaC-EP master key for per-packet ciphering is		when PaC-EP master key for per-packet ciphering is transmitted to the
transmitted to the EP.		EP.
The PaC-EP master key MUST be unique to the PaC and EP pair. The		The PaC-EP master key MUST be unique to the PaC and EP pair. The
session ID and EP's device ID are taken into computation for		session ID and EP's device ID are taken into computation for
achieving this effect [I-D.ietf-pana-ipsec]. Compromise of an EP		achieving this effect [I-D.ietf-pana-ipsec]. Compromise of an EP
does not automatically lead to compromise of another EP or the PAA.		does not automatically lead to compromise of another EP or the PAA.
11.8 Livenes Test		10.8 Liveness Test
A PANA session is associated with a session lifetime. The session is		A PANA session is associated with a session lifetime. The session is
terminated unless it is refreshed by a new round of EAP		terminated unless it is refreshed by a new round of EAP
authentication before it expires. Therefore, at the latest a		authentication before it expires. Therefore, at the latest a
disconnected client can be detected when its session expires. A		disconnected client can be detected when its session expires. A
disconnect may also be detected earlier by using PANA ping messages.		disconnect may also be detected earlier by using PANA ping messages.
A request message can be generated by either PaC or PAA at any time		A request message can be generated by either PaC or PAA at any time
and the peer must respond with an answer message. A successful		and the peer must respond with an answer message. A successful
round-trip of this exchange is a simple verification that the peer is		round-trip of this exchange is a simple verification that the peer is
alive. This test can be engaged when there is a possibility that the		alive. This test can be engaged when there is a possibility that the
peer might have disconnected (e.g., after the discontinuation of data		peer might have disconnected (e.g., after the discontinuation of data
traffic for an extended period of time). Periodic use of this		traffic for an extended period of time). Periodic use of this
exchange as a keep-alive requires additional care as it might result		exchange as a keep-alive requires additional care as it might result
in congestion and hence false alarms. This exchange is		in congestion and hence false alarms. This exchange is
cryptographically protected when a PANA SA is available in order to		cryptographically protected when a PANA SA is available in order to
prevent threats associated with the abuse of this functionality.		prevent threats associated with the abuse of this functionality.
11.9 Mobility Optimization		10.9 Updating PaC's IP Address
The mobility optimization described in Section 6 involves the
previous PAA (holding AAA-Key) providing a AAA-Key-new to the current
PAA of the PaC. There are security risks stemming from potential
compromise of PAAs. Compromise of the current PAA does not yield
compromise of the previous PAA, as AAA-Key cannot be computed from a
compromised AAA-Key-new. But a compromised previous PAA along with
the intercepted nonce values on the current link leads to the
compromise of AAA-Key-new. Operators should be aware of the
potential risk of using this optimization.
An operator can reduce the risk exposure by forcing the PaC to
perform an EAP-based authentication immediately after the PaC gains
access to new link via the optimized PANA execution. EAP-based
authentication can be run in parallel with IP data packet
transmission.
11.10 Updating PaC's IP Address
Even though the IP-Address AVP in a PANA-Update-Request can be		Even though the IP-Address AVP in a PANA-Update-Request can be
cryptographically protected by the MAC AVP, there is not way to prove		cryptographically protected by the MAC AVP, there is not way to prove
the ownership of the IP address presented by the PaC. Hence an		the ownership of the IP address presented by the PaC. Hence an
authorized PaC can launch a redirect attack by spoofing a victim's IP		authorized PaC can launch a redirect attack by spoofing a victim's IP
address.		address.
11.11 Early Termination of a Session		10.10 Early Termination of a Session
The PANA protocol supports the ability for both the PaC and the PAA		The PANA protocol supports the ability for both the PaC and the PAA
to transmit a tear-down message before the session lifetime expires.		to transmit a tear-down message before the session lifetime expires.
This message causes state removal, a stop of the accounting procedure		This message causes state removal, a stop of the accounting procedure
and removes the installed per-PaC state on the EP(s). This message		and removes the installed per-PaC state on the EP(s). This message
is cryptographically protected when PANA SA is present.		is cryptographically protected when PANA SA is present.
		11. Open Issues and Change History
		A list of open issues is maintained at [1].
		Open issues: 114, 115, 116, 117, 123, 124, 125, 126, 127, 128, 131,
		149 and 150.
		Issues resolved in PANA-07b December 2004: 112, 113, 118, 119, 120,
		121, 122, 129, 130, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141,
		142, 143, 145, 146, 147, 148, 151, 152 and 153.
12. Acknowledgments		12. Acknowledgments
We would like to thank Jari Arkko, Mohan Parthasarathy, Julien		We would like to thank Jari Arkko, Mohan Parthasarathy, Julien
Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik		Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik
Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo		Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo
and all members of the PANA working group for their valuable comments		and all members of the PANA working group for their valuable comments
to this document.		to this document.
13. References		13. References
Skipping to change at page 72, line 37:
[I-D.ietf-pana-framework]		[I-D.ietf-pana-framework]
Jayaraman, P., "PANA Framework",		Jayaraman, P., "PANA Framework",
draft-ietf-pana-framework-02 (work in progress), September		draft-ietf-pana-framework-02 (work in progress), September
2004.		2004.
[I-D.ietf-pana-snmp]		[I-D.ietf-pana-snmp]
Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for		Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for
PAA-2-EP interface", draft-ietf-pana-snmp-02 (work in		PAA-2-EP interface", draft-ietf-pana-snmp-02 (work in
progress), October 2004.		progress), October 2004.
[I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Experimental Handoff Extension
to RADIUS", draft-irtf-aaaarch-handoff-04 (work in
progress), November 2003.
[I-D.ietf-eap-statemachine]		[I-D.ietf-eap-statemachine]
Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba,		Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba,
"State Machines for Extensible Authentication Protocol		"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator",		(EAP) Peer and Authenticator",
draft-ietf-eap-statemachine-05 (work in progress),		draft-ietf-eap-statemachine-05 (work in progress),
September 2004.		September 2004.
[I-D.ietf-seamoby-ctp]
Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-11 (work in progress), August 2004.
[I-D.ietf-ipsec-ikev2]		[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October		draft-ietf-ipsec-ikev2-17 (work in progress), October
2004.		2004.
		[I-D.ietf-dna-link-information]
		Yegin, A., "Link-layer Event Notifications for Detecting
		Network Attachments", draft-ietf-dna-link-information-00
		(work in progress), September 2004.
		[I-D.adrangi-eap-network-discovery]
		Adrangi, F., "Mediating Network Discovery in the
		Extensible Authentication Protocol (EAP)",
		draft-adrangi-eap-network-discovery-06 (work in progress),
		December 2004.
[ianaweb] IANA, "Number assignment", http://www.iana.org.		[ianaweb] IANA, "Number assignment", http://www.iana.org.
[IANA-EXP]		[IANA-EXP]
Narten, T., "Assigning Experimental and Testing Numbers		Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.		Considered Useful", BCP 82, RFC 3692, January 2004.
		URIs
		[1] <http://danforsberg.info:8080/pana-issues/>
Authors' Addresses		Authors' Addresses
Dan Forsberg		Dan Forsberg
Nokia Research Center		Nokia Research Center
P.O. Box 407		P.O. Box 407
FIN-00045 NOKIA GROUP		FIN-00045 NOKIA GROUP
Finland		Finland
Phone: +358 50 4839470		Phone: +358 50 4839470
EMail: dan.forsberg@nokia.com		EMail: dan.forsberg@nokia.com
Skipping to change at page 75, line 18:
illustrated in Figure 13. The example assumes the following		illustrated in Figure 13. The example assumes the following
scenario:		scenario:
o The PaC initiates the discovery and handshake phase.		o The PaC initiates the discovery and handshake phase.
o The PAA offers separate NAP and ISP authentication, as well as a		o The PAA offers separate NAP and ISP authentication, as well as a
choice of ISP from "ISP1" and "ISP2". The PaC accepts the offer		choice of ISP from "ISP1" and "ISP2". The PaC accepts the offer
from PAA, with choosing "ISP1" as the ISP.		from PAA, with choosing "ISP1" as the ISP.
o NAP authentication and ISP authentication is performed in this		o NAP authentication and ISP authentication is performed in this
order in authentication phase.		order in the authentication and authorization phase.
o An EAP authentication method with a single round trip is used in		o An EAP authentication method with a single round trip is used in
each EAP sequence.		each EAP sequence.
o After a PANA SA is established, all messages are integrity and		o After a PANA SA is established, all messages are integrity and
replay protected with MAC AVPs.		replay protected with MAC AVPs.
o Authorization, re-authentication and termination phases are not		o The access, re-authentication and termination phases are not
shown.		shown.
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(seqno)[AVPs]
-----------------------------------------------------		-----------------------------------------------------
// Discovery and handshake phase		// Discovery and handshake phase
-----> PANA-PAA-Discover(0)		-----> PANA-PAA-Discover(0)
<----- PANA-Start-Request(x) // S-flag set		<----- PANA-Start-Request(x) // S-flag set
[Nonce, Cookie,		[Nonce, Cookie,
ISP-Information("ISP1"),		ISP-Information("ISP1"),
ISP-Information("ISP2"),		ISP-Information("ISP2"),
NAP-Information("MyNAP")]		NAP-Information("MyNAP")]
-----> PANA-Start-Answer(x) // S-flag set		-----> PANA-Start-Answer(x) // S-flag set
[Nonce, Cookie, // PaC chooses "ISP1"		[Nonce, Cookie, // PaC chooses "ISP1"
ISP-Information("ISP1")]		ISP-Information("ISP1")]
// Authentication phase		// Authentication and authorization phase
<----- PANA-Auth-Request(x+1) // NAP authentication		<----- PANA-Auth-Request(x+1) // NAP authentication
[Session-Id, EAP{Request}] // S- and N-flags set		[Session-Id, EAP{Request}] // S- and N-flags set
-----> PANA-Auth-Answer(x+1) // S- and N-flags set		-----> PANA-Auth-Answer(x+1) // S- and N-flags set
[Session-Id] // No piggybacking		[Session-Id] // No piggybacking
-----> PANA-Auth-Request(y) // S- and N-flags set		-----> PANA-Auth-Request(y) // S- and N-flags set
[Session-Id, EAP{Response}]		[Session-Id, EAP{Response}]
<----- PANA-Auth-Answer(y)[Session-Id] // S- and N-flags set		<----- PANA-Auth-Answer(y)[Session-Id] // S- and N-flags set
<----- PANA-Auth-Request(x+2) // S- and N-flags set		<----- PANA-Auth-Request(x+2) // S- and N-flags set
[Session-Id, EAP{Request}]		[Session-Id, EAP{Request}]
-----> PANA-Auth-Answer(x+2) // S- and N-flags set		-----> PANA-Auth-Answer(x+2) // S- and N-flags set