draft-ietf-pana-pana-07d.txt		draft-ietf-pana-pana-07e.txt
PANA Working Group D. Forsberg		PANA Working Group D. Forsberg
Internet-Draft Nokia		Internet-Draft Nokia
Expires: June 24, 2005 Y. Ohba (Ed.)		Expires: June 29, 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 24, 2004		December 29, 2004
Protocol for Carrying Authentication for Network Access (PANA)		Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-07d		draft-ietf-pana-pana-07e
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 24, 2005.		This Internet-Draft will expire on June 29, 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 7, line 30:
and identified by a Device Identifier (DI). The PAA and the EAP		and identified by a Device Identifier (DI). The PAA and the EAP
authenticator (and optionally the EAP server) are co-located in		authenticator (and optionally the EAP server) are co-located in
the same node. Note the authentication and authorization		the same node. Note the authentication and authorization
procedure can, according to the EAP model, be also offloaded to		procedure can, according to the EAP model, be also offloaded to
the backend AAA infrastructure.		the backend AAA infrastructure.
PANA Session:		PANA Session:
A PANA session begins with the handshake between the PANA Client		A PANA session begins with the handshake between the PANA Client
(PaC) and the PANA Authentication Agent (PAA), and terminates as a		(PaC) and the PANA Authentication Agent (PAA), and terminates as a
result of an authentication failure, a timeout, or an explicit		result of an authentication or liveness test failure, a message
termination message. A fixed session identifier is maintained		delivery failure after retransmissions reach maximum values,
throughout a session. A session cannot be shared across multiple		session lifetime expiration, or an explicit termination message.
network interfaces. Only one device identifier of the PaC is		A fixed session identifier is maintained throughout a session. A
allowed to be bound to a PANA session for simplicity.		session cannot be shared across multiple network interfaces. Only
		one device identifier of the PaC is allowed to be bound to a PANA
		session for simplicity.
Session Identifier:		Session Identifier:
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.
Skipping to change at page 12, line 12:
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.		cryptographic key computations.
o IP-Address AVP: contains an IP Address of the PaC.		o IP-Address AVP: contains an IP Address of the PaC.
o Notification AVP: contains a displayable message.		o Notification AVP: contains a displayable message.
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
Skipping to change at page 14, line 35:
PANA protocol. A Nonce AVP MUST be included in the		PANA protocol. A Nonce AVP MUST be included in the
PANA-Start-Request and PANA-Start-Answer messages. The nonces are		PANA-Start-Request and PANA-Start-Answer messages. The nonces are
used to establish a PANA SA.		used to establish a PANA SA.
A PANA-Start-Request message in stateless PAA discovery MUST NOT be		A PANA-Start-Request message in stateless PAA discovery MUST NOT be
retransmitted as this voids the statelessness on the PAA. Instead,		retransmitted as this voids the statelessness on the PAA. Instead,
the PaC MUST retransmit the PANA-PAA-Discover message until it		the PaC MUST retransmit the PANA-PAA-Discover message until it
receives a PANA-Start-Request message, and retransmit the		receives a PANA-Start-Request message, and retransmit the
PANA-Start-Answer message until it receives a PANA-Auth-Request		PANA-Start-Answer message until it receives a PANA-Auth-Request
message. The PaC can determine whether the PAA is using stateless		message. The PaC can determine whether the PAA is using stateless
discovery by the presence of Cookie AVP. The PANA-Start-Request		PAA discovery by the presence of Cookie AVP. The PANA-Start-Request
message MUST be retransmitted instead of the PANA-Start-Answer		message MUST be retransmitted instead of the PANA-Start-Answer
message when stateful PAA discovery is used.		message when stateless PAA discovery is not 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 the PANA-Start-Request message based on a timer,		PAA will retransmit the PANA-Start-Request message based on a timer,
if the PaC doesn't respond in time (the message was lost for		if the PaC doesn't respond in time (the message was lost for
example). If the PAA had sent a PANA-Start-Request message without		example). If the PAA had sent a PANA-Start-Request message without
creating a state for the PaC (i.e., a Cookie AVP was included in the		creating a state for the PaC (i.e., a Cookie AVP was included in the
message), then it SHOULD answer to the PANA-PAA-Discover message.		message), then it SHOULD answer to the PANA-PAA-Discover message.
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 with		shows an example sequence for the discovery and handshake phase with
traffic-driven PAA discovery.		traffic-driven PAA discovery.
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(sequence number)[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 the authentication and		(continued to the authentication and
authorization phase)		authorization phase)
Figure 2: Example sequence for the discovery and handshake phase when		Figure 2: Example sequence for the discovery and handshake phase when
PANA-PAA-Discover is sent by the PaC		PANA-PAA-Discover is sent by the PaC
PaC EP PAA Message(seqno)[AVPs]		PaC EP PAA Message(sequence number)[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 the authentication and		(continued to the authentication and
authorization phase)		authorization phase)
Figure 3: Example sequence for the discovery and handshake phase with		Figure 3: Example sequence for the discovery and handshake phase with
traffic-driven PAA discovery		traffic-driven PAA discovery
Skipping to change at page 16, line 21:
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 the PAA to the PaC. This message carries the final		message sent from the PAA to the PaC. This message carries the final
EAP authentication result (whether it is the second EAP		EAP authentication result (whether it is the second EAP
authentication result of NAP and ISP separate authentication, or the		authentication result of NAP and ISP separate authentication, or the
sole EAP authentication result) and the result of PANA		sole EAP authentication result) and the result of PANA
authentication. The PANA-Bind-Request message MUST be acknowledged		authentication. The PANA-Bind-Request message MUST be acknowledged
with a PANA-Bind-Answer (PBA) message. Figure 4 shows an example		with a PANA-Bind-Answer (PBA) message. Figure 4 shows an example
sequence in the authentication and authorization phase (no separate		sequence in the authentication and authorization phase (no separate
authentication).		authentication).
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(sequence number)[AVPs]
--------------------------------------------------------------------		--------------------------------------------------------------------
(continued from the 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, Result-Code, EAP{Success}, Device-Id,
Lifetime, Protection-Cap., PPAC, MAC]		Key-Id, IP-Address, 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, Key-Id, PPAC, MAC]
Figure 4: Example sequence for the authentication and authorization		Figure 4: Example sequence for the authentication and authorization
phase		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 and authorization phase and the keys are		the authentication and authorization phase and the keys are
successfully derived, the PANA message that carries the EAP Success		successfully derived, the PANA message that carries the EAP Success
message (i.e., a PANA-FirstAuth-End-Request or a PANA-Bind-Request		message (i.e., a PANA-FirstAuth-End-Request or a PANA-Bind-Request
message) and any subsequent message MUST contain a MAC AVP.		message) and any subsequent message MUST contain a MAC AVP.
Skipping to change at page 19, line 5:
PANA SA is available.		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(sequence number)[AVPs]
------------------------------------------------------		------------------------------------------------------
-----> PANA-Ping-Request(q)[Session-Id, MAC]		-----> PANA-Ping-Request(q)[Session-Id, MAC]
<----- PANA-Ping-Answer(q)[Session-Id, MAC]		<----- PANA-Ping-Answer(q)[Session-Id, MAC]
Figure 5: Example sequence for PaC-initiated liveness test		Figure 5: Example sequence for PaC-initiated liveness test
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(sequence number)[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
The PANA session in the access phase can enter the re-authentication		The PANA session in the access phase can enter the re-authentication
phase to extend the current session lifetime by re-executing EAP.		phase to extend the current session lifetime by re-executing EAP.
Skipping to change at page 20, line 15:
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 authentication		adding a MAC AVP to each message. Any subsequent EAP authentication
MUST be performed with the same ISP and NAP that was selected during		MUST be performed with the same ISP and NAP that was selected during
the discovery and handshake phase. An example sequence for		the discovery and handshake phase. An example sequence for
re-authentication phase initiated by the PaC is shown in Figure 7.		re-authentication phase initiated by the PaC is shown in Figure 7.
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(sequence number)[AVPs]
------------------------------------------------------		------------------------------------------------------
-----> PANA-Reauth-Request(q)		-----> PANA-Reauth-Request(q)
[Session-Id, MAC]		[Session-Id, MAC]
<----- PANA-Reauth-Answer(q)		<----- PANA-Reauth-Answer(q)
[Session-Id, MAC]		[Session-Id, MAC]
<----- PANA-Auth-Request(p)		<----- PANA-Auth-Request(p)
[Session-Id, EAP{Request}, MAC]		[Session-Id, EAP{Request}, MAC]
-----> PANA-Auth-Answer(p) // No piggybacking EAP Response		-----> PANA-Auth-Answer(p) // No piggybacking EAP Response
[Session-Id, MAC]		[Session-Id, MAC]
-----> PANA-Auth-Request(q+1)		-----> PANA-Auth-Request(q+1)
[Session-Id, EAP{Response}, MAC]		[Session-Id, EAP{Response}, MAC]
<----- PANA-Auth-Answer(q+1) // No piggybacking EAP Response		<----- PANA-Auth-Answer(q+1) // No piggybacking EAP Response
[Session-Id, MAC]		[Session-Id, MAC]
<----- PANA-Auth-Request(p+1)		<----- PANA-Auth-Request(p+1)
[Session-Id, EAP{Request}, MAC]		[Session-Id, EAP{Request}, MAC]
-----> PANA-Auth-Answer(p+1) // Piggybacking EAP Response		-----> PANA-Auth-Answer(p+1) // Piggybacking EAP Response
[Session-Id, EAP{Response}, MAC]		[Session-Id, EAP{Response}, MAC]
<----- PANA-Bind-Request(p+2)		<----- PANA-Bind-Request(p+2)
[Session-Id, EAP{Success}, Device-Id, Key-Id,		[Session-Id, Result-Code, EAP{Success}, Device-Id, Key-Id,
IP-Address, Lifetime, Protection-Cap., PPAC, MAC]		IP-Address, Lifetime, Protection-Cap., PPAC, MAC]
-----> PANA-Bind-Answer(p+2)		-----> PANA-Bind-Answer(p+2)
[Session-Id, Device-Id, Key-Id, PPAC, MAC]		[Session-Id, Device-Id, Key-Id, PPAC, MAC]
Figure 7: Example sequence for the re-authentication phase initiated		Figure 7: Example sequence for the re-authentication phase initiated
by PaC		by PaC
4.6 Termination Phase		4.6 Termination Phase
A procedure for explicitly terminating a PANA session can be		A procedure for explicitly terminating a PANA session can be
Skipping to change at page 21, line 9:
PANA-Termination-Answer message exchanges are used for disconnect		PANA-Termination-Answer message exchanges are used for disconnect
indication and session revocation procedures.		indication and session revocation procedures.
The reason for termination is indicated in the Termination-Cause AVP.		The reason for termination is indicated in the Termination-Cause AVP.
When there is an established PANA SA between the PaC and the PAA, all		When there is an established PANA SA between the PaC and the PAA, all
messages exchanged during the termination phase MUST be protected		messages exchanged during the termination phase MUST be protected
with a MAC AVP. When the sender of the PANA-Termination-Request		with a MAC AVP. When the sender of the PANA-Termination-Request
message receives a valid acknowledgment, all states maintained for		message receives a valid acknowledgment, all states maintained for
the PANA session MUST be deleted immediately.		the PANA session MUST be deleted immediately.
PaC PAA Message(seqno)[AVPs]		PaC PAA Message(sequence number)[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 the termination phase triggered by PaC		Figure 8: Example sequence for the termination phase 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 the		PANA allows running at most two EAP sessions in sequence in the
authentication and authorization phase to support separate NAP and		authentication and authorization phase to support separate NAP and
Skipping to change at page 25, line 14:
The initial discovery and handshake phase requires special handling.		The initial discovery and handshake phase requires special handling.
The PaC MUST retransmit the PANA-PAA-Discover message if a subsequent		The PaC MUST retransmit the PANA-PAA-Discover message if a subsequent
PANA-Start-Request message is not received in time. Even though a		PANA-Start-Request message is not received in time. Even though a
PANA-Start-Request message is received, the PANA-PAA-Discover message		PANA-Start-Request message is received, the PANA-PAA-Discover message
may still have to be retransmitted. This is because stateless PAA		may still have to be retransmitted. This is because stateless PAA
discovery requires one time transmission of a solicited		discovery requires one time transmission of a solicited
PANA-Start-Request message. The PAA MUST NOT start a timer and		PANA-Start-Request message. The PAA MUST NOT start a timer and
retransmit the request in order to avoid state creation. If the		retransmit the request in order to avoid state creation. If the
received PANA-Start-Request message included a Cookie AVP (an		received PANA-Start-Request message included a Cookie AVP (an
indication of stateless discovery), the PaC MUST retransmit the		indication of stateless PAA discovery), the PaC MUST retransmit the
PANA-PAA-Discover message until the first PANA-Auth-Request message		PANA-PAA-Discover message until the first PANA-Auth-Request message
is received. Otherwise, the PaC can rely on the PAA to retransmit		is received. Otherwise, the PaC can rely on the PAA to retransmit
the PANA-Start-Request message as soon as the PaC receives the first		the PANA-Start-Request message as soon as the PaC receives the first
one (i.e., the PaC can stop sending the PANA-PAA-Discover message).		one (i.e., the PaC can stop sending the PANA-PAA-Discover message).
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 8 for default		[RFC2988] to provide congestion control. See Section 8 for default
timer and maximum retransmission count parameters.		timer and maximum retransmission count parameters.
The PaC and PAA MUST respond to duplicate requests. The last		The PaC and PAA MUST respond to duplicate requests. The last
Skipping to change at page 28, line 36:
+ 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.
+ PANA-Reauth-Request.		+ PANA-Reauth-Request.
+ PANA-Error-Request.		+ PANA-Error-Request.
* In the authentication and authorization phase:		* In the authentication and authorization phase and the
		re-authentication 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.
Skipping to change at page 30, line 9:
It is assumed that the PAA knows the link type and the security		It is assumed that the PAA knows the link type and the security
mechanisms being provided or required on the access network (e.g.,		mechanisms being provided or required on the access network (e.g.,
based on physical security, link-layer ciphers enabled before or		based on physical security, link-layer ciphers enabled before or
after PANA, or IPsec). Based on that information, the PAA can decide		after PANA, or IPsec). Based on that information, the PAA can decide
what type of EP device id will be used when running PANA with the		what type of EP device id will be used when running PANA with the
client. When IPsec-based security [I-D.ietf-pana-ipsec] is the		client. When IPsec-based security [I-D.ietf-pana-ipsec] is the
choice of access control, the PAA SHOULD provide IP address(es) as		choice of access control, the PAA SHOULD provide IP address(es) as
EP(s)' device ID, and expect the PaC to provide its IP address in		EP(s)' device ID, and expect the PaC to provide its IP address in
return. In case IPsec is not used, MAC addresses are used as device		return. In case IPsec is not used, MAC addresses are used as device
IDs when available. If non-IPsec access control is enabled, and a		identifiers when available. If non-IPsec access control is enabled,
MAC address is not available, device ID exchange does not occur		and a MAC address is not available, device ID exchange does not occur
within PANA. Instead, peers rely on lower-layers to provide		within PANA. Instead, peers rely on lower-layers to provide
locally-significant identifiers along with received PANA messages.		locally-significant identifiers along with received PANA messages.
5.7 PaC Updating its IP Address		5.7 PaC Updating its IP Address
A PaC's IP address can change in certain situations. For example,		A PaC's IP address can change in certain situations. For example,
the PANA framework [I-D.ietf-pana-framework] describes a case in		the PANA framework [I-D.ietf-pana-framework] describes a case in
which a PaC replaces a pre-PANA address (PRPA) with a post-PANA		which a PaC replaces a pre-PANA address (PRPA) with a post-PANA
address (POPA), and the PaC and PAA create host routes to each other		address (POPA), and the PaC and PAA create host routes to each other
in order to maintain on-link communication based on the POPA. The		in order to maintain on-link communication based on the POPA. The
Skipping to change at page 32, line 22:
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
response message, the receiver of the PANA-Error-Request message		response message, the receiver of the PANA-Error-Request message
SHOULD NOT resend the same response until it receives the next		SHOULD NOT resend the same response until it receives the next
request.		request.
Erroneous PANA messages may be exploited by adverseries to launch DoS		Erroneous PANA messages may be exploited by adversaries to launch DoS
attacks on the victims. Unless the PaC or PAA rate-limits the		attacks on the victims. Unless the PaC or PAA rate-limits the
generated PANA-Error-Request messages it may be overburdened by		generated PANA-Error-Request messages it may be overburdened by
having tp respond to bogus messages. Limiting the number of error		having to respond to bogus messages. 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. PANA Headers and Formats		6. PANA Headers and Formats
Skipping to change at page 34, line 34:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
an answer.		an answer.
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 the 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. The PaC may also respond
a PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer		with the S-flag not set which implies the PaC has chosen to
and PANA-Bind-Request/Answer messages it indicates that		authenticate with the ISP only. When the S-flag is set in a
separate NAP and ISP authentication is being performed in the		PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and
		PANA-Bind-Request/Answer messages it indicates that separate
		NAP and ISP authentication is being performed in the
authentication and authorization phase. For other cases,		authentication and authorization phase. For other cases,
S-flag MUST NOT be set.		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
copied from the request. The N-flag MUST NOT be set when		copied from the request. The N-flag MUST NOT be set when
S-flag is not set.		S-flag is not set.
Skipping to change at page 40, line 10:
; qualifier, then exactly one such AVP MUST		; qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no		; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be		; qualifier, then 0 or 1 such AVP may be
; present.		; present.
;		;
; NOTE: "[" and "]" have a different meaning		; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above).		; than in ABNF (see the optional rule, above).
; These braces cannot be used to express		; These braces cannot be used to express
; optional fixed rules (such as an optional		; optional fixed rules (such as an optional
; ICV at the end). To do this, the convention		; MAC at the end). To do this, the convention
; is '0*1fixed'.		; is '0*1fixed'.
min = 1*DIGIT		min = 1*DIGIT
; The minimum number of times the element may		; The minimum number of times the element may
; be present. The default value is zero.		; be present. The default value is zero.
max = 1*DIGIT		max = 1*DIGIT
; The maximum number of times the element may		; The maximum number of times the element may
; be present. The default value is infinity. A		; be present. The default value is infinity. A
; value of zero implies the AVP MUST NOT be		; value of zero implies the AVP MUST NOT be
Skipping to change at page 41, line 11:
PANA-PAA-Discover ::= < PANA-Header: 1 >		PANA-PAA-Discover ::= < PANA-Header: 1 >
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
7.2.2 PANA-Start-Request (PSR)		7.2.2 PANA-Start-Request (PSR)
The PANA-Start-Request (PSR) message is sent by the PAA to the PaC to		The PANA-Start-Request (PSR) message is sent by the PAA to the PaC to
advertise availability of the PAA and start PANA authentication. The		advertise availability of the PAA and start PANA authentication. The
PAA sets the sequence number to an initial random value.		PAA sets 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 ]
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
7.2.3 PANA-Start-Answer (PSA)		7.2.3 PANA-Start-Answer (PSA)
The PANA-Start-Answer (PSA) message is sent by the PaC to the PAA in		The PANA-Start-Answer (PSA) message is sent by the PaC to the PAA in
response to a PANA-Start-Request message. This message completes the		response to a PANA-Start-Request message. This message completes the
handshake to start PANA authentication.		handshake to start PANA authentication.
PANA-Start-Answer ::= < PANA-Header: 2 [SEP] >		PANA-Start-Answer ::= < PANA-Header: 2 [, SEP] >
{ Nonce }		{ Nonce }
[ Cookie ]		[ Cookie ]
[ EAP-Payload ]		[ EAP-Payload ]
[ ISP-Information ]		[ ISP-Information ]
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >
7.2.4 PANA-Auth-Request (PAR)		7.2.4 PANA-Auth-Request (PAR)
The PANA-Auth-Request (PAR) message is either sent by the PAA or the		The PANA-Auth-Request (PAR) message is either sent by the PAA or the
PaC. Its main task is to carry an EAP-Payload AVP.		PaC. Its 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 >
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.5 PANA-Auth-Answer (PAN)		7.2.5 PANA-Auth-Answer (PAN)
THe PANA-Auth-Answer (PAN) message is sent by either the PaC or the		THe PANA-Auth-Answer (PAN) message is sent by either the PaC or the
PAA in response to a PANA-Auth-Request message. It MAY carry an		PAA in response to a PANA-Auth-Request message. It MAY carry an
EAP-Payload AVP.		EAP-Payload 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 ]
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.6 PANA-Reauth-Request (PRAR)		7.2.6 PANA-Reauth-Request (PRAR)
The PANA-Reauth-Request (PRAR) message is sent by the PaC to the PAA		The PANA-Reauth-Request (PRAR) message is sent by the PaC to the PAA
to re-initiate EAP authentication.		to re-initiate EAP authentication.
Skipping to change at page 42, line 45:
< Session-Id >		< Session-Id >
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.8 PANA-Bind-Request (PBR)		7.2.8 PANA-Bind-Request (PBR)
The PANA-Bind-Request (PBR) message is sent by the PAA to the PaC to		The PANA-Bind-Request (PBR) message is sent by the PAA to the PaC to
deliver the result of PANA authentication.		deliver the 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 ]
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.9 PANA-Bind-Answer (PBA)		7.2.9 PANA-Bind-Answer (PBA)
The PANA-Bind-Answer (PBA) message is sent by the PaC to the PAA in		The PANA-Bind-Answer (PBA) message is sent by the PaC to the PAA in
response to a PANA-Bind-Request message.		response to a 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 }
[ PPAC ]		[ PPAC ]
[ Device-Id ]		[ Device-Id ]
[ Key-Id ]		[ Key-Id ]
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.10 PANA-Ping-Request (PPR)		7.2.10 PANA-Ping-Request (PPR)
The PANA-Ping-Request (PPR) message is either sent by the PaC or the		The PANA-Ping-Request (PPR) message is either sent by the PaC or the
Skipping to change at page 44, line 33:
< Session-Id >		< Session-Id >
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.14 PANA-Error-Request (PER)		7.2.14 PANA-Error-Request (PER)
The PANA-Error-Request (PER) message is sent either by the PaC or the		The PANA-Error-Request (PER) message is sent either by the PaC or the
PAA to report an error with the last received PANA message.		PAA to report an error 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 ]
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.15 PANA-Error-Answer (PEA)		7.2.15 PANA-Error-Answer (PEA)
The PANA-Error-Answer (PEA) message is sent in response to a		The PANA-Error-Answer (PEA) message is sent in response to a
PANA-Error-Request.		PANA-Error-Request.
PANA-Error-Answer ::= < PANA-Header: 8 >		PANA-Error-Answer ::= < PANA-Header: 8 >
< Session-Id >		< Session-Id >
		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.16 PANA-FirstAuth-End-Request (PFER)		7.2.16 PANA-FirstAuth-End-Request (PFER)
The PANA-FirstAuth-End-Request (PFER) message is sent by the PAA to		The PANA-FirstAuth-End-Request (PFER) message is sent by the PAA to
the PaC to signal the result of the first EAP authentication method		the PaC to signal the result of the first EAP authentication method
when separate NAP and ISP authentication is performed.		when 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 }
{ Result-Code }		{ Result-Code }
		[ EAP-Payload ]
[ Key-Id ]		[ Key-Id ]
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.17 PANA-FirstAuth-End-Answer (PFEA)		7.2.17 PANA-FirstAuth-End-Answer (PFEA)
The PANA-FirstAuth-End-Answer (PFEA) message is sent by the PaC to		The PANA-FirstAuth-End-Answer (PFEA) message is sent by the PaC to
the PAA in response to a PANA-FirstAuth-End-Request message.		the PAA in 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 ]
[ Notification ]		[ Notification ]
* [ AVP ]		* [ AVP ]
0*1 < MAC >		0*1 < MAC >
7.2.18 PANA-Update-Request (PUR)		7.2.18 PANA-Update-Request (PUR)
The PANA-Update-Request (PUR) message is sent either by the PaC or		The PANA-Update-Request (PUR) message is sent either by the PaC or
the PAA to deliver attribute updates and notifications. In the scope		the PAA to deliver attribute updates and notifications. In the scope
Skipping to change at page 47, line 5:
0-1 Zero or one instance of the AVP MAY be present in the message.		0-1 Zero or one instance of the AVP MAY be present in the message.
It is considered an error if there are more than one instance		It is considered an error if there are more than one instance
of the AVP.		of the AVP.
1 One instance of the AVP MUST be present in the message.		1 One instance of the AVP MUST be present in the message.
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|PPR|PPA|PTR|PTA|		Attribute Name |PDI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA|
--------------------+---+---+---+---+---+---+---+---+---+---+---+		--------------------+---+---+---+---+---+----+----+---+---+---+---+
Cookie |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Cookie | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 | 0 | 0 | 0 |		Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0+|0-1| 0 | 0 |
EAP-Payload |0-1|0-1| 1 |0-1|0-1| 0 | 0 | 0 | 0 | 0 | 0 |		EAP-Payload | 0 |0-1|0-1| 1 |0-1| 0 | 0 |0-1| 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		IP-Address | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
ISP-Information | 0+|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		ISP-Information | 0 | 0+|0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 | 0 | 0 | 0 |		Key-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1|0-1| 0 | 0 |
MAC | 0 |0-1|0-1|0-1|0-1|0-1| 0 |0-1|0-1|0-1|0-1|		MAC | 0 | 0 | 0 |0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1|
NAP-Information |0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		NAP-Information | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Nonce | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Nonce | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Notification |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|		Notification |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
PPAC |0-1| 0 | 0 | 0 | 1 |0-1| 0 | 0 | 0 | 0 | 0 |		PPAC | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 1 |0-1| 0 | 0 |
Protection-Cap. |0-1| 0 | 0 | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 |		Protection-Cap. | 0 |0-1| 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 |
Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |		Result-Code | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 1 |		Session-Id | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
Session-Lifetime | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 | 0 | 0 | 0 |		Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 |0-1| 0 | 0 | 0 |
Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |		Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
--------------------+---+---+---+---+---+---+---+---+---+---+---+		--------------------+---+---+---+---+---+----+----+---+---+---+---+
Figure 10: AVP Occurrence Table (1/2)		Figure 10: AVP Occurrence Table (1/2)
+-----------------------------------+		+---------------------------------+
| Message |		| Message |
| Type |		| Type |
+----+----+---+---+---+---+----+----+		+---+---+---+---+----+----+---+---+
Attribute Name |PFER|PFEA|PUR|PUA|PER|PEA|PRAR|PRAA|		Attribute Name |PTR|PTA|PER|PEA|PFER|PFEA|PUR|PUA|
--------------------+----+----+---+---+---+---+----+----+		--------------------+---+---+---+---+----+----+---+---+
Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
EAP-Payload | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		EAP-Payload | 0 | 0 | 0 | 0 |0-1 | 0 | 0 | 0 |
Failed-AVP | 0 | 0 | 0 | 0 | 0+| 0 | 0 | 0 |		Failed-AVP | 0 | 0 | 0+| 0 | 0 | 0 | 0 | 0 |
IP-Address | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |		IP-Address | 0 | 0 | 0 | 0 | 0 | 0 |0-1| 0 |
ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Key-Id |0-1 |0-1 | 0 | 0 | 0 | 0 | 0 | 0 |		Key-Id | 0 | 0 | 0 | 0 |0-1 |0-1 | 0 | 0 |
MAC |0-1 |0-1 |0-1|0-1|0-1|0-1|0-1 |0-1 |		MAC |0-1 |0-1 |0-1|0-1|0-1|0-1|0-1 |0-1 |
NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Nonce | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Notification |0-1 |0-1 |0-1|0-1|0-1|0-1|0-1 |0-1 |		Notification |0-1 |0-1 |0-1|0-1|0-1|0-1|0-1 |0-1 |
PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		PPAC | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Result-Code | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |		Result-Code | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 |
Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |		Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |		Termination-Cause | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
--------------------+----+----+---+---+---+---+----+----+		--------------------+---+---+---+---+----+----+---+---+
Figure 11: AVP Occurrence Table (2/2)		Figure 11: AVP Occurrence Table (2/2)
7.3.1 Cookie AVP		7.3.1 Cookie AVP
The Cookie AVP (AVP Code 1) is used for carrying a random value		The Cookie AVP (AVP Code 1) is used for carrying a random value
generated by the PAA. The AVP data is of type OctetString. The		generated by the PAA. The AVP data is of type OctetString. The
random value is referred to as a cookie and used for making PAA		random value is referred to as a cookie and used for making PAA
discovery robust against blind resource consumption DoS attacks. The		discovery robust against blind resource consumption DoS attacks. The
exact algorithms and syntax used by the PAA to generate a cookie does		exact algorithms and syntax used by the PAA to generate a cookie does
Skipping to change at page 50, line 43:
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: 9 >		NAP-Information ::= < AVP Header: 9 >
0*1 { Provider-Identifier }		0*1 { Provider-Identifier }
{ Provider-Name }		{ Provider-Name }
* [ AVP ]		* [ AVP ]
7.3.10 Nonce AVP		7.3.10 Nonce AVP
The Nonce AVP (AVP Code 10) carries a randomly chosen value that is		The Nonce AVP (AVP Code 10) carries a randomly chosen value that is
used in cyrptographic key computations. The AVP data is of type		used in cryptographic 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.
7.3.11 Notification AVP		7.3.11 Notification AVP
The Notification AVP (AVP Code 11) is optionally used to convey a		The Notification AVP (AVP Code 11) is optionally used to convey a
displayable message sent by either the PaC or the PAA. It can be		displayable message sent by either the PaC or the PAA. It can be
included in any message, whether it is a request or answer. In case		included in any message, whether it is a request or answer. In case
a notification needs to be sent but there is no outgoing PANA message		a notification needs to be sent but there is no outgoing PANA message
to deliver this AVP, a PANA-Update-Request that only carries a		to deliver this AVP, a PANA-Update-Request that only carries a
Skipping to change at page 75, line 29:
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 The access, 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(sequence number)[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"
Skipping to change at page 76, line 23:
[Session-Id, MAC] // No piggybacking		[Session-Id, MAC] // No piggybacking
-----> PANA-Auth-Request(y+1) // S-flag set		-----> PANA-Auth-Request(y+1) // S-flag set
[Session-Id, EAP{Response}, MAC]		[Session-Id, EAP{Response}, MAC]
<----- PANA-Auth-Answer(y+1) // S-flag set		<----- PANA-Auth-Answer(y+1) // S-flag set
[Session-Id, MAC]		[Session-Id, MAC]
<----- PANA-Auth-Request(x+5) // S-flag set		<----- PANA-Auth-Request(x+5) // S-flag set
[Session-Id, EAP{Request}, MAC]		[Session-Id, EAP{Request}, MAC]
-----> PANA-Auth-Answer(x+5) // S-flag set		-----> PANA-Auth-Answer(x+5) // S-flag set
[Session-Id, EAP{Response}, MAC] // Piggybacking		[Session-Id, EAP{Response}, MAC] // Piggybacking
<----- PANA-Bind-Request(x+6) // S-flag set		<----- PANA-Bind-Request(x+6) // S-flag set
[Session-Id, EAP{Success}, Device-Id,		[Session-Id, Result-Code, EAP{Success}, Device-Id,
IP-Address, Key-Id, Lifetime,		IP-Address, Key-Id, Lifetime,
Protection-Cap., PPAC, MAC]		Protection-Cap., PPAC, MAC]
-----> PANA-Bind-Answer(x+6) // S-flag set		-----> PANA-Bind-Answer(x+6) // S-flag set
[Session-Id, Device-Id, Key-Id,		[Session-Id, Device-Id, Key-Id,
PPAC, MAC]		PPAC, MAC]
Figure 12: A Complete Message Sequence for Separate NAP and ISP		Figure 12: A Complete Message Sequence for Separate NAP and ISP
Authentication		Authentication
Intellectual Property Statement		Intellectual Property Statement