PANA Working Group                                           D. Forsberg
Internet-Draft                                                     Nokia
Expires: April 20, June 29, 2005                                     Y. Ohba (Ed.)
                                                                 Toshiba
                                                                B. Patil
                                                                   Nokia
                                                           H. Tschofenig
                                                                 Siemens
                                                                A. Yegin
                                                                 Samsung
                                                        October 20,
                                                       December 29, 2004

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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   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
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 20, June 29, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   Extensible Authentication Protocol (EAP)

   This document defines a number of
   authentication schemes.  Network access authentication requires a
   host to authenticate itself before being authorized for sending and
   receiving packets.  The the Protocol for Carrying Authentication for
   Network Access (PANA) is defined in this document.  PANA is (PANA), a link-layer agnostic carrier transport for EAP. Extensible
   Authentication Protocol (EAP) to enable network access authentication
   between clients and access networks.  PANA specifies can carry any
   authentication method that can be specified as an EAP method, and it
   can be used on any link that can carry IP.  PANA protocol
   specification covers the client-to-network access authentication within the scope part
   of an overall secure network access framework. framework, which additionally
   includes other protocols and mechanisms for service provisioning,
   access control as a result of initial authentication, and accounting.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1  Specification of Requirements  . . . . . . . . . . . . . .   5
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   6   7
   3.   Protocol Overview  . . . . . . . . . . . . . . . . . . . . .   8   9
   4.   Protocol Details . . . . . . . . . . . . . . . . . . . . . .  10  11
     4.1  Discovery and Handshake Phase  Payload Encoding . . . . . . . . . . . . . . .  10
     4.2  Authentication Phase . . . . . .  11
     4.2  Discovery and Handshake Phase  . . . . . . . . . . . . . .  13  12
     4.3  Authentication and Authorization Phase . . . . . . . . . .  15
     4.4  Access Phase . . . . . . . . .  15
     4.4  Re-authentication Phase  . . . . . . . . . . . . . . . . .  15  18
     4.5  Termination  Re-authentication Phase  . . . . . . . . . . . . . . . . . . . .  17
   5.   Protocol Design Details and Processing Rules  19
     4.6  Termination Phase  . . . . . . . .  19
     5.1  Payload Encoding . . . . . . . . . . . .  20
     4.7  Separate NAP and ISP Authentication  . . . . . . . . .  19
     5.2  Transport Layer . .  21
       4.7.1  Negotiating Separate NAP and ISP Authentication  . . .  21
       4.7.2  Execution of Separate NAP and ISP Authentication . . .  22
       4.7.3  AAA-Key Calculation  . . . . . . . . . . . . .  20
       5.2.1  Fragmentation . . . .  23
   5.   Protocol Design Details and Processing Rules . . . . . . . .  24
     5.1  Transport Layer  . . . . . . . .  20
     5.3  Sequence Number and Retransmission . . . . . . . . . . . .  20
     5.4  Message Authentication Code .  24
       5.1.1  Fragmentation  . . . . . . . . . . . . . .  21
     5.5  Message Validity Check . . . . . .  24
     5.2  Sequence Number and Retransmission . . . . . . . . . . . .  21
     5.6  24
     5.3  PANA Security Association  . . . . . . . . . . . . . . . .  23
     5.7  Error Handling  25
     5.4  Message Authentication Code  . . . . . . . . . . . . . . .  27
     5.5  Message Validity Check . . . . . . .  25
     5.8  Device ID Choice . . . . . . . . . . .  28
     5.6  Device ID Choice . . . . . . . . . .  25
     5.9  Updating PaC' Address  . . . . . . . . . . . . . . . . . .  26
     5.10   Session Lifetime . . . . . . . . . . . . . . . . . . . .  26
     5.11   Network Selection  . . . . . . . . . . . . . . . . . . .  27
     5.12   Separate NAP and ISP Authentication  . . . . . . . . . .  27
       5.12.1   Negotiating Separate NAP and ISP Authentication  . .  28
       5.12.2   Execution of Separate NAP and ISP Authentication . .  28
       5.12.3   AAA-Key Calculation  . . . . . . . . . . . . . . . .  29
       5.12.4   Re-authentication  . .
     5.7  PaC Updating its IP Address  . . . . . . . . . . . . . . .  30
       5.12.5   Example Sequence . . . . . . . . .
     5.8  Session Lifetime . . . . . . . . .  30
   6.   Security and Mobility . . . . . . . . . . . .  30
     5.9  Network Selection  . . . . . . .  32
     6.1  PANA Security Association Establishment . . . . . . . . .  32
     6.2  Mobility . . . .  31
     5.10   Error Handling . . . . . . . . . . . . . . . . . . . . .  32
   7.
   6.   PANA Headers and Formats . . . . . . . . . . . . . . . . . .  35
     7.1  33
     6.1  IP and UDP Headers . . . . . . . . . . . . . . . . . . . .  35
     7.2  33
     6.2  PANA Header  . . . . . . . . . . . . . . . . . . . . . . .  35
     7.3  33
     6.3  AVP Header . . . . . . . . . . . . . . . . . . . . . . . .  37
   8.  35
   7.   PANA Messages, Message Specifications and AVPs . . . . . . .  40
     8.1  38
     7.1  PANA Messages  . . . . . . . . . . . . . . . . . . . . . .  40
     8.2  38
     7.2  PANA Message Specifications . . . . . ABNF Specification  . . . . . . . . . . . . .  40
       8.2.1  38
       7.2.1  PANA-PAA-Discover (PDI)  . . . . . . . . . . . . . . .  41
       8.2.2  40
       7.2.2  PANA-Start-Request (PSR) . . . . . . . . . . . . . . .  41
       8.2.3
       7.2.3  PANA-Start-Answer (PSA)  . . . . . . . . . . . . . . .  41
       8.2.4
       7.2.4  PANA-Auth-Request (PAR)  . . . . . . . . . . . . . . .  41
       8.2.5
       7.2.5  PANA-Auth-Answer (PAN) . . . . . . . . . . . . . . . .  42
       8.2.6
       7.2.6  PANA-Reauth-Request (PRAR) . . . . . . . . . . . . . .  42
       8.2.7
       7.2.7  PANA-Reauth-Answer (PRAA)  . . . . . . . . . . . . . .  42
       8.2.8
       7.2.8  PANA-Bind-Request (PBR)  . . . . . . . . . . . . . . .  42
       8.2.9
       7.2.9  PANA-Bind-Answer (PBA) . . . . . . . . . . . . . . . .  43
       8.2.10
       7.2.10   PANA-Ping-Request (PPR)  . . . . . . . . . . . . . .  43
       8.2.11
       7.2.11   PANA-Ping-Answer (PPA) . . . . . . . . . . . . . . .  43
       8.2.12
       7.2.12   PANA-Termination-Request (PTR) . . . . . . . . . . .  43
       8.2.13  44
       7.2.13   PANA-Termination-Answer (PTA)  . . . . . . . . . . .  44
       8.2.14
       7.2.14   PANA-Error-Request (PER) . . . . . . . . . . . . . .  44
       8.2.15
       7.2.15   PANA-Error-Answer (PEA)  . . . . . . . . . . . . . .  44
       8.2.16
       7.2.16   PANA-FirstAuth-End-Request (PFER)  . . . . . . . . .  44
       8.2.17  45
       7.2.17   PANA-FirstAuth-End-Answer (PFEA) . . . . . . . . . .  45
       8.2.18
       7.2.18   PANA-Update-Request (PUR)  . . . . . . . . . . . . .  45
       8.2.19
       7.2.19   PANA-Update-Answer (PUA) . . . . . . . . . . . . . .  45
     8.3  46
     7.3  AVPs in PANA . . . . . . . . . . . . . . . . . . . . . . .  45
       8.3.1  MAC  46
       7.3.1  Cookie AVP . . . . . . . . . . . . . . . . . . . . . . .  48
       8.3.2
       7.3.2  Device-Id AVP  . . . . . . . . . . . . . . . . . . . .  49
       8.3.3  Session-Id  48
       7.3.3  EAP-Payload AVP  . . . . . . . . . . . . . . . . . . . .  49
       8.3.4  Cookie
       7.3.4  Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . .  49
       8.3.5  Protection-Capability
       7.3.5  IP-Address AVP . . . . . . . . . . . . . . . . . . . .  49
       8.3.6  Termination-Cause
       7.3.6  ISP-Information AVP  . . . . . . . . . . . . . . . . .  49
       8.3.7  Result-Code
       7.3.7  Key-Id AVP . . . . . . . . . . . . . . . . . . .  50
       8.3.8  EAP-Payload . . .  49
       7.3.8  MAC AVP  . . . . . . . . . . . . . . . . . . .  54
       8.3.9  Session-Lifetime . . . .  50
       7.3.9  NAP-Information AVP  . . . . . . . . . . . . . . . . .  54
       8.3.10   Failed-AVP  50
       7.3.10   Nonce AVP  . . . . . . . . . . . . . . . . . . .  54
       8.3.11   NAP-Information . .  50
       7.3.11   Notification AVP . . . . . . . . . . . . . . . .  54
       8.3.12   ISP-Information . .  50
       7.3.12   Post-PANA-Address-Configuration (PPAC) AVP . . . . .  51
       7.3.13   Protection-Capability AVP  . . . . . . . . . . . . .  54
       8.3.13  52
       7.3.14   Provider-Identifier AVP  . . . . . . . . . . . . . .  54
       8.3.14  52
       7.3.15   Provider-Name AVP  . . . . . . . . . . . . . . . . .  55
       8.3.15   Key-Id  52
       7.3.16   Result-Code AVP  . . . . . . . . . . . . . . . . . .  52
       7.3.17   Session-Id AVP . . .  55
       8.3.16   Post-PANA-Address-Configuration (PPAC) AVP . . . . .  55
       8.3.17   Nonce AVP . . . . . . . . . . .  56
       7.3.18   Session-Lifetime AVP . . . . . . . . . .  56
       8.3.18   IP-Address AVP . . . . . .  56
       7.3.19   Termination-Cause AVP  . . . . . . . . . . . . . . .  56
   9.   PANA Protocol Message Retransmissions
   8.   Retransmission Timers  . . . . . . . . . . .  57
     9.1 . . . . . . . .  58
     8.1  Transmission and Retransmission Parameters . . . . . . . .  58
   10.  59
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  60
     10.1  61
     9.1  PANA UDP Port Number . . . . . . . . . . . . . . . . . .  60
     10.2 .  61
     9.2  PANA Multicast Address . . . . . . . . . . . . . . . . .  60
     10.3 .  61
     9.3  PANA Header  . . . . . . . . . . . . . . . . . . . . . .  60
       10.3.1 .  61
       9.3.1  Message Type . . . . . . . . . . . . . . . . . . . .  60
       10.3.2 .  61
       9.3.2  Flags  . . . . . . . . . . . . . . . . . . . . . . .  61
     10.4 .  62
     9.4  AVP Header . . . . . . . . . . . . . . . . . . . . . . .  61
       10.4.1 .  62
       9.4.1  AVP Code . . . . . . . . . . . . . . . . . . . . . .  61
       10.4.2 .  62
       9.4.2  Flags  . . . . . . . . . . . . . . . . . . . . . . .  62
     10.5 .  63
     9.5  AVP Values . . . . . . . . . . . . . . . . . . . . . . .  62
       10.5.1 .  63
       9.5.1  Algorithm Values of MAC AVP  . . . . . . . . . . . .  62
       10.5.2   Protection-Capability .  63
       9.5.2  Post-PANA-Address-Configuration AVP Values . . . . . . . . . .  62
       10.5.3   Termination-Cause  63
       9.5.3  Protection-Capability AVP Values . . . . . . . . . . . .  62
       10.5.4  63
       9.5.4  Result-Code AVP Values . . . . . . . . . . . . . . .  62
       10.5.5   Post-PANA-Address-Configuration .  63
       9.5.5  Termination-Cause AVP Values . . . . .  63
   11. . . . . . . . .  64
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  64
     11.1  65
     10.1   General Security Measures  . . . . . . . . . . . . . . .  64
     11.2  65
     10.2   Discovery  . . . . . . . . . . . . . . . . . . . . . . .  65
     11.3  66
     10.3   EAP Methods  . . . . . . . . . . . . . . . . . . . . . .  66
     11.4  67
     10.4   Separate NAP and ISP Authentication  . . . . . . . . . .  66
     11.5  67
     10.5   Cryptographic Keys . . . . . . . . . . . . . . . . . . .  66
     11.6  67
     10.6   Per-packet Ciphering . . . . . . . . . . . . . . . . . .  67
     11.7  68
     10.7   PAA-to-EP Communication  . . . . . . . . . . . . . . . .  67
     11.8   Livenes  68
     10.8   Liveness Test  . . . . . . . . . . . . . . . . . . . . . .  68
     11.9   Mobility Optimization  . . . . . . . . . . . . . . . . .  68
     11.10  69
     10.9   Updating PaC's IP Address  . . . . . . . . . . . . . . .  68
     11.11  69
     10.10  Early Termination of a Session . . . . . . . . . . . . .  69
   12.
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  70
   13.
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  71
   13.1
   12.1   Normative References . . . . . . . . . . . . . . . . . . .  71
   13.2
   12.2   Informative References . . . . . . . . . . . . . . . . . .  72
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  73
   A.   Example Sequence of Separate NAP and ISP Authentication  . .  75
        Intellectual Property and Copyright Statements . . . . . . .  75  77

1.  Introduction

   Network

   Providing secure network access service requires access control based
   on the authentication has traditionally been a layer 2
   function.  This document specifies a protocol that enables EAP to be
   transported above and authorization of the clients and the IP layer.  As a result, network access
   networks.  Client-to-network authentication can be made a function of provides parameters that
   are needed to police the network layer thereby
   achieving link-layer independence for traffic flow through the enforcement points.
   A protocol is needed to carry authentication methods between the process of authenticating a
   client seeking and the access to a network.  At the present time,

   Currently there are is no standardized solutions standard network-layer solution for
   authenticating a host clients for network
   access at access.  Appendix A of
   [I-D.ietf-pana-requirements] describes the network layer.  The problem statement for which that led
   to the
   PANA protocol is a solution can be found in Appendix A development of
   [I-D.ietf-pana-requirements]. PANA.

   Scope of this work is identified as designing a link-layer agnostic
   transport for network access authentication methods.  The Extensible
   Authentication Protocol (EAP) [RFC3748] provides such authentication
   methods.  In other words, PANA relies on will carry EAP for the actual which can carry various
   authentication methods.  By the virtue of a client.  It
   does not define enabling transport of EAP
   above IP, any new authentication protocols or schemes.  It
   enables EAP messages to method that can be carried between the client and the
   network.  The actual choice of a specific as an EAP
   method is made available to be run over PANA is dependent on the underlying access network and hence to any link-layer
   technology.  The
   key factor in the choice of the EAP method  There is the determination a clear division of
   whether the labor between PANA (an EAP
   lower layer (link/physical) provides security layer), EAP and EAP methods as described in [RFC3748].

   Various environments and usage models for the PANA messages. are identified in
   Appendix A secure network of [I-D.ietf-pana-requirements].  Potential security
   threats for network-layer access authentication framework goes beyond just
   authenticating protocol are
   discussed in [I-D.ietf-pana-threats-eval].  These have been essential
   in defining the client to requirements [I-D.ietf-pana-requirements] on the network.  Other aspects such as PANA
   protocol.  Note that some of these requirements are imposed by the
   chosen payload, EAP [RFC3748].

   There are components that are part of a complete secure network
   solution but are outside of the PANA protocol specification,
   including IP address configuration, authentication method choice,
   filter rule installation, data traffic security, access control filters protection and separation of the enforcement point from the protocol end-point PAA-EP
   protocol.  These components are documented described in separate documents (see
   [I-D.ietf-pana-framework] and [I-D.ietf-pana-snmp].

   This document specifies the client-network interaction and [I-D.ietf-pana-snmp]).  The readers are
   recommended to go through the
   messages defined for PANA Framework document
   [I-D.ietf-pana-framework] prior to reading this purpose. protocol
   specification document.

1.1  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

2.  Terminology

   PANA Client (PaC):

      The client side of the protocol that resides in the host device. access device
      (e.g., laptop, PDA, etc.).  It is responsible for providing the
      credentials in order to prove its identity (authentication) for
      network access authorization.

   PANA Authentication  The PaC and the EAP peer are
      co-located in the same access device.

   PANA Authentication Agent (PAA):

      The protocol entity in the access network whose responsibility is
      to verify the credentials provided by a PANA client (PaC) and
      authorize network access to the device associated with the client
      and identified by a Device Identifier (DI).  The PAA and the EAP
      authenticator (and optionally the EAP server) are co-located in
      the same node.  Note the authentication and authorization
      procedure can, according to the EAP model, be also offloaded to
      the backend AAA infrastructure.

   PANA Session:

      A PANA session begins with the handshake between the PANA Client
      (PaC) and the PANA Authentication Agent (PAA), and terminates as a
      result of an authentication or liveness test failure, a timeout, message
      delivery failure after retransmissions reach maximum values,
      session lifetime expiration, or an explicit termination message.
      A fixed session identifier is maintained throughout a session.  A
      session cannot be shared across multiple network interfaces.  Only
      one device identifier of the PaC is allowed to be bound to a PANA
      session for simplicity.

   Session Identifier:

      This identifier is used to uniquely identify a PANA session on the
      PAA and PaC.  It includes an identifier of the PAA, therefore it
      cannot be shared across multiple PAAs.  It is included in PANA
      messages to bind the message to a specific PANA session.  This
      bidirectional identifier is allocated by the PAA following the
      handshake and freed when the session terminates.

   PANA Security Association (PANA SA):

      A PANA security association is a relationship formed between the PaC and
      PAA, formed by the PAA
      by sharing of cryptographic keying material and associated context.  Security associations are duplex.  That is,
      one
      The formed duplex security association is needed used to protect the
      bidirectional PANA signaling traffic between the PaC and the PAA.

   Device Identifier (DI):

      The identifier used by the network as a handle to control and
      police the network access of a client. device.  Depending on the access
      technology, this identifier may contain an address that is carried
      in protocol headers (e.g., IP or link-layer address), or a locally
      significant identifier that is made available by the local
      protocol stack (e.g., circuit id, PPP interface id) of a connected
      device.

   Enforcement Point (EP):

      A node on the access network where per-packet enforcement policies
      (i.e., filters) are applied on the inbound and outbound traffic of
      client
      access devices.  Information such as the DI and (optionally)
      cryptographic keys are provided by the PAA per client for
      generating filters on the EP.  The EP and PAA may be co-located.

   Network Access Provider (NAP):

      A service provider that provides physical and link-layer
      connectivity to an access network it manages.

   AAA-Key:

      A key derived by the EAP peer and EAP server and transported to
      the authenticator [I-D.ietf-eap-keying].

   For additional terminology definitions see the PANA framework
   document [I-D.ietf-pana-framework].

3.  Protocol Overview

   The PANA protocol is run between a client (PaC) and a server (PAA) in
   order to perform authentication and authorization for the network
   access service.

   The protocol messaging consists of a series of request and responses,
   some of which may be initiated by either ends.  Each message can
   carry zero or more AVPs as payload.  The main payload of PANA is EAP
   which performs authentication.  PANA helps the PaC and PAA establish
   an EAP session.

   PANA is a UDP-based protocol.  It has its own retransmission
   mechanism to reliably deliver messages.

   PANA messages are sent between a the PaC and PAA as part of a PANA
   session.  A PANA session consists of distinct phases:

   o  Discovery and handshake phase: This is the phase that initiates a
      new PANA session.  The PaC discovers the PAA(s) by either
      explicitly soliciting advertisements for them or receiving
      unsolicited advertisements.  The PaC's answer sent in response to
      an advertisement starts a new session.

   o  Authentication and authorization phase: Immediately following the
      discovery and handshake phase is the EAP execution between the PAA
      and PaC.  The EAP payloads payload (which carry an EAP method inside) is
      what is used for authentication.  Authentication  The PAA conveys the result of
      authentication and authorization to the PaC at the end of this
      phase.  This phase may involve execution of two EAP sessions
      back-to-back, one for the NAP and one for the ISP.

   o  Authorization  Access phase: Following After a successful PANA authentication
      phase, and authorization
      the PaC host gains access to the network and can send and receive IP
      data traffic through EP.  During the EP(s).  At any time during this phase,
      the PaC and PAA may optionally ping each other to test liveness of
      the PANA session on each end.

   o  Re-authentication phase: Following an authorization the access phase, the PAA must
      initiate re-authentication before the PANA session lifetime
      expires.  Again EAP is carried by PANA to perform authentication.
      This phase may be optionally triggered by both the PaC and the PAA
      without any respect to the session lifetime.  The session moves to
      this phase from authorized the access phase, and returns back there upon
      successful re-authentication.

   o  Termination phase: The PaC or PAA may choose to discontinue the
      access service at any time.  An explicit disconnect message can be
      sent by either end.  If either the PaC or the PAA disconnects
      without engaging in termination messaging, it is expected that
      either the expiration of a finite session lifetime or failed
      liveness tests would do the job.

     PaC  PAA    Message[AVPs]    Message
   -----------------------------------------------------
   // Discovery and handshake phase
      ----->     PANA-PAA-Discover
      <-----     PANA-Start-Request
      ----->     PANA-Start-Answer

   // Authentication and authorization phase
      <-----     PANA-Auth-Request /* EAP Request */
      ----->     PANA-Auth-Answer
      ----->     PANA-Auth-Request /* EAP Response */
      <-----     PANA-Auth-Answer
      <-----     PANA-Bind-Request /* EAP Success */
      ----->     PANA-Bind-Answer

   // Authorization Access phase (IP data traffic allowed)
      <-----     PANA-Ping-Request
      ----->     PANA-Ping-Answer

   // Termination phase
      ----->     PANA-Termination-Request
      <-----     PANA-Termination-Answer

          Figure 1: Illustration of PANA Messages messages in a Session session

   Note that depending on the environment and deployment the protocol
   flow depicted in Figure 1 can be abbreviated.

   Cryptographic protection of messages between the PaC and PAA is
   possible as soon as EAP in conjunction with the EAP method exports a
   shared key.  That shared key is used to create a PANA SA.  The PANA
   SA helps generating per-message authentication codes that provide
   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
   incoming messages can generate a PANA error message sent in response.

4.  Protocol Details

   The following sections explain in detail the various phases of a PANA
   session.

4.1  Discovery and Handshake Phase

   When a PaC attaches to a network, and knows that it has to discover a
   PAA, it SHOULD send a PANA-PAA-Discover  Payload Encoding

   The payload of any PANA message consists of zero or more AVPs
   (Attribute Value Pairs).  The subsequent sections refer to these
   AVPs, therefore the list of AVPs are provided with a well-known link
   local multicast address (TBD) and UDP port (TBD).  The PANA PAA
   discovery assumes brief
   description before more extensive descriptions are included later in
   the document.

   o  Cookie AVP: contains a random value that is generated by the PaC PAA
      and the used for making PAA are one hop away from each
   other.  If the PaC knows discovery robust against blind resource
      consumption DoS attacks.

   o  Protection-Capability AVP: contains the IP address type of the PAA (based on
   pre-configuration), it MAY unicast the PANA-PAA-Discover message to
   that address.

   When the PAA receives a PANA-PAA-Discover message from per-packet
      protection (link-layer vs.  network-layer) when a PaC, the PAA
   SHOULD unicast cryptographic
      mechanism should be enabled after PANA authentication.

   o  Device-Id AVP: contains a PANA-Start-Request message to device identifier (link-layer address or
      an IP address) of the PaC.

   The PaC MAY also choose to start sending packets before getting
   authenticated.  In or an EP.

   o  EAP AVP: contains an EAP PDU.

   o  MAC AVP: contains a Message Authentication Code that case, integrity
      protects the network may detect this and PANA message.

   o  Termination-Cause AVP: contains the PAA
   MAY send an unsolicited PANA-Start-Request message to reason of session termination.

   o  Result-Code AVP: contains information about the PaC in
   addition to filtering protocol execution
      results.

   o  Session-Id AVP: contains the unauthorized traffic.  The EP is PANA session identifier value.

   o  Session-Lifetime AVP: contains the node duration of authorized access.

   o  Failed-AVP: contains an offending AVP that can detect such activity.  The PAA-to-EP protocol MAY be used
   for this purpose.

   When caused a PaC receives failure.

   o  Provider-Identifier AVP: contains the identifier of a PANA-Start-Request message from NAP or an
      ISP.

   o  Provider-Name AVP: contains a PAA, it
   responds with name of a PANA-Start-Answer message if it wishes to enter NAP or an
   authentication phase.  The answer message copies ISP.

   o  NAP-Information AVP, ISP-Information AVP: contains the sequence number.

   There identifier
      of a NAP and an ISP, respectively.

   o  Key-Id AVP: contains a AAA-Key identifier.

   o  PPAC AVP: Post-PANA-Address-Configuration AVP.  Used to indicate
      the available/chosen IP address configuration methods that can be multiple PAAs on
      used by the link PaC after successful PANA authentication.

   o  Nonce AVP: contains a randomly chosen value that is used in
      cryptographic key computations.

   o  IP-Address AVP: contains an IP Address of the PaC.

   o  Notification AVP: contains a displayable message.

4.2  Discovery and Handshake Phase

   When a PaC may receive multiple
   PANA-Start-Request messages from those PAAs.  The authentication attaches to a network, and
   authorization result does not depend on which knows that it has to discover a
   PAA, it SHOULD send a PANA-PAA-Discover message to a well-known link
   local multicast address (TBD) and UDP port (TBD).  The PAA is chosen by discovery
   assumes that the
   PaC.  By default PaC and the PAA are one IP hop away from each other.
   If the PaC MAY choose knows the IP address of the PAA that sent (based on
   pre-configuration), it MAY unicast the first
   response.

   A PANA-Start-Request PANA-PAA-Discover message MAY carry a Cookie AVP that contains a
   cookie.  The sequence number is set to a randomly picked initial
   sequence number.  The cookie is used for preventing
   that address.

   When the PAA receives a PANA-PAA-Discover message from
   resource consumption DoS attacks by blind attackers.  The cookie is
   computed in such a way that it does not require any per-session state
   maintenance on PaC, the PAA in order
   SHOULD unicast a PANA-Start-Request message to verify the cookie returned in a
   PANA-Start-Answer message. PaC.

   The exact algorithms and syntax used for
   generating cookies does not affect interoperability and hence is not
   specified here.  An example algorithm is described below.

      Cookie =
        <secret-version> | HMAC_SHA1( <Device-Id of PaC> , <secret> )
   where <secret> is a randomly generated secret known only PaC MAY also choose to the PAA,
   <secret-version> is start sending data packets before getting
   authenticated.  The EP in an index used for choosing the secret for
   generating access network that implements PANA
   SHOULD drop unauthorized packets upon receipt.  Additionally, the cookie EP
   MAY also take this traffic as an indication of unauthorized PaC and '|' indicates concatenation.
   notify the PAA.  The
   secret-version should EP-to-PAA notification SHOULD be changed frequently enough sent via
   [I-D.ietf-pana-snmp].  In response, the PAA SHOULD send an
   unsolicited PANA-Start-Request message to prevent replay
   attacks.  The secret key the PaC.  This is valid called
   "traffic-driven PAA discovery" (an alternative to the PaC explicitly
   soliciting for a certain time frame.

   When PAA).  Note that this optional feature MAY NOT be
   present in all deployments, therefore the PaC sends a PANA-Start-Answer message MUST NOT assume its
   availability.  The EP-to-PAA notification MAY also be generated in
   response to receiving a
   PANA-Start-Request containing a Cookie AVP, the answer MUST contain a
   Cookie AVP with the cookie value copied from link-up event notification on the request. EP
   [I-D.ietf-dna-link-information].

   When the PAA PaC receives the PANA-Start-Answer a PANA-Start-Request message from the PaC, a PAA, it
   verifies the cookie.  The cookie is considered as valid
   responds with a PANA-Start-Answer message if it wishes to enter the
   received cookie has the expected value.  If the computed cookie is
   valid, the protocol enters an
   authentication and authorization phase.  Otherwise, it
   MUST silently discard the received message.

   Initial EAP Request MAY

   There can be optionally carried by multiple PAAs on the
   PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
   message in order to reduce the number of round-trips.  This
   optimization SHOULD NOT be used if link and the PaC may receive
   multiple PANA-Start-Request messages from those PAAs.  The
   authentication and authorization result does not depend on which PAA discovery
   is desired to be
   stateless. chosen by the PaC.  By default the PaC MAY choose the PAA that
   sent the first response.

   A Protection-Capability AVP and PANA-Start-Request message MAY carry a Post-PANA-Address-Configuration
   (PPAC) Cookie AVP MAY be included in that contains a
   random value generated by the PANA-Start-Request in order PAA.  The random value is referred to
   indicate required and available capabilities
   as a cookie.  The cookie is used for preventing the network access.
   These AVPs MAY be used PAA from resource
   consumption DoS attacks by blind attackers which bombard the PaC for assessing PAA with
   PANA-PAA-Discover messages.  By relying on a cookie mechanism the capability match
   even before PAA
   can avoid per-PaC state creation until after the authentication takes place.  But these AVPs are
   provided during PaC can produce the insecure discovery and handshake phase, there are
   certain security risks involved
   same cookie in using its PANA-Start-Answer message.  In order to do that,
   the provided information.
   See Section 11 for further discussion cookie MUST be computed in such a way that it does not require
   any per-session state maintenance on this.

   If the initial EAP Request message is carried PAA in order to verify the
   PANA-Start-Request message, an EAP Response message MUST be carried
   cookie returned in the PANA-Start-Answer message returned to the PAA.

   In any case, PANA MUST NOT generate an EAP message on behalf of EAP
   peer or EAP (pass-through) authenticator. message.  The PANA-Start-Request/Answer exchange PAA discovery
   that takes advantage of cookies is needed before entering an
   authentication phase even when the PaC is 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
   PANA-Start-Answer messages. called "stateless PAA discovery".
   The nonces are exact algorithms and syntax used by the PAA to establish a PANA
   SA.

   A PANA-Start-Request message that carries a Cookie AVP is never
   retransmitted.  A PANA-Start-Request message that generate cookies
   does not carry a
   Cookie AVP is retransmitted based on timer.  A PANA-Start-Answer
   message that carries a Cookie AVP affect interoperability and hence is retransmitted based on timer.  A
   PANA-Start-Answer message that does not carry a Cookie AVP specified here.  An
   example algorithm is never
   retransmitted based on timer.

   It described below.

      Cookie =
        <secret-version> | HMAC_SHA1( <Device-Id of PaC> , <secret> )

   where <secret> is possible that both a randomly generated secret known only to the PAA and PAA,
   <secret-version> is an index used for choosing the PaC initiate secret for
   generating the discovery cookie and handshake procedure at '|' indicates concatenation.  The
   secret-version should be changed frequently enough to prevent replay
   attacks.  The secret key is valid for a certain time frame.  The
   device identifier of the same time, i.e., PaC can be extracted from a link-layer or IP
   header of PANA messages.

   When the PAA PaC sends a
   PANA-Start-Request PANA-Start-Answer message while in response to a
   PANA-Start-Request containing a Cookie AVP, the PaC sends answer MUST contain a PANA-PAA-Discover
   message.  To resolve
   Cookie AVP with the race condition, cookie value copied from the request.

   When the PAA SHOULD silently
   discard receives the PANA-PAA-Discover PANA-Start-Answer message received from the PaC after PaC, it
   has sent a PANA-Start-Request message with creating a state (i.e., no
   Cookie AVP is included in the message) for
   verifies the cookie.  The cookie is considered as valid if the
   received cookie has the expected value.  If the computed cookie is
   valid, the protocol enters the authentication and authorization
   phase.  Otherwise, it MUST silently discard the received message.

   The initial EAP Request message MAY be optionally carried by the PaC.  In this case PAA
   will retransmit
   PANA-Start-Request based on (as opposed to by a timer, if PaC doesn't
   respond later PANA-Auth-Request)
   message in time (message was lost for example).  If order to reduce the number of round-trips.  This
   optimization SHOULD NOT be used if the PAA had sent
   a PANA-Start-Request discovery is desired to be
   stateless since transmission of an EAP Request message without creating creates a
   state at EAP layer.  See [I-D.ietf-eap-statemachine] for more
   information on the PaC
   (i.e., EAP state machine and the allocation of state
   information in the respective protocol steps.

   A Protection-Capability AVP and a Cookie Post-PANA-Address-Configuration
   (PPAC) AVP was MAY be included in the message), then it SHOULD
   answer PANA-Start-Request in order to
   indicate required and available capabilities for the PANA-PAA-Discover message.

   Figure 2 shows an example sequence network access.
   These AVPs MAY be used by the PaC for assessing the capability match
   even before the authentication takes place.  Since these AVPs are
   provided during the insecure discovery and handshake
   phase when a PANA-PAA-Discover phase, there are
   certain security risks involved in using the provided information.
   See Section 10 for further discussion on this.

   If the initial EAP Request message is sent by carried in the PaC.  Figure 3
   shows
   PANA-Start-Request message, an example sequence for EAP Response message MUST be carried
   in the discovery PANA-Start-Answer message returned to the PAA.

   The PANA-Start-Request/Answer exchange is needed before entering the
   authentication and handshake authorization phase that
   is triggered by data traffic.

      PaC      PAA         Message(seqno)[AVPs]
      ------------------------------------------------------
         ----->            PANA-PAA-Discover(0)
         <-----            PANA-Start-Request(x)[Nonce, Cookie]
         ----->            PANA-Start-Answer(x)[Nonce, Cookie]
                           (continued to authentication phase)

   Figure 2: Example Sequence for Discovery and Handshake Phase even when
                    PANA-PAA-Discover is sent by PaC the PaC   EP is
   pre-configured with the IP address of the PAA    Message(seqno)[AVPs]
      ------------------------------------------------------
       ---->o              (Data packet arrival or L2 trigger)
             ------>       PAA-to-EP protocol, or another mechanism
       <------------       PANA-Start-Request(x)[Nonce, Cookie]
       ------------>       PANA-Start-Answer(x)[Nonce, Cookie]
                           (continued to authentication phase)

 Figure 3: Example Sequence for Discovery and Handshake when discovery the
   PANA-PAA-Discover message is triggered by data traffic

4.2  Authentication Phase

   The main task unicast.

   A Nonce AVP MUST be included in authentication phase is to carry EAP messages
   between the PaC PANA-Start-Request and
   PANA-Start-Answer messages.  The nonces are used to establish a fresh
   PANA_MAC_KEY (see Section 5.3) which is a transient session key in
   the PAA. EAP Request key hierarchy [I-D.ietf-eap-keying] and Response messages are
   carried is used only in PANA-Auth-Request the
   PANA protocol.  A Nonce AVP MUST be included in the
   PANA-Start-Request and PANA-Start-Answer messages.  PANA-Auth-Answer messages  The nonces are
   simply
   used to acknowledge receipt of the requests.  As an
   optimization, establish a PANA-Auth-Answer PANA SA.

   A PANA-Start-Request message MAY include the EAP
   Response.  Another optimization allows optionally carrying the first
   EAP Request/Response in PANA-Start-Request/Answer message stateless PAA discovery MUST NOT be
   retransmitted as
   described in Section 4.1

   When an EAP Success/Failure this voids the statelessness on the PAA.  Instead,
   the PaC MUST retransmit the PANA-PAA-Discover message is sent from until it
   receives a PAA, PANA-Start-Request message, and retransmit the
   PANA-Start-Answer message
   is carried in until it receives a PANA-Bind-Request (PBR) PANA-Auth-Request
   message.  The
   PANA-Bind-Request messages MUST be acknowledged with a
   PANA-Bind-Answer (PBA) message.  Figure 4 shows an example sequence
   in an authentication phase. PaC can determine whether the PAA  Message(seqno)[AVPs]
      --------------------------------------------------------------------
                    (continued from discovery and handshake phase)
         <-----     PANA-Auth-Request(x+1)
                       [Session-Id, EAP{Request}]
         ----->     PANA-Auth-Answer(x+1)      // No piggybacking EAP-Response
                       [Session-Id]
         ----->     PANA-Auth-Request(y)
                       [Session-Id, EAP{Response}]
         <-----     PANA-Auth-Answer(y)
                       [Session-Id]
         <-----     PANA-Auth-Request(x+2)
                       [Session-Id, EAP{Request}]
         ----->     PANA-Auth-Answer(x+2)      // Piggybacking EAP-Response
                       [Session-Id, EAP{Response}]
         <-----     PANA-Bind-Request(x+3)
                       [Session-Id, EAP{Success}, Device-Id, IP-Address,
                        Lifetime, Protection-Cap., PPAC, MAC]
         ----->     PANA-Bind-Answer(x+3)
                       [Session-Id, Device-Id, PPAC, MAC]

           Figure 4: Example Sequence in Authentication Phase

   When an EAP method that is capable of deriving keys is used during
   the authentication phase and the keys are successfully derived, using stateless
   PAA discovery by the
   PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or
   PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent
   PANA messages MUST contain a MAC presence of Cookie AVP.  The PANA-Bind-Request and PANA-Start-Request
   message MUST be retransmitted instead of the PANA-Bind-Answer PANA-Start-Answer
   message exchange when stateless PAA discovery is
   also used for binding device identifiers of not used.

   It is possible that both the PaC PAA and EP(s), the PaC initiate the discovery
   and handshake procedure at the IP address of same time, i.e., the PAA to sends a
   PANA-Start-Request message while the PANA SA. PaC sends a PANA-PAA-Discover
   message.  To achieve this, resolve the
   PANA-Bind-Request race condition, the PAA SHOULD contain silently
   discard the device identifier(s) of PANA-PAA-Discover message received from the
   EP(s) PaC after it
   has sent a PANA-Start-Request message with creating a state (i.e., no
   Cookie AVP is included in Device-Id AVP(s) when they are either MAC or IP address(es),
   and the IP address of message) for the PaC.  In this case the
   PAA in an IP-Address AVP.  PANA-Bind-Answer
   SHOULD contain PaC's device identifier in will retransmit the PANA-Start-Request message based on a Device-Id AVP when it is
   already presented with that of EP(s).  The PaC MUST use timer,
   if the same type
   of device identifier as contained PaC doesn't respond in time (the message was lost for
   example).  If the PANA-Bind-Request message.
   This exchange when protected by PAA had sent a MAC AVP prevents man-in-the-middle
   attacks.  The PANA-Bind-Request PANA-Start-Request message MAY also contain without
   creating a
   Protection-Capability state for the PaC (i.e., a Cookie AVP to indicate if link-layer or network-layer
   ciphering should be initiated after PANA.  No link layer or network
   layer specific information is was included in the Protection-Capability
   AVP.  When
   message), then it SHOULD answer to the information is preconfigured on PANA-PAA-Discover message.

   Figure 2 shows an example sequence for the PaC discovery and the PAA
   this AVP can be omitted.  It is assumed that at least PAA handshake
   phase when a PANA-PAA-Discover message is aware of
   the security capabilities of sent by the access network.  The PANA protocol
   does not specify how PaC.  Figure 3
   shows an example sequence for the PANA SA discovery and the Protection-Capability AVP
   will be used to provide per-packet protection for data traffic.

   Additionally, PANA-Bind-Request MUST include a
   Post-PANA-Address-Configuration AVP, which helps handshake phase with
   traffic-driven PAA to inform discovery.

      PaC
   about whether a new IP address MUST be configured      PAA         Message(sequence number)[AVPs]
      ------------------------------------------------------
         ----->            PANA-PAA-Discover(0)
         <-----            PANA-Start-Request(x)[Nonce, Cookie]
         ----->            PANA-Start-Answer(x)[Nonce, Cookie]
                           (continued to the authentication and
                            authorization phase)

 Figure 2: Example sequence for the available
   methods to do so.  PaC MUST include a PPAC AVP in order to indicate
   its choice of method discovery and handshake phase when there
                  PANA-PAA-Discover is a match between the methods
   offered sent by the PaC

      PaC   EP      PAA and    Message(sequence number)[AVPs]
      ------------------------------------------------------
       ---->o              (Data packet arrival or L2 trigger)
             ------>       PAA-to-EP protocol, or another mechanism
       <------------       PANA-Start-Request(x)[Nonce, Cookie]
       ------------>       PANA-Start-Answer(x)[Nonce, Cookie]
                           (continued to the methods available on authentication and
                            authorization phase)

 Figure 3: Example sequence for the PaC.  When there
   is no match, a PPAC AVP MUST NOT be included discovery and handshake phase with
                      traffic-driven PAA discovery

4.3  Authentication and Authorization Phase

   The main task of the Result-Code AVP
   MUST be set authentication and authorization phase is to PANA_PPAC_CAPABILITY_UNSUPPORTED in
   carry EAP messages between the
   PANA-Bind-Answer message.

   PANA-Bind-Request PaC and PANA-Bind-Answer messages MUST be retransmitted
   based on the retransmission rule described in Section 5.3. PAA.  EAP authentication can fail at a pass-through authenticator without
   sending an EAP-Failure message [I-D.ietf-eap-statemachine].  When
   this occurs, Request and
   Response messages are carried in PANA-Auth-Request messages.
   PANA-Auth-Answer messages are simply used to acknowledge receipt of
   the PAA SHOULD send requests.  As an optimization, a PANA-Error-Request PANA-Auth-Answer message to MAY
   include the
   PaC with using PANA_UNABLE_TO_COMPLY result code.  The PaC SHOULD EAP Response message.  This optimization MAY not
   change its state unless the error message is secured by PANA or lower
   layer.  In any case, a more appropriate way is be used
   when it takes time to rely on a timeout
   on generate the PaC.

   There is a case where EAP authentication succeeds with producing an
   EAP-Success Response message but network access authorization fails due (due to,
   e.g., authorization rejected by a AAA proxy or authorization locally
   rejected by the PAA.  When this occurs, the PAA MUST send
   PANA-Bind-Request with a result code PANA_AUTHORIZATION_REJECTED.  If
   a AAA-Key is established between PaC and PAA by the time when the
   EAP-Success is generated by the intervention of human input), in which case returning an
   EAP-Auth-Answer message without piggybacking an EAP server (this is Response message
   can avoid unnecessary retransmission of the case when PANA-Auth-Request
   message.  Another optimization allows optionally carrying the first
   EAP method provides protected success indication), this PANA-Bind Request/Response message exchange MUST be protected in PANA-Start-Request/Answer message as
   described in Section 4.2.

   PANA allows execution of two separate authentication methods, one
   with a MAC AVP NAP and one with carrying a
   Key-Id AVP.  The AAA-Key and ISP under the same PANA session MUST session.  This optional
   feature may be deleted after
   the PANA-Bind message exchange.

4.3  Authorization Phase

   Once an authentication phase or a re-authentication phase
   successfully completes, the PaC gains access to offered by the network and can
   send and receive IP data traffic through EP PAA and accepted by the PANA session
   enters an authorization phase.  In this phase, PANA-Ping-Request and
   PANA-Ping-Answer messages are used for testing PaC.  When
   performed separately, the liveness result of the
   PANA session on first EAP authentication is
   signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer
   message exchange which delineates the PANA peer.  Both first method execution from the PaC
   next.  See Section 4.7 for a detailed discussion on separate NAP and the PAA are allowed
   to send
   ISP authentication.

   The result of PANA authentication is carried in a PANA-Ping-Request PANA-Bind-Request
   message to sent from the communicating peer
   whenever they need PAA to make sure the availability of PaC.  This message carries the session on final
   EAP authentication result (whether it is the peer second EAP
   authentication result of NAP and expect ISP separate authentication, or the peer to return a PANA-Ping-Answer message.
   Both PANA-Ping-Request
   sole EAP authentication result) and PANA-Ping-Answer messages the result of PANA
   authentication.  The PANA-Bind-Request message MUST be
   protected acknowledged
   with a MAC AVP when a PANA SA is available.

   Implementations MUST limit PANA-Bind-Answer (PBA) message.  Figure 4 shows an example
   sequence in the rate of performing this test.  The PaC authentication and the authorization phase (no separate
   authentication).

      PaC      PAA can handle rate limitation on their own, they do not have
   to perform any coordination with each other.  There is no negotiation
   of timers for this purpose.

   Figure 5 and Figure 6 show liveness tests as they are initiated by  Message(sequence number)[AVPs]
      --------------------------------------------------------------------
                    (continued from the PaC discovery and the PAA respectively.

      PaC      PAA     Message(seqno)[AVPs]
      ------------------------------------------------------ handshake phase)
         <-----     PANA-Auth-Request(x+1)
                       [Session-Id, EAP{Request}]
         ----->        PANA-Ping-Request(q)[Session-Id, MAC]     PANA-Auth-Answer(x+1)      // No piggybacking EAP Response
                       [Session-Id]
         ----->     PANA-Auth-Request(y)
                       [Session-Id, EAP{Response}]
         <-----        PANA-Ping-Answer(q)[Session-Id, MAC]

       Figure 5: Example Sequence for PaC-initiated liveness test

      PaC      PAA     Message(seqno)[AVPs]
      ------------------------------------------------------     PANA-Auth-Answer(y)
                       [Session-Id]
         <-----        PANA-Ping-Request(p)[Session-Id,     PANA-Auth-Request(x+2)
                       [Session-Id, EAP{Request}]
         ----->     PANA-Auth-Answer(x+2)      // Piggybacking EAP Response
                       [Session-Id, EAP{Response}]
         <-----     PANA-Bind-Request(x+3)
                       [Session-Id, Result-Code, EAP{Success}, Device-Id,
                        Key-Id, IP-Address, Lifetime, Protection-Cap., PPAC, MAC]
         ----->        PANA-Ping-Answer(p)[Session-Id,     PANA-Bind-Answer(x+3)
                       [Session-Id, Device-Id, Key-Id, PPAC, MAC]

  Figure 6: 4: Example Sequence sequence for PAA-initiated liveness test

4.4  Re-authentication Phase

   A PANA session in an the authentication and authorization
                                 phase can enter a
   re-authentication phase to extend the current session lifetime by
   re-executing EAP.  Once

   When an EAP method that is capable of deriving keys is used during
   the re-authentication authentication and authorization phase successfully
   completes, and the session re-enters keys are
   successfully derived, the authorization phase.  Otherwise, PANA message that carries the session is deleted.

   When EAP Success
   message (i.e., a PaC wants to initiate re-authentication, it sends PANA-FirstAuth-End-Request or a
   PANA-Reauth-Request message to the PAA.  This PANA-Bind-Request
   message) and any subsequent message MUST contain a
   Session-Id AVP which MAC AVP.

   The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
   also used for identifying binding device identifiers of the PANA session on PaC and EP(s), and
   the
   PAA.  If IP address of the PAA already has an established PANA session for to the PaC
   with PANA SA.  To achieve this, the matching identifier, it
   PANA-Bind-Request message MUST first respond with a
   PANA-Reauth-Answer, followed by contain the device identifier in a PANA-Auth-Request that starts
   Device-Id AVP for each EP if a new
   EAP authentication.  If PAA cannot identify Protection-Capability AVP is included
   in the session, it MUST
   respond with a PANA-Error-Request with message.  Otherwise, the error code
   PANA_UNKNOWN_SESSION_ID.  PANA-Reauth-Request/Answer messages MUST message SHOULD contain the device
   identifier in a MAC Device-Id AVP for each EP when PANA SA is available.

   PaC may receive a PANA-Auth-Request before receiving the answer to
   its outstanding PANA-Reauth-Request.  This condition can arise due to
   packet re-ordering link-layer or a race condition between IP
   address is used as the device identifier of the PaC.  The
   PANA-Bind-Request message MUST also contain the IP address of the PaC and PAA when
   they both attempt to engage
   in re-authentication.  PaC an IP-Address AVP.  The PANA-Bind-Answer message MUST keep
   discarding contain the received PANA-Auth-Requests until
   PaC's device identifier in a Device-Id AVP when it receives is already
   presented with that of EP(s) in the request with using the same type
   of device identifier as contained in the
   answer to its request.

   When  If the
   PANA-Bind-Answer message sent from the PaC does not contain a
   Device-Id AVP with the same device identifier type contained in the
   request, the PAA initiates re-authentication, it sends a
   PANA-Auth-Request PANA-Error-Request message containing the session identifier with a
   PANA_MISSING_AVP result code, and wait for the
   PaC a PANA-Error-Answer
   message to enter an authentication phase.  PAA SHOULD initiate EAP
   authentication before terminate the current session lifetime expires.

   Re-authentication of an on-going PANA session session.  The PANA-Bind-Request message with
   a PANA_SUCCESS result code MUST maintain the
   existing sequence numbers.

   For any re-authentication, also contain a Protection-Capability
   AVP if there link-layer or network-layer ciphering is an established PANA SA,
   PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by
   adding enabled after the
   authentication and authorization phase.  The PANA-Bind-Request
   message MAY also contain a MAC Protection-Capability AVP to each message.  Any subsequent EAP-based
   authentication MUST indicate if
   link-layer or network-layer ciphering should be performed with enabled after the same ISP
   authentication and NAP that was
   selected during the initial authentication.  An example sequence for
   a re-authentication initiated by a PaC authorization phase.  No link-layer or
   network-layer specific information is shown included in Figure 7.

      PaC      PAA  Message(seqno)[AVPs]
      ------------------------------------------------------
         ----->     PANA-Reauth-Request(q)
                       [Session-Id, MAC]
         <-----     PANA-Reauth-Answer(q)
                       [Session-Id, MAC]
         <-----     PANA-Auth-Request(p)
                       [Session-Id, EAP{Request}, MAC]
         ----->     PANA-Auth-Answer(p)        // No piggybacking EAP-Response
                       [Session-Id, MAC]
         ----->     PANA-Auth-Request(q+1)
                       [Session-Id, EAP{Response}, MAC]
         <-----     PANA-Auth-Answer(q+1)      // No piggybacking EAP-Response
                       [Session-Id, MAC]
         <-----     PANA-Auth-Request(p+1)
                       [Session-Id, EAP{Request}, MAC]
         ----->     PANA-Auth-Answer(p+1)      // Piggybacking EAP-Response
                       [Session-Id, EAP{Response}, MAC]
         <-----     PANA-Bind-Request(p+2)
                       [Session-Id, EAP{Success}, Device-Id,
                        IP-Address, Key-Id, Lifetime,
                        Protection-Cap., PPAC, MAC]
         ----->     PANA-Bind-Answer(p+2)
                       [Session-Id, Device-Id, Key-Id, PPAC, MAC]

   Figure 7: Example Sequence for re-authentication initiated by PaC

4.5  Termination Phase

   A procedure for explicitly terminating a PANA session can be
   initiated either from the PaC (i.e., disconnect indication) or from
   Protection-Capability AVP.  It is assumed that the PAA (i.e., session revocation).  The PANA-Termination-Request and is aware of
   the PANA-Termination-Answer message exchanges are used for disconnect
   indication and session revocation procedures. security capabilities of the access network.  The reason for termination is indicated in PANA protocol
   does not specify how the Termination-Cause AVP.
   When there is an established PANA SA established between the PaC and the PAA, all messages exchanged during the termination phase MUST Protection-Capability AVP
   will be
   protected used to provide per-packet protection for data traffic.

   Additionally, the PANA-Bind-Request message with a MAC AVP.  When the sender of the
   PANA-Termination-Request receives PANA_SUCCESS
   result code MUST include a valid acknowledgment, all states
   maintained for Post-PANA-Address-Configuration (PPAC)
   AVP, which helps the PANA session PAA to inform the PaC about whether a new IP
   address MUST be deleted immediately.

      PaC      PAA     Message(seqno)[AVPs]
      ------------------------------------------------------
         ----->        PANA-Termination-Request(q)[Session-Id, MAC]
         <-----        PANA-Termination-Answer(q)[Session-Id, MAC]

           Figure 8: Example Sequence for Session Termination

5.  Protocol Design Details configured and Processing Rules

5.1  Payload Encoding

   The payload of any PANA message consists of zero or more AVPs
   (Attribute Value Pairs).  A brief description of the AVPs defined in available methods to do so.  In
   this document is listed below:

   o  Cookie AVP: contains a random value that is used for making
      handshake robust against blind resource consumption DoS attacks.

   o  Protection-Capability AVP: contains information which protection
      should be initiated after case, the PANA exchange (e.g., link-layer or
      network layer protection).

   o  Device-Id AVP: contains PaC MUST include a device identifier of PPAC AVP in the PaC or an EP.
      A device identifier PANA-Bind-Answer
   message in order to indicate its choice of method when there is represented as a pair of device identifier
      type
   match between the methods offered by the PAA and device identifier value.  Either a layer-2 address or an
      IP address is used for the device identifier value when this AVP methods
   available on the PaC.  When there is present.

   o  EAP AVP: contains an EAP PDU.

   o  MAC AVP: contains no match, the PaC MUST send a Message Authentication Code that protects
   PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED
   result code and terminate the PANA message PDU.

   o  Termination-Cause AVP: contains session.

   PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted
   based on the reason of session termination.

   o  Result-Code AVP: contains information about the protocol execution
      results.

   o  Session-Id AVP: contains retransmission rule described in Section 5.2.

   EAP authentication can fail at a pass-through authenticator without
   sending an EAP Failure message [I-D.ietf-eap-statemachine].  When
   this occurs, the session identifier value.

   o  Session-Lifetime AVP: contains PAA SHOULD send a PANA-Error-Request message to the duration of authorized access.

   o  Failed-AVP: contains
   PaC with using PANA_UNABLE_TO_COMPLY result code.  The PaC SHOULD not
   change its state unless the offending AVP that caused error message is secured by PANA or
   lower-layer.  In any case, a failure.

   o  NAP-Information AVP, ISP-Information AVP: contains the information more appropriate way is to rely on a NAP and
   timeout on the PaC.

   There is a case where EAP authentication succeeds with producing an ISP, respectively.

   o  Key-Id AVP: contains
   EAP Success message but network access authorization fails due to,
   e.g., authorization rejected by a AAA-Key identifier.

   o  PPAC AVP: Post-PANA-Address-Configuration AVP.  Conveys the list
      of IP address configuration methods available when sent AAA or authorization locally
   rejected by the
      PAA, and the chosen method when sent by PAA.  When this occurs, the PaC.

   o  Nonce AVP: contains PAA MUST send a randomly chosen value.

   o  IP-Address AVP: contains an IP Address of
   PANA-Bind-Request with a PaC.

5.2  Transport Layer

   PANA uses UDP as its transport layer protocol.  The UDP port number result code PANA_AUTHORIZATION_REJECTED.  If
   a AAA-Key is TBD.  All messages except for PANA-PAA-Discover are always
   unicast.  PANA-PAA-Discover MAY be unicast when established between the PaC knows the IP
   address of and the PAA.

5.2.1  Fragmentation

   PANA does not provide fragmentation of PANA messages.  Instead, it
   relies on fragmentation provided PAA by EAP methods and IP layer the time when
   needed.

5.3  Sequence Number
   the EAP Success message is generated by the EAP server (this is the
   case when the EAP method provides protected success indication), the
   PANA-Bind-Request and Retransmission

   PANA uses sequence numbers to provide ordered PANA-Bind-Answer messages MUST be protected
   with a MAC AVP and reliable delivery
   of messages.

   PaC carry a Key-Id AVP.  The AAA-Key and PAA maintain two sequence numbers: the next one to PANA
   session MUST be used
   for a request it initiates deleted immediately after the PANA-Bind message
   exchange.

4.4  Access Phase

   Once the authentication and authorization phase or the next one it expects
   re-authentication phase successfully completes, the PaC gains access
   to see in a
   request from the other end.  These sequence numbers are 32-bit
   unsigned numbers.  They are monotonically incremented by 1 as new
   requests are generated network and received, can send and wrapped to zero on receive IP data traffic through the next
   message after 2^32-1.  Answers always contain
   EP(s) and the same sequence
   number as PANA session enters the corresponding request.  Retransmissions maintain access phase.  In this phase,
   PANA-Ping-Request and PANA-Ping-Answer messages can be used for
   testing the liveness of the PANA session on the PANA peer.  Both the
   same sequence number.

   The initial sequence numbers (ISN) are randomly picked by
   PaC and the PAA
   as they are allowed to send their very first request messages.  PANA-PAA-Discover
   message carries sequence number 0.

   When a request PANA-Ping-Request message is received, it is considered valid in terms
   of sequence numbers if and only if its sequence number matches to
   the
   expected value.  This check does not apply communicating peer whenever they need to PANA-PAA-Discover, and make sure the very first request messages.

   When an answer message is received, it is considered valid in terms
   availability of sequence numbers if the session on the peer and only if its sequence number matches that
   of expect the currently outstanding request.  A peer can only have one
   outstanding request at to return
   a time.

   PANA PANA-Ping-Answer message.  Both PANA-Ping-Request and
   PANA-Ping-Answer messages are retransmitted based on timer at until MUST be protected with a response is
   received (in which case the retransmission timer MAC AVP when a
   PANA SA is stopped) or available.

   Implementations MUST limit the
   number rate of retransmission reaches the maximum value (in which case the
   PANA session MUST be deleted immediately). performing this test.  The retransmission timer
   SHOULD be calculated as described in [RFC2988] to provide congestion
   control.  See Section 9 for default timer and maximum retransmission
   count parameters. PaC
   and the PAA MUST respond can handle rate limitation on their own, they do not have
   to duplicate requests.  Last transmitted
   PANA answer MAY be cached in case it perform any coordination with each other.  There is not received no negotiation
   of timers for this purpose.

   Figure 5 and Figure 6 show liveness tests as they are initiated by
   the peer PaC and
   that generates a retransmission of the last request.  When available,
   a cached answer PAA respectively.

      PaC      PAA     Message(sequence number)[AVPs]
      ------------------------------------------------------
         ----->        PANA-Ping-Request(q)[Session-Id, MAC]
         <-----        PANA-Ping-Answer(q)[Session-Id, MAC]

       Figure 5: Example sequence for PaC-initiated liveness test

      PaC      PAA     Message(sequence number)[AVPs]
      ------------------------------------------------------
         <-----        PANA-Ping-Request(p)[Session-Id, MAC]
         ----->        PANA-Ping-Answer(p)[Session-Id, MAC]

       Figure 6: Example sequence for PAA-initiated liveness test

4.5  Re-authentication Phase

   The PANA session in the access phase can be used instead of fully processing enter the
   retransmitted request and forming a new answer from scratch.

   PANA MUST NOT generate EAP message duplication.  EAP payload of re-authentication
   phase to extend the current session lifetime by re-executing EAP.
   Once the re-authentication phase successfully completes, the session
   re-enters the access phase.  Otherwise, the session is deleted.

   When the PaC wants to initiate re-authentication, it sends a
   retransmitted PANA
   PANA-Reauth-Request message MUST NOT be passed to the EAP layer.

5.4  Message Authentication Code

   A PANA PAA.  This message can MUST contain a MAC (Message Authentication Code)
   Session-Id AVP which is used for cryptographically protecting identifying the message.

   When a MAC AVP is included in a PANA message, the value field of the
   MAC AVP is calculated by using the PANA_MAC_KEY in session on the following way:

      MAC AVP value = PANA_MAC_PRF(PANA_MAC_KEY, PANA_PDU)

   where PANA_PDU is
   PAA.  If the PAA already has an established PANA message including session for the PANA header, PaC
   with the MAC AVP value field matching session identifier, it MUST first initialized to 0.  PANA_MAC_PRF
   represents respond with a
   PANA-Reauth-Answer message, followed by a PANA-Auth-Request that
   starts a new EAP authentication.  If the pseudo random function corresponding to PAA cannot identify the MAC
   algorithm specified
   session, it MAY respond with a PANA-Error-Request message with a
   result code PANA_UNKNOWN_SESSION_ID.  Transmission of this error
   request is made optional in the MAC AVP.  In case this version of draft,
   PANA_MAC_PRF behavior is HMAC-SHA1. leveraged for a DoS
   attack on the PAA.

   The PaC and PAA MUST use may receive a PANA-Auth-Request before receiving the same
   algorithm answer
   to calculate its outstanding PANA-Reauth-Request.  This condition can arise due
   to packet re-ordering or a MAC AVP they originate and receive.  The
   algorithm is determined by race condition between the PaC and PAA
   when a PANA-Bind-Request with a
   MAC AVP is sent.  When the PaC does not support the MAC algorithm
   specified they both attempt to engage in the PANA-Bind-Request message, it MUST silently discard
   the message. re-authentication.  The PAA PaC MUST NOT change the MAC algorithm throughout
   keep discarding the continuation of received PANA-Auth-Requests until it receives the PANA session.

5.5  Message Validity Check
   answer to its request.

   When the PAA initiates re-authentication, it sends a PANA
   PANA-Auth-Request message is received, containing the message is considered session identifier for the
   PaC to be
   invalid at least when one of enter the following conditions are not met:

   o re-authentication phase.  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.

   o  Each field in PAA SHOULD initiate
   EAP re-authentication before the message header contains a valid value including
      sequence number, message length, message type, version number,
      flags, etc.

   o  When a device identifier current session lifetime expires.

   Re-authentication of an on-going PANA session MUST maintain the PaC
   existing sequence numbers.

   For any re-authentication, if there is bound to the an established PANA session,
      it matches the device identifier carried in MAC or or IP header,
      or other locally-significant identifier provided SA,
   PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by the
      lower-layers (e.g., circuit ID) unless the message is
   adding a
      PANA-Update-Request MAC AVP to each message.  Any subsequent EAP authentication
   MUST be performed with an IP-Address AVP.

   o  The message type is one of the expected types in the current
      state.  Specifically the following messages are unexpected same ISP and
      invalid:

      *  In NAP that was selected during
   the discovery and handshake phase:

         +  PANA-Termination-Request and PANA-Ping-Request.

         +  PANA-Bind-Request.

         +  PANA-Update-Request.

      *  In authentication phase:

         +  PANA-PAA-Discover.

         +  PANA-Update-Request.

         +  PANA-Start-Request after a phase.  An example sequence for
   re-authentication phase initiated by the PaC receives is shown in Figure 7.

      PaC      PAA  Message(sequence number)[AVPs]
      ------------------------------------------------------
         ----->     PANA-Reauth-Request(q)
                       [Session-Id, MAC]
         <-----     PANA-Reauth-Answer(q)
                       [Session-Id, MAC]
         <-----     PANA-Auth-Request(p)
                       [Session-Id, EAP{Request}, MAC]
         ----->     PANA-Auth-Answer(p)        // No piggybacking EAP Response
                       [Session-Id, MAC]
         ----->     PANA-Auth-Request(q+1)
                       [Session-Id, EAP{Response}, MAC]
         <-----     PANA-Auth-Answer(q+1)      // No piggybacking EAP Response
                       [Session-Id, MAC]
         <-----     PANA-Auth-Request(p+1)
                       [Session-Id, EAP{Request}, MAC]
         ----->     PANA-Auth-Answer(p+1)      // Piggybacking EAP Response
                       [Session-Id, EAP{Response}, MAC]
         <-----     PANA-Bind-Request(p+2)
                       [Session-Id, Result-Code, EAP{Success}, Device-Id, Key-Id,
                        IP-Address, Lifetime, Protection-Cap., PPAC, MAC]
         ----->     PANA-Bind-Answer(p+2)
                       [Session-Id, Device-Id, Key-Id, PPAC, MAC]

  Figure 7: Example sequence for the first valid
            PANA-Auth-Request.

         +  PANA-Termination-Request before re-authentication phase initiated
                                 by PaC

4.6  Termination Phase

   A procedure for explicitly terminating a PANA session can be
   initiated either from the PaC receives (i.e., disconnect indication) or from
   the first
            successful PANA-Bind-Request.

      *  After successful PANA authentication:

         +  PANA-Start-Request as well as a non-duplicate
            PANA-Bind-Request.

         +  PANA-PAA-Discover.

      *  In termination phase:

         +  PANA-PAA-Discover.

         +  All requests but PANA-Termination-Request.

   o PAA (i.e., session revocation).  The PANA-Termination-Request and
   PANA-Termination-Answer message payload contains a valid set of AVPs allowed exchanges are used for the
      message type disconnect
   indication and there session revocation procedures.

   The reason for termination is no missing AVP that needs to be included indicated in the payload.

   o  Each AVP is decoded correctly.

   o Termination-Cause AVP.
   When a MAC AVP there is included, an established PANA SA between the AVP value matches PaC and the MAC value
      computed against PAA, all
   messages exchanged during the received message.

   o  When termination phase MUST be protected
   with a Device-Id AVP is included, MAC AVP.  When the AVP is valid if sender of the device
      identifier type contained in PANA-Termination-Request
   message receives a valid acknowledgment, all states maintained for
   the AVP is supported (check performed
      by both PANA session MUST be deleted immediately.

      PaC and PAA) and is      PAA     Message(sequence number)[AVPs]
      ------------------------------------------------------
         ----->        PANA-Termination-Request(q)[Session-Id, MAC]
         <-----        PANA-Termination-Answer(q)[Session-Id, MAC]

 Figure 8: Example sequence for the requested one (check performed termination phase triggered by
      PAA only) PaC

4.7  Separate NAP and the device identifier value contained ISP Authentication

   PANA allows running at most two EAP sessions in sequence in the AVP
      matches the value extracted from the lower-layer encapsulation
      header corresponding
   authentication and authorization phase to the device identifier type contained support separate NAP and
   ISP authentication as described in this section.  A typical network
   access authentication includes execution of one EAP method with the AVP (check performed by PAA only).  Note that a Device-Id AVP
      carries
   ISP.  This separation allows the PaC's device identifier in messages from PaC to PAA
      and EP(s)' device identifier in messages from PAA to PaC.

   o  When perform an IP-Address AVP is received in a message, the AVP is valid
      if the IP address matches additional
   authentication method for receiving differentiated services from the source address
   NAP.

   Currently, running multiple EAP sessions in the IP header.

   Invalid messages MUST be discarded sequence in order to provide robustness
   against DoS attacks.  In addition, an error notification message MAY
   be returned to the sender.  See Section 5.7
   authentication and authorization phase is designed only for details.

5.6  PANA Security Association

   A PANA SA separate
   NAP and ISP authentication.  It is created as an attribute not for running arbitrary number
   of a PANA session when EAP
   authentication succeeds with a creation of a AAA-Key.  A PANA SA is
   not created when sessions in sequence, or giving the PANA PaC another chance to try
   another EAP authentication fails or no AAA-Key is
   produced by any method within an integrated NAP and ISP
   authentication when an EAP authentication method.  In method fails.

   Within separate NAP and ISP authentication, the case where two EAP
   authentications are performed in sequence in a single PANA NAP authentication
   and the ISP authentication phase, it is possible that two AAA-Keys are derived.
   If this happens, considered completely independent.
   Presence or success of one should not effect the PANA SA MUST be generated from both AAA-Keys.
   When other.  Making a new AAA-Key
   network access authorization decision based on the success or failure
   of each authentication is derived as a result of EAP-based
   re-authentication, any key derived from network policy issue.

4.7.1  Negotiating Separate NAP and ISP Authentication

   When the old AAA-Key MUST be
   updated to a new one that is derived from PaC and PAA negotiates in the new AAA-Key.  In order discovery and handshake phase
   to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be
   carried in PANA-Bind-Request perform separate NAP and PANA-Bind-Answer messages or
   PANA-FirstAuth-End-Request ISP authentication, the PaC and PANA-FirstAuth-End-Answer messages at the end of PAA
   operate in the EAP authentication which resulted following way in deriving a new
   AAA-Key.  The Key-Id AVP is addition to the behavior defined in
   Section 4.2

   In the discovery and handshake phase, the PAA MAY advertise
   availability of type Unsigned32 separate NAP and MUST contain a
   value that uniquely identifies ISP authentication
   ([I-D.ietf-pana-framework]) by setting the AAA-Key within S-flag on the PANA session.
   The PANA-Bind-Answer message (or header
   of the PANA-FirstAuth-End-Answer
   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
   Key-Id AVP with PANA-Start-Request message.

   If the same AAA-Key identifier carried in S-flag of the request.
   PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and
   PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry
   a MAC AVP whose value received PANA-Start-Request message is computed set, the
   PaC can indicate its desire to perform separate NAP and ISP
   authentication by using setting the new PANA-MAC-KEY
   derived from S-flag in the new AAA-Key (or PANA-Start-Answer
   message.  If the new pair S-flag of AAA-Keys when the
   PANA_MAC_KEY received PANA-Start-Request message is derived from two AAA-Keys).  Although the
   specification does
   not mandate a particular method for calculation of
   Key-Id AVP value, a simple method is set, the PaC MUST NOT set the S-flag in the PANA-Start-Answer
   message sent back to use monotonically increasing
   numbers.

   The created PANA SA is deleted when the corresponding PANA session is
   deleted.  The lifetime of PAA.

   If the PANA SA S-flag in the PANA-Start-Answer message is not set, only one
   authentication is performed (ISP-only) and the same processing occurs as
   described in Section 4.2.

   When the lifetime of S-flag is set in a PANA-Start-Request message, the PANA session for simplicity.

   PANA SA attributes as well as PANA session attributes are listed
   below:

   PANA Session attributes:

      *  Session-Id

      *  Device-Id of PaC

      *  IP address of PaC (may initial
   EAP Request message MUST NOT be carried in the same as PANA-Start-Request
   message.  (If the Device-Id of PaC)

      *  IP address of PAA

      *  List of device identifiers of EPs

      *  Sequence number of initial EAP Request message were contained in the last transmitted request

      *  Sequence number of
   PANA-Start-Request message during the last received request

      *  Last transmitted S-flag negotiation, the PaC
   cannot tell whether the EAP Request message payload

      *  Retransmission interval

      *  Session lifetime

      *  Protection-Capability

      *  PANA SA attributes:

         +  Nonce generated by is for NAP authentication
   or ISP authentication.)

4.7.2  Execution of Separate NAP and ISP Authentication

   When the PaC (PaC_nonce)

         +  Nonce generated by and PAA (PAA_nonce)

         +  AAA-Key

         +  AAA-Key Identifier

         +  PANA_MAC_KEY

   The PANA_MAC_KEY is used have negotiated in the discovery and handshake
   phase to integrity protect PANA messages perform separate NAP and
   derived from AAA-Key(s).  When two AAA-Keys (AAA-Key1 ISP authentication, the PaC and AAA-Key2)
   are generated as a result of double EAP authentication (see Section
   4.2) the compound AAA-Key can be computed as follows ('|' indicates
   concatenation):

      AAA-Key = AAA-Key1 | AAA-Key2

    The PANA_MAC_KEY is computed
   PAA operate in the following way:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID)

   where the value of N depends on way in addition to the integrity protection algorithm behavior defined
   in
   use, i.e., N=160 for HMAC-SHA1. Section 4.3

   o  The length S-flag of AAA-Key PANA-Auth-Request and PANA-Auth-Answer messages MUST
      be N bits
   or longer.  See Section Section 5.4 for the detailed usage of the
   PANA_MAC_KEY.

5.7  Error Handling

   A PANA-Error-Request message MAY be sent by either the PaC or the PAA
   when a badly formed PANA set.

   o  An EAP Success/Failure message is received or carried in case of other
   errors.  The receiver of this request MUST respond with a
   PANA-Error-Answer message.  If the cause of this error
      PANA-FirstAuth-End-Request (PFER) message was as well as a
   request
      PANA-Bind-Request (PBR) message.  The PANA-FirstAuth-End-Request
      message (e.g., PANA-PAA-Discover or *-Request), then the
   request MAY MUST be retransmitted immediately without waiting used at the end of the first EAP authentication
      and the PANA-Bind-Request MUST be used for its
   retransmission timer to go off. the second EAP
      authentication.  The PANA-FirstAuth-End-Request messages MUST be
      acknowledged with a PANA-FirstAuth-End-Answer (PFEA) message.

   o  If the cause first EAP authentication has failed, the PAA can choose not
      to perform the second EAP authentication by clearing the S-flag of
      the error was a
   response message, PANA-FirstAuth-End-Request message.  In this case, the receiver S-flag
      of the PANA-Error-Request PANA-FirstAuth-End-Answer message
   SHOULD NOT resend the same response until it receives sent by the next
   request.

   To defend against DoS attacks a timer MAY PaC MUST be used.  One (1) error
   notification is sent to each different sender each N seconds.  N is a
   configurable parameter.

   When an error
      cleared.  If the S-flag of the PANA-FirstAuth-End-Request message
      is sent unprotected with a MAC AVP set when the first EAP authentication has failed, the PaC can
      choose not to perform the second EAP authentication by clearing
      the S-flag of the PANA-FirstAuth-End-Answer message.  If the first
      EAP authentication failed and the
   lower-layer S-flag is insecure, not set in the error
      PANA-FirstAuth-End-Answer message is treated as an
   informational message.  The receiver a result of such an error message MUST
   NOT change its state unless the error persists and those operations,
      the PANA session
   is not making any progress.

5.8  Device ID Choice MUST be immediately deleted.  Otherwise, the
      second EAP authentication MUST be performed.

   o  The device identifier used in PAA determines the context execution order of PANA NAP authentication and
      ISP authentication.  In this case, the PAA can be an IP
   address, a MAC address, indicate which
      authentication (NAP authentication or an identifier that is not carried in data
   packets but has local significance ISP authentication) is
      currently occurring by using N-flag in identifying a connected host
   (e.g., circuit id, PPP interface id). the PANA message header.
      When NAP authentication is being performed, the N-flag MUST be
      set.  When ISP authentication is being performed, the N-flag MUST
      NOT be set.  The last type of identifiers
   are commonly used in point-to-point links where MAC addresses are not
   available and lower-layers are already physically or
   cryptographically secured.

   It N-flag MUST NOT be set when S-flag is assumed that not set.

   When the PaC and PAA knows have negotiated in the link type discovery and handshake
   phase to perform separate NAP and ISP authentication, and the security
   mechanisms being provided or required on the access network (e.g.,
   based on physical security, link-layer ciphers enabled before or
   after PANA, or IPsec).  Based on that information,
   lower-layer is insecure, the PAA can decide
   what type of EP device id will be two EAP authentication methods used when running PANA with the
   client.  When IPsec-based security [I-D.ietf-pana-ipsec] is in
   the
   choice separate authentication MUST be capable of access control, deriving keys
   (AAA-Key).

4.7.3  AAA-Key Calculation

   When the PAA SHOULD provide IP address(es) as
   EP(s)' device ID, PaC and expect PAA have negotiated in the PaC discovery and handshake
   phase to provide its IP address perform separate NAP and ISP authentication, if the
   lower-layer is insecure, the two EAP authentication methods used in
   return.
   the separate authentication MUST be capable of deriving keys.  In case IPsec
   this case, if the first EAP authentication is not used, MAC addresses are used successful, the
   PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as device
   IDs when available.  If non-IPsec access control is enabled,
   well as PANA-Auth-Request and a
   MAC address is not available, device ID exchange does not occur
   within PANA.  Instead, peers rely on lower-layers to provide
   locally-significant identifiers along with received PANA packets.

5.9  Updating PaC' Address

   A PaC's IP address can change PANA-Auth-Answer messages in certain situations.  For example, the PANA framework [I-D.ietf-pana-framework] describes a case in
   which a PaC replaces a pre-PANA address (PRPA) second
   EAP authentication MUST be protected with a post-PANA
   address (POPA), and the PaC key derived from the
   AAA-Key for the first EAP authentication.  The PANA-Bind-Request and PAA create host routes to each other
   PANA-Bind-Answer messages and all subsequent PANA messages exchanged
   in order to maintain on-link communication based on the POPA.  The
   PAA needs to access phase, re-authentication phase and termination phase
   MUST be notified about protected either with the change of PaC address.

   After AAA-Key for the PaC has changed its address, it MUST send a
   PANA-Update-Request message to first EAP
   authentication if the PAA.  The message MUST carry first EAP authentication succeeds and the
   new PaC address in an IP-Address AVP.  If
   second EAP authentication fails, or with the address contained in AAA-Key for the request is invalid, second
   EAP authentication if the PAA MUST send a PANA-Error message with first EAP authentication fails and the result code PANA_INVALID_IP_ADDRESS.  Otherwise,
   second EAP authentication succeeds, or with the PAA MUST
   update compound AAA-Key
   derived from the PANA session with two AAA-Keys, one for the new PaC address first EAP authentication
   and return a
   PANA-Update-Answer message.  If there is an established PANA SA, the other from the second EAP authentication, if both
   PANA-Update-Request the first
   and PANA-Update-Answer messages MUST be protected
   with a MAC AVP.

5.10  Session Lifetime

   The second EAP authentication phase determines succeed.  See Section 5.3 for how to
   derive the AAA-Key.

5.  Protocol Design Details and Processing Rules

5.1  Transport Layer

   PANA session lifetime when
   the network access authorization succeeds. uses UDP as its transport layer protocol.  The Session-Lifetime AVP UDP port number
   is TBD.  All messages except for PANA-PAA-Discover are always
   unicast.  The PANA-PAA-Discover message MAY be optionally included in unicast when the PANA-Bind-Request message to inform PaC about
   knows the valid lifetime IP address of the PAA.

5.1.1  Fragmentation

   PANA session.  It MUST be ignored
   when included in other does not provide fragmentation of PANA messages.  When there are multiple EAP
   authentication taking place, this AVP SHOULD be included after the
   final authentication.

   The lifetime is a non-negotiable parameter that can be used  Instead, it
   relies on fragmentation provided by PaC to
   manage PANA-related state.  PaC does not have to perform any actions
   when the lifetime expires, other than optionally purging local state.

   PAA SHOULD initiate EAP authentication before the current session
   lifetime expires.

   PaC methods and PAA MAY optionally rely on lower-layer indications to
   expedite the detection of a disconnected peer.  Availability IP layer when
   needed.

5.2  Sequence Number and
   reliability of such indications depend on the specific access
   technologies. Retransmission

   PANA peer can use PANA-Ping-Request message to verify
   the disconnection before taking an action.

   The session lifetime parameter is not related uses sequence numbers to the transmission provide ordered and reliable delivery
   of
   PANA-Ping-Request messages.  These messages can

   The PaC and PAA maintain two sequence numbers: the next one to be
   used for
   asynchronously verifying the liveness of a request it initiates and the peer.  The decision next one it expects to
   send PANA-Ping-Request message is taken locally and does not require
   coordination between the peers.

5.11  Network Selection

   In a discovery and handshake phase, see in
   a PANA-Start-Request message sent request from the PAA MAY contain zero or one NAP-Information AVP other end.  These sequence numbers are 32-bit
   unsigned numbers.  They are monotonically incremented by 1 as new
   requests are generated and zero or
   more ISP-Information AVPs received, and wrapped to advertise the information on the NAP
   and/or ISPs.  The PaC MAY indicate its choice of ISP by including an
   ISP-Information AVP in the PANA-Start-Answer message.  When a AAA
   backend is used, the identity of the destination AAA server or realm
   MUST be determined based zero on the explicitly chosen ISP.  When next
   message after 2^32-1.  Answers always contain the
   ISP-Information AVP is not present, same sequence
   number as the access network MAY rely on corresponding request.  Retransmissions reuse the client identifier carried
   sequence number contained in the EAP authentication method to
   make this determination. original packet.

   The initial sequence numbers (ISN) are randomly picked by the PaC can choose an ISP and contain an
   ISP-Information AVP for the chosen ISP in
   PAA as they send their very first request messages.
   PANA-PAA-Discover message carries sequence number 0.

   When a PANA-Start-Answer request message
   even when there is no ISP-Information AVP contained received, it is considered valid in terms
   of sequence numbers if and only if its sequence number matches the
   expected value.  This check does not apply to the PANA-PAA-Discover,
   PANA-Start-Request message.

5.12  Separate NAP and ISP Authentication

   PANA allows running at most two EAP sessions messages.

   When an answer message is received, it is considered valid in terms
   of sequence in an
   authentication phase to support separate NAP numbers if and ISP authentication
   as described in next sections.  Currently, running multiple EAP
   sessions in sequence in an authentication phase is designed only for
   separate NAP and ISP authentication.  It is not for running arbitrary if its sequence number matches that
   of EAP sessions in sequence, or giving the PaC another chance
   to try another EAP authentication method within an integrated NAP and
   ISP authentication when an EAP authentication method fails.  Within
   separate NAP and ISP authentication, the NAP authentication and the
   ISP authentication are considered completely independent.  Presence
   or success of currently outstanding request.  A peer can only have one should not effect the other.  Making
   outstanding request at a network
   access authorization decision time.

   PANA messages are retransmitted based on a timer until a response is
   received (in which case the success retransmission timer is stopped) or failure the
   number of each
   authentication is a network policy issue.

5.12.1  Negotiating Separate NAP and ISP Authentication

   When retransmission reaches the PaC and PAA negotiates in maximum value (in which case the
   PANA session MUST be deleted immediately).

   The initial discovery and handshake phase
   to perform separate NAP and ISP authentication, the requires special handling.
   The PaC and the PAA
   operate in the following way in addition to the behavior defined in
   Section 4.1

   In the discovery and handshake phase, the PAA MAY enable separate NAP
   and ISP authentication ([I-D.ietf-pana-framework]) by setting the
   S-flag of MUST retransmit the PANA-PAA-Discover message header of the PANA-Start-Request.

   If the S-flag of the received if a subsequent
   PANA-Start-Request message is not set,
   the PaC MUST NOT set the S-flag received in the PANA-Start-Answer time.  Even though a
   PANA-Start-Request message sent
   back to is received, the PAA.

   If the S-flag of the received PANA-Start-Request PANA-PAA-Discover message is set, the
   PaC can indicate its desire
   may still have to perform separate NAP and ISP
   authentication by setting the S-flag in the PANA-Start-Answer
   message.  If the S-flag in the PANA-Start-Answer message be retransmitted.  This is not set,
   only because stateless PAA
   discovery requires one authentication is performed time transmission of a solicited
   PANA-Start-Request message.  The PAA MUST NOT start a timer and
   retransmit the processing occurs as
   described request in Section 4.1. order to avoid state creation.  If the S-flag in the PANA-Start-Answer
   received PANA-Start-Request message is set, the determination included a Cookie AVP (an
   indication of stateless PAA discovery), the destination AAA server or
   realm for ISP authentication is performed as described in Section
   5.11.  In addition, where backend AAA servers are used for NAP
   authentication, the NAP is considered PaC MUST retransmit the ultimate AAA realm, and
   PANA-PAA-Discover message until the
   destination AAA server for this authentication first PANA-Auth-Request message
   is determined entirely
   by received.  Otherwise, the local configuration PaC can rely on the access server hosting the PAA
   (NAS).

   When the S-flag is set in a PANA-Start-Request message, the initial
   EAP Request MUST NOT be carried in the PANA-Start-Request message.
   (If the initial EAP Request were contained in to retransmit
   the PANA-Start-Request message during as soon as the S-flag negotiation, PaC receives the first
   one (i.e., the PaC cannot tell whether can stop sending the EAP Request is PANA-PAA-Discover message).

   The retransmission timers SHOULD be calculated as described in
   [RFC2988] to provide congestion control.  See Section 8 for NAP authentication or ISP authentication.)

5.12.2  Execution of Separate NAP default
   timer and ISP Authentication

   When the maximum retransmission count parameters.

   The PaC and PAA have negotiated in the discovery and handshake
   phase MUST respond to perform separate NAP and ISP authentication, duplicate requests.  The last
   transmitted answer MAY be cached in case it is not received by the PaC
   peer and that generates a retransmission of the
   PAA operate in the following way in addition to last request.  When
   available, the behavior defined
   in Section 4.2

   o  The S-flag cached answer can be used instead of PANA-Auth-Request fully processing
   the retransmitted request and PANA-Auth-Answer messages forming a new answer from scratch.

   PANA MUST
      be set.

   o  An NOT generate EAP Success/Failure message is carried in a
      PANA-FirstAuth-End-Request (PFER) message as well as duplication.  EAP payload of a
      PANA-Bind-Request (PBR) message.  The PANA-FirstAuth-End-Request
   retransmitted PANA message MUST NOT be used at passed to the end EAP layer.

5.3  PANA Security Association

   A PANA SA is created as an attribute of the first a PANA session when EAP
   authentication
      and the PANA-Bind-Request MUST be used for the second EAP
      authentication.  The PANA-FirstAuth-End-Request messages MUST be
      acknowledged succeeds with a PANA-FirstAuth-End-Answer (PFEA) message.

   o  If the first EAP authentication has failed, the PAA can choose creation of a AAA-Key.  A PANA SA is
   not
      to perform created when the second EAP PANA authentication fails or no AAA-Key is
   produced by clearing the S-flag of
      the PANA-FirstAuth-End-Request message. any EAP authentication method.  In this case, the S-flag
      of case where two EAP
   sessions are performed in sequence in the PANA-FirstAuth-End-Answer message sent by PANA authentication and
   authorization phase, it is possible that two AAA-Keys are derived.
   If this happens, the PaC PANA SA MUST be
      cleared.  If the S-flag of the PANA-FirstAuth-End-Request message generated from both AAA-Keys.
   When a new AAA-Key is set when derived in the first EAP authentication has failed, PANA re-authentication phase,
   any key derived from the PaC can
      choose not old AAA-Key MUST be updated to perform the second EAP authentication by clearing a new one
   that is derived from the S-flag of new AAA-Key.  In order 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
   PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer message.  If messages at
   the end of the first EAP authentication failed which resulted in deriving a new
   AAA-Key.  The Key-Id AVP is of type Unsigned32 and MUST contain a
   value that uniquely identifies the S-flag is not set in AAA-Key within the PANA session.
   The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer
   message) sent in response to a PANA-Bind-Request message as (or a result of those operations,
      the PANA session
   PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST be immediately deleted.  Otherwise, contain a
   Key-Id AVP with the
      second EAP authentication MUST be performed.

   o  The PAA determines same AAA-Key identifier carried in the execution order of NAP authentication request.
   PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and
      ISP authentication.  In this case, the PAA can indicate which
      authentication (NAP authentication or ISP authentication)
   PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry
   a MAC AVP whose value is
      currently occurring computed by using N-flag in the PANA message header.
      When NAP authentication is being performed, new PANA_MAC_KEY
   derived from the N-flag MUST be
      set.  When ISP authentication is being performed, new AAA-Key (or the N-flag MUST
      NOT be set.  The N-flag MUST NOT be set new pair of AAA-Keys when S-flag the
   PANA_MAC_KEY is not set.

5.12.3  AAA-Key Calculation

   When derived from two AAA-Keys).  Although the PaC and PAA have negotiated in
   specification does not mandate a particular method for calculation of
   the discovery and handshake
   phase Key-Id AVP value, a simple method is to perform separate NAP and ISP authentication, if the
   lower-layer use monotonically
   increasing numbers.

   The PANA session lifetime is insecure, bounded by the two EAP authentication methods used in lifetime granted by the separate
   authentication MUST be capable server (same as the AAA-Key lifetime).  The lifetime
   of deriving keys.  In
   this case, if the first EAP authentication PANA SA (hence the PANA_MAC_KEY) is successful, the
   PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as
   well same as PANA-Auth-Request and PANA-Auth-Answer messages in the second
   EAP authentication MUST be protected with the key derived from the
   AAA-Key for lifetime
   of the first EAP authentication. PANA session.  The PANA-Bind-Request and
   PANA-Bind-Answer messages and all subsequent created PANA messages exchanged
   in authorized phase, re-authentication phase and termination phase
   MUST SA is deleted when the
   corresponding PANA session is deleted.

   PANA SA attributes as well as PANA session attributes are listed
   below:

   PANA Session attributes:

      *  Session-Id

      *  Device-Id of PaC

      *  IP address of PaC (may be protected either with the AAA-Key for same as the first EAP
   authentication if Device-Id of PaC when
         IP address is used as the first EAP authentication succeeds and device identifier)

      *  IP address of PAA

      *  List of device identifiers of EPs

      *  Sequence number of the
   second EAP authentication fails, or with last transmitted request

      *  Sequence number of the last received request

      *  Last transmitted message payload

      *  Retransmission interval

      *  Session lifetime

      *  Protection-Capability

      *  PANA SA attributes:

         +  Nonce generated by PaC (PaC_nonce)

         +  Nonce generated by PAA (PAA_nonce)

         +  AAA-Key for the second
   EAP authentication if

         +  AAA-Key Identifier

         +  PANA_MAC_KEY

   The PANA_MAC_KEY is derived from the first EAP authentication fails available AAA-Key(s) and the
   second EAP authentication succeeds, it is
   used to integrity protect PANA messages.  If there is only one
   AAA-Key available, e.g., due to ISP-only authentication, or with the compound AAA-Key
   derived from the two AAA-Keys, one for the first EAP authentication
   and the other from the second EAP authentication, if both the first
   failed and second EAP authentications succeed.

5.12.4  Re-authentication

   When one successful separate ISP and NAP and ISP authentication (see
   Section 4.7), the PANA_MAC_KEY computation is performed, it is possible based on that different authorization lifetime values are associated with the single
   key.  Otherwise, two authentications.  In this case, AAA-Keys available to PANA can be combined in
   following way ('|' indicates concatenation):

      AAA-Key = AAA-Key1 | AAA-Key2

   The PANA_MAC_KEY is computed in the following way:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID)

   where the smaller authorization
   lifetime value of N depends on the integrity protection algorithm in
   use, i.e., N=160 for HMAC-SHA1.  The length of the AAA-Key MUST be used N
   bits or longer.  See Section Section 5.4 for calculating the detailed usage of
   the PANA_MAC_KEY.

5.4  Message Authentication Code

   A PANA Session-Lifetime
   value.  As message can contain a result, when entering MAC (Message Authentication Code) AVP
   for cryptographically protecting the message.

   When a re-authentication phase, both
   NAP and ISP authentication will be performed MAC AVP is included in the same
   re-authentication phase.

5.12.5  Example Sequence

   A a PANA message sequence with separate NAP and ISP authentication message, the value field of the
   MAC AVP is
   illustrated calculated by using the PANA_MAC_KEY in Figure 9.  The example assumes the following scenario:

   o  The PaC initiates way:

      MAC AVP value = PANA_MAC_PRF(PANA_MAC_KEY, PANA_PDU)

   where PANA_PDU is the discovery and handshake phase.

   o PANA message including the PANA header, with
   the MAC AVP value field first initialized to 0.  PANA_MAC_PRF
   represents the pseudo random function corresponding to the MAC
   algorithm specified in the MAC AVP.  In this version of draft,
   PANA_MAC_PRF is HMAC-SHA1.  The PAA offers separate NAP PaC and ISP authentication, as well as PAA MUST use the same
   algorithm to calculate a
      choice of ISP from "ISP1" MAC AVP they originate and "ISP2". receive.  The PaC accepts
   algorithm is determined by the offer
      from PAA, PAA when a PANA-Bind-Request with choosing "ISP1" as the ISP.

   o  NAP authentication and ISP authentication a
   MAC AVP is performed in this
      order sent.  When the PaC does not support the MAC algorithm
   specified in authentication phase.

   o  An EAP authentication method with the PANA-Bind-Request message, it MUST silently discard
   the message.  The PAA MUST NOT change the MAC algorithm throughout
   the continuation of the PANA session.

5.5  Message Validity Check

   When a single round trip PANA message is used in
      each EAP sequence. received, the message is considered to be
   invalid at least when one of the following conditions are not met:

   o  After  The IP Hop Limit (or TTL) field has a PANA SA value of 255, i.e., the
      packet could not possibly have been forwarded by a router.

   o  Each field in the message header contains a valid value including
      sequence number, message length, message type, version number,
      flags, etc.

   o  The message type is established, all one of the expected types in the current
      state.  Specifically the following messages are integrity unexpected and
      replay protected with MAC AVPs.

   o  Authorization, re-authentication and termination phases are not
      shown.

      PaC      PAA  Message(seqno)[AVPs]
      -----------------------------------------------------
      // Discovery
      invalid:

      *  In the discovery and handshake phase
         ----->     PANA-PAA-Discover(0)
         <-----     PANA-Start-Request(x)               // S-flag set
                       [Nonce, Cookie,
                        ISP-Information("ISP1"),
                        ISP-Information("ISP2"),
                        NAP-Information("MyNAP")]
         ----->     PANA-Start-Answer(x)                // S-flag set
                       [Nonce, Cookie,                  // PaC chooses "ISP1"
                        ISP-Information("ISP1")]

      // Authentication phase
         <-----     PANA-Auth-Request(x+1)              // NAP phase:

         +  PANA-Termination-Request and PANA-Ping-Request.

         +  PANA-Bind-Request.

         +  PANA-Update-Request.

         +  PANA-Reauth-Request.

         +  PANA-Error-Request.

      *  In the authentication
                       [Session-Id, EAP{Request}]       // S- and N-flags set
         ----->     PANA-Auth-Answer(x+1)               // S- authorization phase and N-flags the
         re-authentication phase:

         +  PANA-PAA-Discover.

         +  PANA-Update-Request.

         +  PANA-Start-Request after a PaC receives the first valid
            PANA-Auth-Request.

         +  PANA-Termination-Request before the PaC receives the first
            successful PANA-Bind-Request.

      *  In the access phase:

         +  PANA-Start-Request as well as a non-duplicate
            PANA-Bind-Request.

         +  PANA-PAA-Discover.

      *  In the termination phase:

         +  PANA-PAA-Discover.

         +  All requests but PANA-Termination-Request.

   o  The message payload contains a valid set
                       [Session-Id]                     // No piggybacking
         ----->     PANA-Auth-Request(y)                // S- of AVPs allowed for the
      message type and N-flags set
                       [Session-Id, EAP{Response}]
         <-----     PANA-Auth-Answer(y)[Session-Id]     // S- there is no missing AVP that needs to be included
      in the payload.

   o  Each AVP is decoded correctly.

   o  When a MAC AVP is included, the AVP value matches the MAC value
      computed against the received message.

   o  When a Device-Id AVP is included, the AVP is valid if the device
      identifier type contained in the AVP is supported (check performed
      by both the PaC and N-flags set
         <-----     PANA-Auth-Request(x+2)              // S- the PAA) and N-flags set
                       [Session-Id, EAP{Request}]
         ----->     PANA-Auth-Answer(x+2)               // S- is the requested one (check
      performed by the PAA only) and N-flags set
                       [Session-Id, EAP{Response}]      // Piggybacking
         <-----     PANA-FirstAuth-End-Request(x+3)     // S- and N-flags set
                       [Session-Id, EAP{Success}, Key-Id, MAC]
         ----->     PANA-FirstAuth-End-Answer(x+3)      // S- and N-flags set
                       [Session-Id, Key-Id, MAC]
         <-----     PANA-Auth-Request(x+4)              // ISP authentication
                       [Session-Id, EAP{Request}, MAC]  // S-flag set
         ----->     PANA-Auth-Answer(x+4)               // S-flag set
                       [Session-Id, MAC]                // No piggybacking
         ----->     PANA-Auth-Request(y+1)              // S-flag set
                       [Session-Id, EAP{Response}, MAC]
         <-----     PANA-Auth-Answer(y+1)               // S-flag set
                       [Session-Id, MAC]
         <-----     PANA-Auth-Request(x+5)              // S-flag set
                       [Session-Id, EAP{Request}, MAC]
         ----->     PANA-Auth-Answer(x+5)               // S-flag set
                       [Session-Id, EAP{Response}, MAC] // Piggybacking
         <-----     PANA-Bind-Request(x+6)              // S-flag set
                       [Session-Id, EAP{Success}, Device-Id,
                       IP-Address, Key-Id, Lifetime,
                       Protection-Cap., PPAC, MAC]
         ----->     PANA-Bind-Answer(x+6)               // S-flag set
                       [Session-Id, Device-Id, Key-Id,
                        PPAC, MAC]

     Figure 9: A Complete Message Sequence for Separate NAP and ISP
                             Authentication

6.  Security and Mobility

6.1  PANA Security Association Establishment

   When PANA is used over an already established secure channel, such as
   physically secured wires or ciphered link-layers, we can reasonably
   assume that man-in-the-middle attacks or service theft is not
   possible.  See [I-D.ietf-pana-threats-eval] for a detailed
   discussion.

   In environments where no secure channel prior to the PANA execution
   is available, PANA needs to protect itself against a number of
   attacks.  The device identifier that is used during value
      contained in the
   authentication needs to be verified at AVP matches the end of value extracted from the authentication
      lower-layer encapsulation header corresponding to prevent service theft and DoS attacks.  Additionally, a free
   loader should be prevented from spoofing data packets the device
      identifier type contained in the AVP (check performed by using the PAA
      only).  Note that a Device-Id AVP carries the device identifier of an already authorized legitimate client.  Both
   of these requirements necessitate generation of a security
   association between
      the PaC and in messages from the PaC to the PAA at and the end device
      identifier(s) of the
   authentication.  This can only be done when EP(s) in messages from the authentication method
   used can generate session keys.  Use of session keys can prevent
   attacks which would otherwise be very easy PAA to launch by eavesdropping
   on and spoofing traffic over the PaC.

   o  When an insecure link.

   The EAP method provided session key IP-Address AVP is transported to received in a message, the PAA (if
   necessary) and AVP is subsequently input to the creation of valid
      if the PANA SA.
   Applying IP address matches the PANA SA to source address in the IP header.

   Invalid messages exchanged during the final PANA
   handshake provides implicit key confirmation MUST be discarded in order to provide robustness
   against DoS attacks.  In addition, an error notification message MAY
   be returned to both the PAA and the
   PaC.  Implicit key confirmation shows both, the PaC and the PAA, that
   they possess the unique and fresh session key.

   Protecting the final PANA handshake also ensures that the sender.  See Section 5.10 for details.

5.6  Device ID Choice

   The device identifier (and other information) cannot used in the context of PANA can be modified by an
   adversary.  Further usage of the keying material IP
   address, a MAC address, or an identifier that is discussed not carried in
   [I-D.ietf-pana-framework].

6.2  Mobility

   A mobile PaC's network access authentication performance can be
   enhanced by deploying data
   packets but has local significance in identifying a context-transfer-based mechanism, connected device
   (e.g., circuit id, PPP interface id).  The last type of identifiers
   are commonly used in point-to-point links where some
   session attributes MAC addresses are transferred from not
   available and lower-layers are already physically or
   cryptographically secured.

   It is assumed that the previous PAA to knows the new
   one in order to avoid performing a full EAP authentication (reactive
   approach).  Additional mechanisms that are based link type and the security
   mechanisms being provided or required on the proactive AAA
   state establishment at one access network (e.g.,
   based on physical security, link-layer ciphers enabled before or more candidate PAAs may be developed in
   after PANA, or IPsec).  Based on that information, the future [I-D.irtf-aaaarch-handoff].  The details of a
   context-transfer-based mechanism is provided in this section.

   Upon changing its point PAA can decide
   what type of attachment, a PaC that wants to quickly
   resume its ongoing PANA session without EP device id will be used when 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
   client.  When IPsec-based security [I-D.ietf-pana-ipsec] is computed by using the PANA_MAC_KEY shared
   between
   choice of access control, the PaC and its previous PAA that has an unexpired PANA
   session with SHOULD provide IP address(es) as
   EP(s)' device ID, and expect the PaC.  This action signals PaC's desire PaC to perform
   the mobility optimization. provide its IP address in
   return.  In the absence of case IPsec is not used, MAC addresses are used as device
   identifiers when available.  If non-IPsec access control is enabled,
   and a Session-Id AVP MAC address is not available, device ID exchange does not occur
   within PANA.  Instead, peers rely on lower-layers to provide
   locally-significant identifiers along with received PANA messages.

5.7  PaC Updating its IP Address

   A PaC's IP address can change in
   this message, certain situations.  For example,
   the PANA session takes its usual course (i.e.,
   EAP-based authentication is performed).

   If a PAA receives framework [I-D.ietf-pana-framework] describes a session identifier case in
   which a PaC replaces a pre-PANA address (PRPA) with a post-PANA
   address (POPA), and the PANA-Start-Answer
   message, PaC 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 create host routes to each other
   in order to maintain on-link communication based on the PANA session identifier. POPA.  The MAC AVP
   can only
   PAA needs to be verified by notified about the previous PAA, therefore a copy change of PaC address.

   After the
   PANA PaC has changed its address, it MUST send a
   PANA-Update-Request message SHOULD be provided to the previous PAA.  The mechanism
   required to send a copy of the PANA-Start-Answer message from current
   PAA to MUST carry the previous PAA, and retrieve
   new PaC address in an IP-Address AVP.  If the session attributes is
   outside address contained in
   the scope of PANA protocol.  The Context Transfer Protocol
   [I-D.ietf-seamoby-ctp] might be useful for this purpose.

   When request is invalid, the previous or current PAA is not configured to enable this
   optimization, MUST send a PANA-Error message with a
   result code PANA_INVALID_IP_ADDRESS.  Otherwise, the current PAA can not retrieve MUST update
   the PANA session
   attributes, or with the PANA session has already expired (i.e., session
   lifetime new PaC address and return a
   PANA-Update-Answer message.  If there is zero), the PAA an established PANA SA, both
   PANA-Update-Request and PANA-Update-Answer messages MUST send the PANA-Auth-Request message be protected
   with a new session identifier and let the PANA exchange take its
   usual course.  This action will engage EAP-based MAC AVP.

5.8  Session Lifetime

   The authentication and
   create a fresh authorization phase determines the PANA
   session from scratch.

   In case lifetime when the current PAA can retrieve network access authorization succeeds.  The
   Session-Lifetime AVP MAY be optionally included in the on-going PANA session
   attributes from
   PANA-Bind-Request message to inform the previous PAA, PaC about the valid lifetime
   of the PANA session continues with a
   PANA-Bind exchange.

   As part of the context transfer, an intermediate AAA-Key material session.  It MUST be ignored when included in other PANA
   messages.

   The lifetime is
   provided a non-negotiable parameter that can be used by the previous PAA
   PaC to the current PAA.

      AAA-Key-int = The first N bits of
                    HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) manage PANA-related state.  The value of N depends on PaC does not have to perform
   any actions when the integrity protection algorithm in use,
   i.e., N=160 for HMAC-SHA1.  DiameterIdentity is lifetime expires, other than optionally purging
   local state.  The PAA SHOULD initiate the identifier of PANA re-authentication
   phase before the current PAA.  Session-ID is the identifier of the PaC's PANA session
   with the previous PAA. lifetime expires.

   The current PAA and PaC compute the new AAA-Key by using the nonce
   values and PAA MAY optionally rely on lower-layer indications to
   expedite the AAA-Key-int.

      AAA-Key-new = The first N bits detection of
                    HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce)

   New PANA_MAC_KEY is computed based a disconnected peer.  Availability and
   reliability of such indications depend on the algorithm described in
   Section 5.6, by using the new AAA-Key and specific access
   technologies.  A PANA peer can use the new Session-ID assigned
   by PANA-Ping exchange to verify
   the current PAA. disconnection before taking an action.

   The MAC AVP contained in session lifetime parameter is not related to the PANA-Bind-Request
   and PANA-Bind-Answer transmission of
   PANA-Ping-Request messages.  These messages MUST can be generated and verified by using used for
   asynchronously verifying the new PANA_MAC_KEY. liveness of the peer.  The Session-ID AVP MUST include decision to
   send a new session
   identifier assigned by PANA-Ping-Request message is taken locally and does not
   require coordination between the current PAA.  A new PANA session peers.

   When separate ISP and NAP authentication is
   created upon successful completion of this exchange.

   Note that correct operation of this optimization relies on many
   factors, including applicability of performed, it is possible
   that different authorization state from one
   network attachment to another.  [I-D.ietf-eap-keying] identifies this
   operation as "fast handoff" and provides deployment considerations.
   Operators lifetime values are recommended to take those guidelines into account when
   using associated with the
   two EAP authentication sessions.  In this optimization in their networks.

7.  PANA Headers and Formats

   This section defines message formats for PANA protocol.

7.1  IP and UDP Headers

   The Hop Limit (or TTL) field of case, the IP header smaller
   authorization lifetime value MUST be set to 255.
   When a PANA-PAA-Discover message is multicast, IP destination address
   of used for calculating the message is set to PANA
   Session-Lifetime value.  As a well-known link-local multicast address
   (TBD).  A PANA-PAA-Discover message MAY result, both NAP and ISP authentication
   will be unicast in some cases as
   specified performed in Section 4.1.  Any other the re-authentication phase.

5.9  Network Selection

   The PANA packet is unicast between discovery and handshake phase allows the PaC and to learn
   identity of the PAA.  The source NAP and destination addresses SHOULD be
   set to a list of ISPs that are available through the addresses on
   NAP.  The PaC can not only learn the interfaces from which ISPs but also convey the message will be
   sent and received, respectively.

   When
   selected ISP explicitly during the PANA packet handshake phase.  The PAA is sent in response
   assumed to a request, be pre-configured with the UDP source
   and destination ports information of ISPs that are
   served by the response packet MUST be copied NAP.

   A PANA-Start-Request message sent from the
   destination PAA MAY contain zero or
   one NAP-Information AVP, and source ports of the request packet, respectively. zero or more ISP-Information AVPs.  The destination port
   PaC MAY indicate its choice of an unsolicited PANA packet MUST be set to an
   assigned value (TBD), and the source port MUST be set to a value
   chosen ISP by including an ISP-Information
   AVP in the sender.

7.2  PANA Header

   A summary of the PANA header format is shown below. PANA-Start-Answer message.  The fields are
   transmitted PaC MAY convey its ISP
   even when there is no ISP-Information AVP contained in network byte order.

          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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |   Reserved    |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Flags              |         Message Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sequence Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version

      This Version field MUST be set to 1 to indicate PANA Version 1.

   Reserved

      This 8-bit field the
   PANA-Start-Request message.  The PaC can do that when it is reserved for future use, and MUST be set to
      zero,
   pre-configured with ISP information.

   In the absence of an ISP explicitly selected and ignored conveyed by the receiver.

   Message Length

      The Message Length field PaC,
   ISP selection is three octets and indicates typically performed based on the length client identifier
   (e.g., using the realm portion of an NAI carried in EAP method).  A
   backend AAA protocol (e.g., RADIUS) will run between the PANA message including AAA client
   on the header fields.

   Flags

      The Flags field is eight bits. PAA and a AAA server in the selected ISP domain.

   The following bits are assigned:

       0                   1
       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(equest)

         If set, PANA-based ISP selection mechanism dictates the message is a request.  If cleared, next-hop AAA
   proxy on the message is
         an answer.

      S(eparate)

         When PAA.  If the S-flag is set in a PANA-Start-Request message NAP requires all AAA traffic to go through
   its local AAA proxy, it
         indicates that PAA is willing may have to offer separate NAP and ISP
         authentication.  When the S-flag is set in rely on a PANA-Start-Answer
         message it indicates that mechanism to relay the PaC accepts on performing
         separate NAP and
   selected ISP authentication.  When information from PAA (AAA client) to the S-flag is set in
         a 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 local AAA
   proxy.  The local AAA proxy can forward the
         authentication phase.  For other cases, S-flag MUST NOT be set.

      N(AP authentication)

         When AAA traffic to the N-flag is set in a PANA-Auth-Request message, it
         indicates that
   selected ISP domain upon processing.  Further details, including how
   the current EAP authentication is for NAP
         authentication.  When AAA client relays AAA routing information to the N-flag AAA proxy, are
   outside the scope of PANA.

   An alternative ISP discovery mechanism is unset outlined in a
         PANA-Auth-Request message, it indicates that
   [I-D.adrangi-eap-network-discovery] which suggests advertising ISP
   information in-band with the current ongoing EAP
         authentication is for method execution.
   Deployments using the PANA's built-in ISP authentication.  The PaC MUST copy discovery mechanism need
   not use the value of other mechanism.

5.10  Error Handling

   A PANA-Error-Request message MAY be sent by either the flag in its requests from PaC or the last PAA
   when a badly formed PANA message is received
         request or in case of the PAA. other
   errors.  The value receiver of the flag on an answer this request MUST be
         copied from respond with a
   PANA-Error-Answer message.  If the request.  The N-flag MUST NOT cause of this error message was a
   request message (e.g., PANA-PAA-Discover or *-Request), then the
   request MAY be set when
         S-flag is not set.

      r(eserved)

         these flag bits are reserved retransmitted immediately without waiting for future use, and MUST be set to
         zero, and ignored by the receiver.

   Message Type

      The Message Type field is two octets, and is used in order its
   retransmission timer to
      communicate go off.  If the message type with cause of the message.  The 16-bit address
      space is managed by IANA [ianaweb].  PANA uses its own address
      space for this field.

   Sequence Number

      The Sequence Number field contains a 32 bit value.

   AVPs

      AVPs are error was a method
   response message, the receiver of encapsulating information relevant to the PANA-Error-Request message
   SHOULD NOT resend the same response until it receives the next
   request.

   Erroneous PANA message.  See section Section 7.3 for more information on
      AVPs.

7.3  AVP Header

   Each AVP of type OctetString MUST messages may be padded exploited by adversaries to align launch DoS
   attacks on a 32-bit
   boundary, while other AVP types align naturally.  A number of
   zero-valued bytes are added the victims.  Unless the PaC or PAA rate-limits the
   generated PANA-Error-Request messages it may be overburdened by
   having to respond to bogus messages.  Limiting the end number of the AVP Data field till error
   notifications sent to a
   word boundary is reached.  The length given peer during a (configurable) period of
   time may be useful.

   When an error message is sent unprotected (i.e., no MAC AVP) and the padding
   lower-layer is not reflected
   in insecure, the AVP Length field [RFC3588]. error message is treated as an
   informational message.  The fields in receiver of such an error message MUST
   NOT change its state unless the AVP error persists and the PANA session
   is not making any progress.

6.  PANA Headers and Formats

   This section defines message formats for PANA protocol.

6.1  IP and UDP Headers

   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
   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
   specified in Section 4.2.  Any other PANA packet is unicast between
   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
   sent and received, respectively.

   When the PANA packet is sent in network byte order. response to a request, the UDP source
   and destination ports of the response packet MUST be copied from the
   destination and source ports of the request packet, respectively.
   The
   format 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
   chosen by the sender.

   The maximum PANA packet size is limited by the maximum UDP payload.

6.2  PANA Header

   A summary of the PANA header is: format is shown below.  The fields are
   transmitted in network byte order.

          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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           AVP Code    Version    |           AVP Flags   Reserved    |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length            Flags              |            Reserved         Message Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Vendor-Id (opt)                      Sequence Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data  AVPs ...
      +-+-+-+-+-+-+-+-+
   AVP Code

      The AVP Code, combined with the Vendor-Id field, identifies the
      attribute uniquely.  AVP numbers are allocated by IANA [ianaweb].
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
      This Version field MUST be set to 1 to indicate PANA uses its own address space Version 1.

   Reserved

      This 8-bit field is reserved for this future use, and MUST be set to
      zero, and ignored by the receiver.

   Message Length

      The Message Length field although some is three octets and indicates the length
      of the AVP formats are borrowed from Diameter protocol [RFC3588].

   AVP PANA message including the header fields.

   Flags

      The AVP Flags field is two octets.  The following bits are assigned:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V M r
      |R S N r r r r r r r r r r r r r|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      M(andatory)

         The 'M' Bit, known as

      R(equest)

         If set, the Mandatory bit, indicates whether
         support of message is a request.  If cleared, the AVP message is required.

      V(endor)

         The 'V' bit, known as
         an answer.

      S(eparate)

         When the Vendor-Specific bit, S-flag is set in a PANA-Start-Request message it
         indicates
         whether that PAA is willing to offer separate NAP and ISP
         authentication.  When the optional Vendor-Id field S-flag is present set in a PANA-Start-Answer
         message it indicates that the AVP
         header.

      r(eserved)

         These flag bits are reserved for future use, PaC accepts on performing
         separate NAP and MUST be ISP authentication.  The PaC may also respond
         with the S-flag not set which implies the PaC has chosen to
         zero, and ignored by
         authenticate with the receiver.

   AVP Length

      The AVP Length field ISP only.  When the S-flag is four octets, set in a
         PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and
         PANA-Bind-Request/Answer messages it indicates the number of
      octets that separate
         NAP and ISP authentication is being performed in this AVP including the AVP Code, AVP Length, AVP Flags,
         authentication and the AVP data.

   Reserved

      This two-octet field is authorization phase.  For other cases,
         S-flag MUST NOT be set.

      N(AP authentication)
         When the N-flag is set in a PANA-Auth-Request message, it
         indicates that the current EAP authentication is for NAP
         authentication.  When the N-flag is unset in a
         PANA-Auth-Request message, it indicates that the current EAP
         authentication is for ISP authentication.  The PaC MUST copy
         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
         copied from the request.  The N-flag MUST NOT be set when
         S-flag is not set.

      r(eserved)

         These flag bits are reserved for future use, and MUST be set to
         zero, and ignored by the receiver.

   Vendor-Id

   Message Type

      The Vendor-Id Message Type field is present if the 'V' bit two octets, and is set used in order to
      communicate the AVP
      Flags field.  The optional four-octet Vendor-Id field contains message type with the message.  The 16-bit address
      space is managed by IANA assigned "SMI Network Management Private Enterprise Codes"
      [ianaweb] value, encoded in network byte order.  Any vendor
      wishing to implement a vendor-specific [ianaweb].  PANA AVP MUST use their uses its own
      Vendor-Id along with their privately managed AVP address space,
      guaranteeing that they will not collide with any other vendor's
      vendor-specific AVP(s), nor with future IETF applications.

   Data
      space for this field.

   Sequence Number

      The Data Sequence Number field is zero or more octets and contains a 32 bit value.

   AVPs

      AVPs are a method of encapsulating information
      specific relevant to the Attribute.  The format and length of the Data
      field is determined by the
      PANA message.  See section Section 6.3 for more information on
      AVPs.

6.3  AVP Code and Header

   Each AVP Length fields.

8.  PANA Messages, Message Specifications and AVPs

8.1  PANA Messages

   Figure 10 lists all PANA messages defined in this document.

                 Message          Direction: PaC---PAA
                 ----------------------------------------
                 PANA-PAA-Discover           -------->

                 PANA-Start-Request          <--------
                 PANA-Start-Answer           -------->

                 PANA-Auth-Request           <------->
                 PANA-Auth-Answer            <------->

                 PANA-Reauth-Request         -------->
                 PANA-Reauth-Answer          <--------

                 PANA-FirstAuth-End-Request  <--------
                 PANA-FirstAuth-End-Answer   -------->

                 PANA-Bind-Request           <--------
                 PANA-Bind-Answer            -------->

                 PANA-Ping-Request           <------->
                 PANA-Ping-Answer            <------->

                 PANA-Termination-Request    <------->
                 PANA-Termination-Answer     <------->

                 PANA-Update-Request         -------->
                 PANA-Update-Answer          <--------

                 PANA-Error-Request          <------->
                 PANA-Error-Answer           <------->

                    Figure 10: PANA Message Overview

8.2  Message Specifications

   Every PANA message of type OctetString MUST include be padded to align on a corresponding ABNF [RFC2234]
   specification found in [RFC3588].

   Example:

      message ::= < PANA-Header: <Message type>, [REQ] [SEP] >
                * [ 32-bit
   boundary, while other AVP ]

8.2.1  PANA-PAA-Discover (PDI)

   The PANA-PAA-Discover (PDI) message is used to discover the address types align naturally.  A number of PAA(s).  Both sequence numbers in this message
   zero-valued bytes are set added to zero
   (0).

         PANA-PAA-Discover ::= < PANA-Header: 1 >
                    *  [ the end of the AVP ]

8.2.2  PANA-Start-Request (PSR)

   PANA-Start-Request (PSR) Data field till a
   word boundary is sent by reached.  The length of the PAA to padding is not reflected
   in the PaC. AVP Length field [RFC3588].

   The PAA sets fields in the sequence number to an initial random value.

         PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] >
                       { Nonce }
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ NAP-Information ]
                    *  [ ISP-Information ]
                       [ Protection-Capability]
                       [ PPAC ]
                    *  [ AVP ]

8.2.3  PANA-Start-Answer (PSA)

   PANA-Start-Answer (PSA) is header are sent by the PaC to the PAA in response to
   a PANA-Start-Request message.

         PANA-Start-Answer ::= < PANA-Header: network byte order.  The
   format of the header is:

          0                   1                   2 [SEP] >
                       { Nonce }
                       [ Session-Id ]
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ ISP-Information ]
                    *  [                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           AVP ]
                   0*1 < MAC >

8.2.4  PANA-Auth-Request (PAR)

   PANA-Auth-Request (PAR) is sent by Code            |           AVP Flags           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Vendor-Id (opt)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   AVP Code

      The AVP Code, combined with the PAA to Vendor-Id field, identifies the PaC.

         PANA-Auth-Request ::= < PANA-Header: 3, REQ [SEP] [NAP] >
                       < Session-Id >
                       < EAP-Payload >
                    *  [
      attribute uniquely.  AVP ]
                   0*1 < MAC >

8.2.5  PANA-Auth-Answer (PAN)

   PANA-Auth-Answer (PAN) is sent numbers are allocated by IANA [ianaweb].
      PANA uses its own address space for this field although some of
      the PaC to the PAA in response to a
   PANA-Auth-Request message.

         PANA-Auth-Answer ::= < PANA-Header: AVP formats are borrowed from Diameter protocol [RFC3588].

   AVP Flags

      The AVP Flags field is two octets.  The following bits are
      assigned:

       0                   1
       0 1 2 3 [SEP] [NAP] >
                       < Session-Id >
                       < EAP-Payload >
                    *  [ 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|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      M(andatory)

         The 'M' Bit, known as the Mandatory bit, indicates whether
         support of the AVP ]
                   0*1 < MAC >

8.2.6  PANA-Reauth-Request (PRAR)

   PANA-Reauth-Request (PRAR) is sent required.
         If an AVP with the 'M' bit set is received by the PaC to or PAA
         and either the PAA.

         PANA-Reauth-Request ::= < PANA-Header: 4, REQ >
                       < Session-Id >
                    *  [ AVP ]
                   0*1 < MAC >

8.2.7  PANA-Reauth-Answer (PRAA)

   PANA-Reauth-Answer (PRAA) or its value is sent by unrecognized, the PAA to message
         MUST be rejected and the PaC in response
   to receiver MUST send a PANA-Reauth-Request
         PANA-Error-Request message.

         PANA-Reauth-Answer ::= < PANA-Header: 4 >
                       < Session-Id >
                    *  [  If the AVP ]
                   0*1 < MAC >

8.2.8  PANA-Bind-Request (PBR)

   PANA-Bind-Request (PBR) is sent by was unrecognized the PAA to
         PANA-Error-Request message result code MUST be
         PANA_AVP_UNSUPPORTED.  If the PaC.

         PANA-Bind-Request ::= < PANA-Header: 5, REQ [SEP] [NAP] >
                       < Session-Id >
                       { Result-Code }
                       { PPAC }
                       { IP-Address }
                       [ EAP-Payload ]
                       [ Session-Lifetime ]
                       [ Protection-Capability ]
                       [ Key-Id ]
                    *  [ Device-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

8.2.9  PANA-Bind-Answer (PBA)

   PANA-Bind-Answer (PBA) is sent by value was unrecognized the PaC to
         PANA-Error-Request message result code MUST be
         PANA_INVALID_AVP_DATA.  In either case the PAA in response to PANA-Error-Request
         message MUST carry a
   PANA-Result-Request message.

         PANA-Bind-Answer ::= < PANA-Header: 5 [,SEP] [NAP] >
                       < Session-Id >
                       { Result-Code }
                       [ PPAC ]
                       [ Device-Id ]
                       [ Key-Id ]
                    *  [ Failed-AVP AVP ]
                   0*1 < MAC >

8.2.10  PANA-Ping-Request (PPR)

   PANA-Ping-Request (PPR) is either sent by containing the PaC or offending
         mandatory AVP.
         AVPs with the PAA.

         PANA-Ping-Request ::= < PANA-Header: 6, REQ >
                       < Session-Id >
                    *  [ AVP ]
                   0*1 < MAC >

8.2.11  PANA-Ping-Answer (PPA)

   PANA-Ping-Answer (PPA) is sent in response to 'M' bit cleared are informational only and a PANA-Ping-Request.

         PANA-Ping-Answer ::= < PANA-Header: 6 >
                       < Session-Id >
                    *  [
         receiver that receives a message with such an AVP ]
                   0*1 < MAC >

8.2.12  PANA-Termination-Request (PTR)

   PANA-Termination-Request (PTR) that is sent either by the PaC not
         supported, or the PAA.

         PANA-Termination-Request ::= < PANA-Header: 7, REQ >
                       < Session-Id >
                       < Termination-Cause >
                    *  [ AVP ]
                   0*1 < MAC >

8.2.13  PANA-Termination-Answer (PTA)

   PANA-Termination-Answer (PTA) whose value is sent either by not supported, MAY simply ignore
         the PaC or AVP.

      V(endor)

         The 'V' bit, known as the PAA Vendor-Specific bit, indicates
         whether the optional Vendor-Id field is present in
   response to PANA-Termination-Request.

         PANA-Termination-Answer ::= < PANA-Header: 7 >
                       < Session-Id >
                    *  [ the AVP ]
                   0*1 < MAC >

8.2.14  PANA-Error-Request (PER)

   PANA-Error is sent either
         header.  When set the AVP Code belongs to the specific vendor
         code address space.

      r(eserved)

         These flag bits are reserved for future use, and MUST be set to
         zero, and ignored by the PaC or receiver.
      Unless otherwise noted, AVPs defined in this document will have
      the PAA.

         PANA-Error-Request ::= < PANA-Header: 8 REQ >
                        < Session-Id >
                        < Result-Code >
                        { Failed-AVP }
                     *  [ following default AVP ]
                    0*1 < MAC >

8.2.15  PANA-Error-Answer (PEA)

   PANA-Error-Answer Flags field settings: The 'M' bit MUST
      be set.  The 'V' bit MUST NOT be set.

   AVP Length

      The AVP Length field is sent four octets, and indicates the number of
      octets in response to a PANA-Error-Request.

         PANA-Error-Answer ::= < PANA-Header: 8 >
                        < Session-Id >
                     *  [ this AVP ]
                    0*1 < MAC >

8.2.16  PANA-FirstAuth-End-Request (PFER)

   PANA-FirstAuth-End-Request (PFER) including the AVP Code, AVP Length, AVP Flags,
      and the AVP data.

   Reserved

      This two-octet field is sent reserved for future use, and MUST be set
      to zero, and ignored by the PAA to receiver.

   Vendor-Id

      The Vendor-Id field is present if the PaC.

         PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [SEP] [NAP] >
                       < Session-Id >
                       { EAP-Payload }
                       { Result-Code }
                       [ Key-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

8.2.17  PANA-FirstAuth-End-Answer (PFEA)

   PANA-FirstAuth-End-Answer (PFEA) 'V' bit is sent by set in the PaC to AVP
      Flags field.  The optional four-octet Vendor-Id field contains the PAA
      IANA assigned "SMI Network Management Private Enterprise Codes"
      [ianaweb] value, encoded in
   response network byte order.  Any vendor
      wishing to implement a PANA-FirstAuth-End-Request message.

         PANA-FirstAuth-End-Answer ::= < PANA-Header: 9, REQ [SEP] [NAP] >
                       < Session-Id >
                       [ Key-Id ]
                    *  [ vendor-specific PANA AVP ]
                   0*1 < MAC >

8.2.18  PANA-Update-Request (PUR)

   PANA-Update-Request (PUR) MUST use their own
      Vendor-Id along with their privately managed AVP address space,
      guaranteeing that they will not collide with any other vendor's
      vendor-specific AVP(s), nor with future IETF applications.

   Data

      The Data field is sent by the PaC zero or more octets and contains information
      specific to the PAA.

         PANA-Update-Request ::= < PANA-Header: 10, REQ >
                       < Session-Id >
                       < IP-Address >
                    *  [ AVP ]
                   0*1 < MAC >

8.2.19  PANA-Update-Answer (PUA)

   PANA-Update-Answer (PUA) Attribute.  The format and length of the Data
      field is sent determined by the PAA to the PaC in response to
   a PANA-Update-Request.

         PANA-Update-Answer ::= < PANA-Header: 10 >
                       < Session-Id >
                    *  [ AVP ]
                   0*1 < MAC >

8.3 Code and AVP Length fields.

7.  PANA Messages, Message Specifications and AVPs

7.1  PANA Messages

   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.

   Every PANA defines several AVPs that are specific message MUST contain a message ID in its header's
   Message-Id field, which is used to determine the protocol.  A
   number of others AVPs are reused.  These are specified in other
   documents such as [RFC3588].

   The following tables action that is to be
   taken for a particular message.  Figure 9 lists the AVPs used all PANA messages
   defined in this document, and
   specifies in which document:

   Message-Name                Abbrev. ID PaC<->PAA  Ref.
   -----------------------------------------------------------
   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
   -----------------------------------------------------------

                    Figure 9: Table of PANA messages they MAY, Messages

7.2  PANA Message ABNF Specification

   Every PANA message defined MUST include a corresponding ABNF
   [RFC2234] specification, which is used to define the AVPs that MUST
   or MAY NOT be present.  The table uses the following symbols:

   0     The AVP MUST NOT be present format is used in the message.

   0+    Zero or more instances of the AVP MAY be present in definition:

   message-def      = Message-Name "::=" PANA-message

   message-name     = PANA-name
   PANA-name        = ALPHA *(ALPHA / DIGIT / "-")

   PANA-message     = header  [ *fixed] [ *required] [ *optional]
                      [ *fixed]

   header           = "< PANA-Header: " Message-Id
                      [r-bit] [s-bit] [n-bit] ">"

   Message-Id       = 1*DIGIT
                      ; The message code assigned to the
         message.

   0-1   Zero or one instance of message

   r-bit            = ", REQ"
                      ; If present, the AVP MAY be present 'R' bit in the message.
         It Message
                      ; Flags is considered an error if there are more than one instance
         of set, indicating that the AVP.

   1     One instance of message
                      ; is a request, as opposed to an answer.

   s-bit            = ", SEP"
                      ; If present, the AVP MUST be present 'S' bit in the message.

   1+    At least one instance of Message
                      ; Flags is set, indicating support for
                      ; separate NAP and ISP authentication.

   n-bit            = ", NAP"
                      ; If present, the 'N' bit in the Message
                      ; Flags is set, indicating that current
                      ; EAP authentication is for NAP authentication.

   fixed            = [qual] "<" avp-spec ">"
                      ; Defines the fixed position of an AVP

   required         = [qual] "{" avp-spec "}"
                      ; The AVP MUST be present and can appear
                      ; anywhere in the message.

                          +-----------------------------------------+
                          |                 Message                 |
                          |                   Type                  |
                          +-----+-----+-----+-----+-----+-----+-----+
      Attribute

   optional         = [qual] "[" avp-name "]"
                      ; The avp-name in the 'optional' rule cannot
                      ; evaluate to any AVP Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
      --------------------+-----+-----+-----+-----+-----+-----+-----+
      Result-Code         |  0  |  0  |  0  |  0  |  1  |  1  |  0  |
      Session-Id          |  0  | 0-1 |  1  |  1  |  1  |  1  |  0  |
      Termination-Cause   |  0  |  0  |  0  |  0  |  0  |  0  | 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  |
      EAP-Payload         | 0-1 | 0-1 | or 1  | 0-1 | 0-1 |  0  |  0  | 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
                      ; MAC                 |  0  | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 |  0  |
      Nonce               |  1  |  1  |  0  |  0  |  0  |  0  |  0  |
      Device-Id           |  0  |  0  |  0  |  0  |  0+ | 0-1 |  0  | 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 ]
                   0*1 < MAC >

7.2.1  PANA-PAA-Discover (PDI)

   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
   (0).

         PANA-PAA-Discover ::= < PANA-Header: 1 >
                       [ Notification ]
                    *  [ AVP ]

7.2.2  PANA-Start-Request (PSR)

   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
   PAA sets the sequence number to an initial random value.

         PANA-Start-Request ::= < PANA-Header: 2, REQ [, SEP] >
                       { Nonce }
                       [ Cookie              | 0-1 | 0-1 |  0  |  0  |  0  |  0  |  0  |
      Protection-Cap.     | 0-1 |  0  |  0  |  0  | 0-1 |  0  |  0  | ]
                       [ EAP-Payload ]
                       [ NAP-Information ]
                    *  [ ISP-Information ]
                       [ Protection-Capability]
                       [ PPAC                | 0-1 |  0  |  0  |  0  |  1  | 0-1 |  0  | ]
                       [ Notification ]
                    *  [ AVP ]

7.2.3  PANA-Start-Answer (PSA)

   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
   handshake to start PANA authentication.

         PANA-Start-Answer ::= < PANA-Header: 2 [, SEP] >
                       { Nonce }
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ ISP-Information ]
                       [ Notification ]
                    *  [ AVP ]

7.2.4  PANA-Auth-Request (PAR)

   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.

         PANA-Auth-Request ::= < PANA-Header: 3, REQ [, SEP] [, NAP] >
                       < Session-Id >
                       < EAP-Payload >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.5  PANA-Auth-Answer (PAN)

   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
   EAP-Payload AVP.

         PANA-Auth-Answer ::= < PANA-Header: 3 [, SEP] [, NAP] >
                       < Session-Id >
                       [ EAP-Payload ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.6  PANA-Reauth-Request (PRAR)

   The PANA-Reauth-Request (PRAR) message is sent by the PaC to the PAA
   to re-initiate EAP authentication.

         PANA-Reauth-Request ::= < PANA-Header: 4, REQ >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.7  PANA-Reauth-Answer (PRAA)

   The PANA-Reauth-Answer (PRAA) message is sent by the PAA to the PaC
   in response to a PANA-Reauth-Request message.

         PANA-Reauth-Answer ::= < PANA-Header: 4 >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.8  PANA-Bind-Request (PBR)

   The PANA-Bind-Request (PBR) message is sent by the PAA to the PaC to
   deliver the result of PANA authentication.

         PANA-Bind-Request ::= < PANA-Header: 5, REQ [, SEP] [, NAP] >
                       < Session-Id >
                       { Result-Code }
                       { PPAC }
                       { IP-Address }
                       [ EAP-Payload ]
                       [ Session-Lifetime    |  0  |  0  |  0  |  0  | 0-1 |  0  |  0  | ]
                       [ Protection-Capability ]
                       [ Key-Id ]
                    *  [ Device-Id ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.9  PANA-Bind-Answer (PBA)

   The PANA-Bind-Answer (PBA) message is sent by the PaC to the PAA in
   response to a PANA-Bind-Request message.

         PANA-Bind-Answer ::= < PANA-Header: 5 [,SEP] [, NAP] >
                       < Session-Id >
                       [ PPAC ]
                       [ Device-Id ]
                       [ Key-Id ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.10  PANA-Ping-Request (PPR)

   The PANA-Ping-Request (PPR) message is either sent by the PaC or the
   PAA for performing liveness test.

         PANA-Ping-Request ::= < PANA-Header: 6, REQ >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.11  PANA-Ping-Answer (PPA)

   The PANA-Ping-Answer (PPA) message is sent in response to a
   PANA-Ping-Request.

         PANA-Ping-Answer ::= < PANA-Header: 6 >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.12  PANA-Termination-Request (PTR)

   The PANA-Termination-Request (PTR) message is sent either by the PaC
   or the PAA to terminate a PANA session.

         PANA-Termination-Request ::= < PANA-Header: 7, REQ >
                       < Session-Id >
                       < Termination-Cause >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.13  PANA-Termination-Answer (PTA)

   The PANA-Termination-Answer (PTA) message is sent either by the PaC
   or the PAA in response to PANA-Termination-Request.

         PANA-Termination-Answer ::= < PANA-Header: 7 >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.14  PANA-Error-Request (PER)

   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.

         PANA-Error-Request ::= < PANA-Header: 8, REQ >
                        < Session-Id >
                        < Result-Code >
                     *  [ Failed-AVP          |  0  |  0  |  0  |  0  |  0  |  0  | ]
                        [ Notification ]
                     *  [ AVP ]
                    0*1 < MAC >

7.2.15  PANA-Error-Answer (PEA)

   The PANA-Error-Answer (PEA) message is sent in response to a
   PANA-Error-Request.

         PANA-Error-Answer ::= < PANA-Header: 8 >
                        < Session-Id >
                        [ Notification ]
                     *  [ AVP ]
                    0*1 < MAC >

7.2.16  PANA-FirstAuth-End-Request (PFER)

   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
   when separate NAP and ISP authentication is performed.

         PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [, SEP] [, NAP] >
                       < Session-Id >
                       { Result-Code }
                       [ EAP-Payload ]
                       [ Key-Id ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.17  PANA-FirstAuth-End-Answer (PFEA)

   The PANA-FirstAuth-End-Answer (PFEA) message is sent by the PaC to
   the PAA in response to a PANA-FirstAuth-End-Request message.

         PANA-FirstAuth-End-Answer ::= < PANA-Header: 9, REQ [, SEP] [, NAP] >
                       < Session-Id >
                       [ Key-Id ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.18  PANA-Update-Request (PUR)

   The PANA-Update-Request (PUR) message is sent either by the PaC or
   the PAA to deliver attribute updates and notifications.  In the scope
   of this specification only the PaC IP address attribute can be
   updated via this mechanism.  An IP-Address AVP can only be included
   in the PUR messages sent by the PaC.  The PUR message can be used to
   deliver just a notification as well.

         PANA-Update-Request ::= < PANA-Header: 10, REQ >
                       < Session-Id >
                       [ IP-Address ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.2.19  PANA-Update-Answer (PUA)

   The PANA-Update-Answer (PUA) message is sent by the PAA to the PaC in
   response to a PANA-Update-Request.

         PANA-Update-Answer ::= < PANA-Header: 10 >
                       < Session-Id >
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < MAC >

7.3  AVPs in PANA

   PANA defines several AVPs that are specific to the protocol.  A
   number of others AVPs are reused.  These are specified in other
   documents such as [RFC3588].

   The following tables lists the AVPs used in this document, and
   specifies in which PANA messages they MAY, or MAY NOT be present.

   The table uses the following symbols:

   0  |
      ISP-Information     |     The AVP MUST NOT be present in the message.

   0+ | 0-1 |  0  |  0  |  0  |  0  |  0  |
      NAP-Information     | 0-1 |  0  |  0  |  0  |  0  |  0  |  0  |
      Key-Id              |  0  |  0  |  0  |  0  | 0-1 |    Zero or more instances of the AVP MAY be present in the
         message.

   0-1 |  0  |
      IP-Address          |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
      --------------------+-----+-----+-----+-----+-----+-----+-----+

                 Figure 11:   Zero or one instance of the AVP Occurrence Table (1/3)
                          +-------------------------------------+
                          |              Message                |
                          |               Type                  |
                          +-----+-----+-----+-----+------+------+
      Attribute Name      | PPR | PPA | PTR | PTA | PFER | PFEA |
      --------------------+-----+-----+-----+-----+------+------+
      Result-Code         |  0  |  0  |  0  |  0  |  1   |  0   |
      Session-Id          |  1  |  1  | MAY be present in the message.
         It is considered an error if there are more than one instance
         of the AVP.

   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
         message.

                          +---------------------------------------------+
                          |  1                  Message                    |  1
                          |  1                   Type                      |
      Termination-Cause
                          +---+---+---+---+---+----+----+---+---+---+---+
      Attribute Name      |PDI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA|
      --------------------+---+---+---+---+---+----+----+---+---+---+---+
      Cookie              | 0  | |0-1|0-1| 0 |  1 0 | 0  | 0  | 0 |
      EAP-Payload 0 | 0 | 0 |
      Device-Id           | 0 | 0 |  1 0 | 0 |
      MAC 0 | 0-1 0  | 0-1 0  | 0-1 0+|0-1| 0 | 0-1 0 | 0-1
      EAP-Payload         | 0-1 0 |0-1|0-1| 1 |0-1| 0  |
      Nonce 0  |0-1| 0 | 0 | 0 |
      Failed-AVP          | 0 | 0 | 0 | 0 |
      Device-Id 0 | 0  | 0  | 0 | 0 | 0 | 0 |
      Cookie
      IP-Address          | 0 | 0 | 0 | 0 | 0 | 0  |
      Protection-Cap. 0  | 1 | 0 | 0 | 0 |
      ISP-Information     | 0 | 0+|0-1| 0 | 0 |
      PPAC 0  | 0  | 0 | 0 | 0 | 0 |
      Key-Id              | 0 |
      Session-Lifetime 0 | 0 | 0 | 0 | 0  | 0  |0-1|0-1| 0 | 0 |
      Failed-AVP
      MAC                 | 0 | 0 | 0 |0-1|0-1|0-1 |0-1 |0-1|0-1|0-1|0-1|
      NAP-Information     | 0 |0-1| 0 | 0 | 0 |
      ISP-Information 0  | 0  | 0 | 0 | 0 | 0 |
      Nonce               | 0 |
      NAP-Information 1 | 1 | 0 | 0 | 0  | 0  | 0 | 0 |
      Key-Id 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|
      PPAC                | 0 |0-1| 0 | 0 | 0 | 0-1 0  | 0-1 0  |
      IP-Address 1 |0-1| 0 | 0 |
      Protection-Cap.     | 0 |0-1| 0 | 0 | 0 | 0  | 0  |0-1| 0 |
      --------------------+-----+-----+-----+-----+------+------+

                 Figure 12: AVP Occurrence Table (2/3)
                          +-------------------------------------+ 0 |               Message 0 |
      Result-Code         |                Type 0 |
                          +-----+-----+-----+-----+------+------+
      Attribute Name 0 | PUR 0 | PUA 0 | PER 0 | PEA 0  | PRAR 0  | PRAA 1 |
      --------------------+-----+-----+-----+-----+------+------+
      Result-Code 0 | 0 | 0 |  1
      Session-Id          | 0 | 0 | 0 |
      Session-Id 1 | 1 | 1  | 1  | 1 | 1 | 1 |
      Termination-Cause 1 |
      Session-Lifetime    | 0 | 0 | 0 | 0 | 0 | 0  |
      EAP-Payload 0  |0-1| 0 | 0 | 0 |
      Termination-Cause   | 0 | 0 | 0 | 0 |
      MAC 0 | 0-1 0  | 0-1 0  | 0-1 0 | 0-1 0 | 0-1 0 | 0-1 0 |
      --------------------+---+---+---+---+---+----+----+---+---+---+---+

                 Figure 10: AVP Occurrence Table (1/2)
                          +---------------------------------+
                          |              Message            |
      Nonce
                          |               Type              |
                          +---+---+---+---+----+----+---+---+
      Attribute Name      |PTR|PTA|PER|PEA|PFER|PFEA|PUR|PUA|
      --------------------+---+---+---+---+----+----+---+---+
      Cookie              | 0 | 0 | 0 | 0 | 0  | 0  | 0 | 0 |
      Device-Id           | 0 | 0 | 0 | 0 | 0  | 0  |
      Cookie 0 | 0 |
      EAP-Payload         | 0 | 0 | 0 | 0 |0-1 | 0  |
      Protection-Cap. 0 | 0 |
      Failed-AVP          | 0 | 0 | 0+| 0 | 0  | 0  |
      PPAC 0 | 0 |
      IP-Address          | 0 | 0 | 0 | 0 | 0  |
      Session-Lifetime 0  |0-1| 0 |
      ISP-Information     | 0 | 0 | 0 | 0 | 0  | 0  |
      Failed-AVP 0 | 0 |
      Key-Id              | 0 |  1 0 | 0 | 0 |0-1 |0-1 | 0 |
      ISP-Information 0 |
      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  |
      NAP-Information 0 | 0 |
      Nonce               | 0 | 0 | 0 | 0 | 0  |
      Key-Id 0  | 0 | 0 |
      Notification        |0-1|0-1|0-1|0-1|0-1 |0-1 |0-1|0-1|
      PPAC                | 0 | 0 | 0 | 0 |
      IP-Address 0  |  1 0  | 0 | 0 |
      Protection-Cap.     | 0 | 0 | 0 | 0 | 0  | 0  |
      --------------------+-----+-----+-----+-----+------+------+

                 Figure 13: AVP Occurrence Table (3/3)

8.3.1  MAC AVP

   The first octet (8 bits) of the MAC (AVP Code 1) AVP data contains
   the MAC algorithm type.  Rest of the AVP data payload contains the
   MAC encoded in network byte order.  The 8-bit Algorithm name space is
   managed by IANA [ianaweb].  The AVP length varies depending on the
   used algorithm. 0                   1                   2                   3 | 0 1 2 3 4 5 6 7 8 9 |
      Result-Code         | 0 | 0 | 1 2 3 4 5 6 7 8 9 | 0 | 1 2 3 4 5 6 7 8 9  | 0  | 0 | 0 |
      Session-Id          | 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   Algorithm 1 |           MAC...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Algorithm 1           HMAC-SHA1 (20 bytes)
   MAC

      The Message Authentication Code is encoded in network byte order.

8.3.2  Device-Id AVP

   The Device-Id AVP (AVP Code 2) is of Address type [RFC3588].  IPv4
   and IPv6 addresses are encoded as specified in [RFC3588].  The
   content and format of data (including byte and bit ordering) for
   link-layer addresses is expected to be specified in specific
   documents that describe how IP operates over different link-layers.
   For instance, [RFC2464].  Address families other than that are
   defined for link-layer or IP addresses MUST NOT be used for this AVP.

8.3.3  Session-Id AVP

   All messages pertaining to a specific PANA session MUST include a
   Session-Id AVP (AVP Code 3) which carries a PAA-assigned fix value
   throughout the lifetime of a session.  When present, the Session-Id
   SHOULD appear immediately following the PANA header.

   The Session-Id MUST be globally and eternally unique, as it is meant
   to identify a PANA Session without reference to any other
   information, and may be needed to correlate historical authentication
   information with accounting information.  The PANA Session-Id AVP has
   the same format as the Diameter Session-Id | 1 | 1  | 1  | 1 | 1 |
      Session-Lifetime    | 0 | 0 | 0 | 0 | 0  | 0  | 0 | 0 |
      Termination-Cause   | 1 | 0 | 0 | 0 | 0  | 0  | 0 | 0 |
      --------------------+---+---+---+---+----+----+---+---+

                 Figure 11: AVP [RFC3588].

8.3.4 Occurrence Table (2/2)

7.3.1  Cookie AVP

   The Cookie AVP (AVP Code 4) is of type OctetString.  The data is
   opaque and the exact content 1) is outside used for carrying a random value
   generated by the scope of this protocol.

8.3.5  Protection-Capability AVP PAA.  The Protection-Capability AVP (AVP Code 5) data is of type Unsigned32. OctetString.  The AVP data indicates the cryptographic data protection capability
   supported
   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 EPs.  Below is PAA to generate a list of cookie does
   not affect interoperability and not specified data protection
   capabilities:

         0          L2_PROTECTION
         1          IPSEC_PROTECTION

8.3.6  Termination-Cause in this document.  An
   example cookie generation algorithm is shown in Section 4.2.

7.3.2  Device-Id AVP

   The Termination-Cause Device-Id AVP (AVP Code 6) 2) is used for carrying device
   identifiers of type of type Enumerated, PaC and is used to indicate the reason why a session was terminated on
   the access device. EP(s).  The AVP data is used as a collection of flags The
   following Termination-Cause AVP defined in [RFC3588] Address type
   [RFC3588].  IPv4 and IPv6 addresses are used for
   PANA.

   LOGOUT                   1  (PaC -> PAA)

      The client initiated a disconnect

   ADMINISTRATIVE           4  (PAA -> PaC)

      The client was not granted access, or was disconnected, due to
      administrative reasons, such encoded as the receipt of a
      Abort-Session-Request message.

   SESSION_TIMEOUT          8  (PAA -> PaC) specified in
   [RFC3588].  The session has timed out, content and service has been terminated.

8.3.7  Result-Code format of data (including byte and bit
   ordering) for link-layer addresses is expected to be specified in
   specific documents that describe how IP operates over different
   link-layers.  For instance, [RFC2464].  Address families other than
   that are defined for link-layer or IP addresses MUST NOT be used for
   this AVP.

7.3.3  EAP-Payload AVP

   The Result-Code EAP-Payload AVP (AVP Code 7) 3) is of type Unsigned32 and indicates
   whether an EAP authentication was completed successfully or whether
   an error occurred.  Here are Result-Code AVP values taken from
   [RFC3588] and adapted used for PANA.

8.3.7.1  Authentication Results Codes

   These result code values inform the PaC about encapsulating the authentication and
   authorization result.  The authentication result and authorization
   result can be different as described below, but only one result actual
   EAP message that
   corresponds to the one detected first is returned.

   PANA_SUCCESS                            2001

      Both being exchanged between the authentication EAP peer and authorization processes are
      successful.

   PANA_AUTHENTICATION_REJECTED            4001 the EAP
   authenticator.  The authentication process failed.  When this error AVP data is returned,
      the authorization process also fails.

   PANA_AUTHORIZATION_REJECTED             5003 of type OctetString.

7.3.4  Failed-AVP AVP

   The authorization process failed.  This error could occur when
      authorization Failed-AVP AVP (AVP Code 4) provides debugging information in
   cases where a request is rejected by a AAA proxy or rejected locally by not fully processed due to
   erroneous information in a
      PAA, even if specific AVP.  The AVP data is of type
   Grouped.  The format of the Failed-AVP AVP is defined in [RFC3588].

7.3.5  IP-Address AVP

   The IP-Address AVP (AVP Code 5) contains an IP address of the authentication procedure succeeds.

8.3.7.2  Protocol Error Result Codes

   Protocol error result code values.

   PANA_MESSAGE_UNSUPPORTED                3001

      Error code from PAA to PaC or from PaC to
   PAA.  Message type not
      recognized or supported.

   PANA_UNABLE_TO_DELIVER                  3002

      Error code from PAA to PaC.  PAA was unable  When it is sent by the PaC, it is used to deliver convey the EAP
      payload new IP
   address of the PaC to the authentication server.

   PANA_INVALID_HDR_BITS                   3008

      Error code from PAA to PaC or from when the PaC to PAA.  A message was
      received whose bits in reconfigures its IP
   address after the successful PANA header were either set to an
      invalid combination, or to a value that authentication.  This AVP is inconsistent with not
   used if the PaC's IP address used during the authentication and
   authorization phase is still valid.  It is sent by the
      message type's definition.

   PANA_INVALID_AVP_BITS                   3009

      Error code from PAA in
   PANA-Bind-Request to PaC or from PaC bind the IP address of the PAA to PAA.  A message was
      received that included an the PANA
   session.  The payload format of the IP-Address AVP whose flag bits are set to an
      unrecognized value, or that is inconsistent with the AVP's
      definition.

   PANA_AVP_UNSUPPORTED                    5001

      Error code from PAA to PaC same as
   that of the Device-Id AVP (see See Section 7.3.2).  Address families
   for IPv4 or from PaC to PAA. IPv6 MUST be used for this AVP.

7.3.6  ISP-Information AVP

   The received
      message contained an ISP-Information AVP that is not recognized (AVP Code 6) contains zero or supported and
      was marked with one
   Provider-Identifier AVP which carries the Mandatory bit.  A PANA message with this error
      MUST contain identifier of the ISP and
   one or more Failed-AVP Provider-Name AVP containing which carries the AVPs that
      caused name of the failure.

   PANA_UNKNOWN_SESSION_ID                 5002

      Error code from PAA to PaC or from PaC to PAA. ISP.  The AVP
   data is of type Grouped, and it has the following ABNF grammar:

         ISP-Information ::= < AVP Header: 6 >
                    0*1 { Provider-Identifier }
                        { Provider-Name }
                     *  [ AVP ]

7.3.7  Key-Id AVP

   The message
      contained Key-Id AVP (AVP Code 7) is of type Integer32, and contains an unknown Session-Id.
   AAA-Key identifier.  The AAA-Key identifier is assigned by PAA and
   MUST NOT send this error
      result code value to PaC if PaC sent an unknown Session-Id in be unique within the
      PANA-Start-Answer message (session resumption).

   PANA_INVALID_AVP_VALUE                  5004
      Error code from PAA to PaC or from PaC to PAA. PANA session.

7.3.8  MAC AVP

   The message
      contained an MAC (Message Authentication Code) AVP with an invalid value in its data portion.  A is used to integrity
   protect PANA message indicating messages.  The first octet of the this error MUST include AVP (AVP Code 8)
   data contains the MAC algorithm type.  Rest of the offending AVPs
      within a Failed-AVP AVP.

   PANA_MISSING_AVP                        5005

      Error code from PAA to PaC or from PaC to PAA.  The message did
      not contain an AVP that data payload
   contains the MAC encoded in network byte order.  The 8-bit Algorithm
   name space is required managed by IANA [ianaweb].  The AVP length varies
   depending on the message type
      definition.  If this value used algorithm.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Algorithm   |           MAC...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Algorithm

         1           HMAC-SHA1 (20 bytes)

   MAC

      The Message Authentication Code is sent encoded in the Result-Code AVP, a
      Failed-AVP network byte order.

7.3.9  NAP-Information AVP SHOULD be included in the message.

   The Failed-AVP NAP-Information AVP MUST contain an example (AVP Code 9) contains zero or one
   Provider-Identifier AVP which carries the identifier of the missing NAP and
   one Provider-Name AVP complete with which carries the
      Vendor-Id if applicable.  The value field name of the missing NAP.  The AVP
      should be
   data is of correct minimum length type Grouped, and contain zeroes.

   PANA_RESOURCES_EXCEEDED                 5006

      Error code from PAA to PaC.  A message was received that cannot be
      authorized because the client it has already expended allowed
      resources.  An example of this error condition is the following ABNF grammar:

         NAP-Information ::= < AVP Header: 9 >
                    0*1 { Provider-Identifier }
                        { Provider-Name }
                     *  [ AVP ]

7.3.10  Nonce AVP

   The Nonce AVP (AVP Code 10) carries a client randomly chosen value that is
      restricted to one PANA session
   used in cryptographic key computations.  The AVP data is of type
   OctetString and attempts to establish it contains a second
      session.

   PANA_CONTRADICTING_AVPS                 5007

      Error code from PAA to PaC.  The PAA has detected AVPs randomly generated value in the
      message that contradicted each other, opaque
   format.  The data length MUST be between 8 and 256 bytes inclusive.

7.3.11  Notification AVP

   The Notification AVP (AVP Code 11) is not willing to
      provide service optionally used to convey a
   displayable message sent by either the client.  One PaC or more Failed-AVP AVPs MUST
      be present, containing the AVPs that contradicted each other.

   PANA_AVP_NOT_ALLOWED                    5008

      Error code from PAA to PaC PAA.  It can be
   included in any message, whether it is a request or from PaC answer.  In case
   a notification needs to PAA.  A be sent but there is no outgoing PANA message was
      received with an AVP
   to deliver this AVP, a PANA-Update-Request that MUST NOT only carries a
   Notification AVP SHOULD be present.  The Failed-AVP generated.

   Receipt this AVP does not change PANA state.

   AVP
      MUST be included data is of type OctetString and contain a copy it contains UTF-8 encoded ISO
   10646 characters [RFC2279].  The length of the offending AVP.

   PANA_AVP_OCCURS_TOO_MANY_TIMES          5009

      Error code from PAA to PaC or from PaC to PAA.  A displayable message was
      received that included an AVP that appeared more often than
      permitted in is
   determined by the message definition.  The Failed-AVP AVP Length field.  The message MUST NOT be
      included and contain a copy of null
   terminated.

7.3.12  Post-PANA-Address-Configuration (PPAC) AVP

   The PPAC AVP (AVP Code 12) is used for conveying the first instance available types
   of post-PANA IP address configuration mechanisms when sent by the offending
      AVP that exceeded
   PAA, and the maximum number of occurrences.

   PANA_UNSUPPORTED_VERSION                5011
      Error code from PAA to PaC or from PaC to PAA.  This error is
      returned chosen one when a message was received, whose version number is
      unsupported.

   PANA_UNABLE_TO_COMPLY                   5012

      This error sent by the PaC.  Each possible
   mechanisms is returned when represented by a request is rejected for unspecified
      reasons.  For example, flag.  At least one or more of the
   flags MUST be set when an EAP authentication fails at an EAP
      pass-through authenticator without passing an EAP-Failure message
      to sent by the PAA, a Result-Code and exactly one flag MUST be
   set when sent by the PaC.  The AVP with this error code data is carried in
      PANA-Error-Request message.

   PANA_INVALID_AVP_LENGTH                 5014

      Error code from PAA to of type Unsigned32.

   The format of the AVP data is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |N|D|A|T|I|                   Reserved                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PPAC Flags

      N (No configuration)

         The PaC does not have to (if sent by PAA) or from will not (if sent
         by PaC) configure a new IP address after PANA.

      D (DHCP)

         The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP
         [RFC2131][RFC3315] to PAA. configure a new IP address after PANA.

      A (stateless autoconfiguration)

         The message
      contained an AVP PaC can/will use stateless IPv6 address autoconfiguration
         [RFC2462] to configure a new IP address after PANA.

      T (DHCP with an invalid length. IPsec tunnel mode)

         The PANA-Error message
      indicating this error MUST include the offending AVPs within a
      Failed-AVP AVP.

   PANA_INVALID_MESSAGE_LENGTH             5015

      Error code from PAA to PaC or from PaC can/will use [RFC3456] to PAA.  This error is
      returned when configure a message is received with an invalid message
      length.

   PANA_PROTECTION_CAPABILITY_UNSUPPORTED  5016

      Error code from new IP address
         after PANA.

      I (IKEv2)

         The PaC can/will use [I-D.ietf-ipsec-ikev2] to PAA.  This error configure a new
         IP address after PANA.

      Reserved

         These flag bits are reserved for future use, and MUST be set to
         zero, and ignored by the receiver.

   Unless the N-flag is returned when set, the PaC
      receives MUST configure a PANA-Bind-Request with new IP address
   using one of the methods indicated by the other flags.  Refer to
   [I-D.ietf-pana-framework] for a detailed discussion on when these
   methods can be used.

7.3.13  Protection-Capability AVP and
      a valid MAC

   The Protection-Capability AVP but does not support (AVP Code 13) indicates the
   cryptographic data protection capability
      specified in supported and required by
   the Protection-Capability AVP.

   PANA_PPAC_CAPABILITY_UNSUPPORTED  5017

      Error code from PaC to PAA.  This error EPs.  The AVP data is of type Unsigned32.  Below is returned in a
      PANA-Bind-Answer message when there is no match between the list of PPAC methods offered by the PAA
   valid data values and the ones available on the
      PaC.

   PANA_INVALID_IP_ADDRESS  5018

      Error code from PAA to PaC.  This error associated protection capabilities:

         0          L2_PROTECTION
         1          IPSEC_PROTECTION

7.3.14  Provider-Identifier AVP

   The Provider-Identifier AVP (AVP Code 14) is returned of type Unsigned32, and
   contains an IANA assigned "SMI Network Management Private Enterprise
   Codes" [ianaweb] value, encoded in a
      PANA-Error-Request message when the IP-Address network byte order.

7.3.15  Provider-Name AVP in the received
      PANA-Update-Request message

   The Provider-Name AVP (AVP Code 15) is invalid (e.g., a non-unicast
      address).

8.3.8  EAP-Payload of type UTF8String, and
   contains the UTF8-encoded name of the provider.

7.3.16  Result-Code AVP

   The EAP-Payload Result-Code AVP (AVP Code 8) 16) is of type OctetString Unsigned32 and indicates
   whether an EAP authentication was completed successfully or whether
   an error occurred.  Here are Result-Code AVP values taken from
   [RFC3588] and adapted for PANA.

7.3.16.1  Authentication Results Codes

   These result code values inform the PaC about the authentication and
   authorization result.  The authentication result and authorization
   result can be different as described below, but only one result is used
   returned to encapsulate the actual EAP packet PaC.  These codes are used with PANA-Bind-Request and
   PANA-FirstAuth-End-Request messages.

   PANA_SUCCESS                            2001

      Both authentication and authorization processes are successful.

   PANA_AUTHENTICATION_REJECTED            4001

      Authentication has failed.  When this error is returned, it is
      assumed that authorization is being exchanged between automatically failed.

   PANA_AUTHORIZATION_REJECTED             5003

      The authorization process has failed.  This error could occur when
      authorization is rejected by a AAA server or rejected locally by a
      PAA, even if the authentication procedure has succeeded.

7.3.16.2  Protocol Error Result Codes

   These codes are used with PANA-Error-Request messages.  Unless stated
   otherwise, they can be generated by both the EAP peer PaC and the EAP authenticator.

8.3.9  Session-Lifetime AVP

   The Session-Lifetime AVP (AVP Code 9) data is of PAA.

   PANA_MESSAGE_UNSUPPORTED                3001

      Message type Unsigned32.  It
   contains not recognized or supported.

   PANA_UNABLE_TO_DELIVER                  3002

      The PAA was unable to deliver the number of seconds remaining before EAP payload to the current session
   is considered expired.

8.3.10  Failed-AVP AVP

   The Failed-AVP AVP (AVP Code 10) is of type Grouped and provides
   debugging information
      authentication server.  Only the PAA can generate this code.

   PANA_INVALID_HDR_BITS                   3008

      A message was received whose bits in cases where a request is rejected the PANA header were either
      set to an invalid combination, or not
   fully processed due to erroneous information in a specific AVP.  The
   format of the Failed-AVP AVP is defined in [RFC3588].

8.3.11  NAP-Information AVP

   The NAP-Information AVP (AVP Code 11) value that is of type Grouped, and
   contains zero or one Provider-Identifier AVP which carries the
   identifier of inconsistent
      with the NAP and one Provider-Name message type definition.

   PANA_INVALID_AVP_FLAGS                   3009
      A message was received that included an AVP which carries the
   name of the NAP.  Its Data field has whose flag bits are
      set to an unrecognized value, or that is inconsistent with the following ABNF grammar:

         NAP-Information ::= < AVP Header: 11 >
                    0*1 { Provider-Identifier }
                        { Provider-Name }
                     *  [ AVP ]

8.3.12  ISP-Information AVP
      AVP's definition.

   PANA_AVP_UNSUPPORTED                    5001

      The ISP-Information received message contained an AVP (AVP Code 12) that is of type Grouped, and
   contains zero not recognized or one Provider-Identifier AVP which carries the
   identifier of the ISP
      supported and was marked with the Mandatory bit.  A PANA message
      with this error MUST contain one Provider-Name or more Failed-AVP AVP which carries containing
      the
   name of AVPs that caused the ISP.  Its Data field has failure.

   PANA_UNKNOWN_SESSION_ID                 5002

      The message contained an unknown Session-Id.  A PANA message
      indicating this error MUST include the following ABNF grammar:

         ISP-Information ::= < AVP Header: 12 >
                    0*1 { Provider-Identifier }
                        { Provider-Name }
                     *  [ AVP ]

8.3.13  Provider-Identifier unknown Session-Id AVP
      within a Failed-AVP AVP.

   PANA_INVALID_AVP_DATA                   5004

      The Provider-Identifier message contained an AVP (AVP Code 13) is of type Unsigned32, and
   contains with an IANA assigned "SMI Network Management Private Enterprise
   Codes" [ianaweb] value, encoded invalid value in network byte order.

8.3.14  Provider-Name AVP its data
      portion.  A PANA message indicating this error MUST include the
      offending AVPs within a Failed-AVP AVP.

   PANA_MISSING_AVP                        5005

      The Provider-Name message did not contain an AVP (AVP Code 14) that is of type UTF8String, and
   contains required by the UTF8-encoded name of message
      type definition.  If this value is sent in the provider.

8.3.15  Key-Id Result-Code AVP, a
      Failed-AVP AVP SHOULD be included in the message.  The Key-Id Failed-AVP
      AVP (AVP Code 15) is of type Integer32, and contains an
   AAA-Key identifier.  The AAA-Key identifier is assigned by PAA and MUST be unique within contain an example of the PANA session.

8.3.16  Post-PANA-Address-Configuration (PPAC) missing AVP complete with the
      Vendor-Id if applicable.  The data value field of PPAC the missing AVP (AVP Code 16) is
      should be of type Unsigned32. correct minimum length and contain zeroes.

   PANA_RESOURCES_EXCEEDED                 5006

      A message was received that cannot be authorized because the
      client has already expended allowed resources.  An example of this
      error condition is a client that is restricted to one PANA session
      and attempts to establish a second session.  Only the PAA can
      generate this code.

   PANA_CONTRADICTING_AVPS                 5007

      The
   AVP data PAA has detected AVPs in the message that contradicted each
      other, and is used not willing to carry a set of flags which maps provide service to various IP
   address configuration methods.  When sent by the PAA, client.  One
      or more Failed-AVP AVPs MUST be present, containing the AVPs that
      contradicted each other.  Only the PAA can generate this code.

   PANA_AVP_NOT_ALLOWED                    5008

      A message was received with an AVP that MUST
   have at least one NOT be present.  The
      Failed-AVP AVP MUST be included and contain a copy of the flags set, and MAY have
      offending AVP.

   PANA_AVP_OCCURS_TOO_MANY_TIMES          5009

      A message was received that included an AVP that appeared more
      often than one set.
   When sent by the PaC, only one of permitted in the flags message definition.  The Failed-AVP
      AVP MUST be set.

   The format included and contain a copy of the first instance of
      the offending AVP data that exceeded the maximum number of occurrences.

   PANA_UNSUPPORTED_VERSION                5011

      This error is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |N|D|A|T|I|                   Reserved                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PPAC Flags

      N (No configuration)

         The PaC does not have to (if sent by PAA) or will not (if sent
         by PaC) configure returned when a new IP address after PANA.

      D (DHCP)

         The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP
         [RFC2131][RFC3315] to configure message was received, whose version
      number is unsupported.

   PANA_UNABLE_TO_COMPLY                   5012

      This error is returned when a new IP address after PANA.

      A (stateless autoconfiguration)

         The PaC can/will use stateless IPv6 address autoconfiguration
         [RFC2462] request is rejected for unspecified
      reasons.  For example, when an EAP authentication fails at an EAP
      pass-through authenticator without passing an EAP Failure message
      to configure the PAA, a new IP address after PANA.

      T (DHCP Result-Code AVP with IPsec tunnel mode) this error code is carried in
      the PANA-Error-Request message.

   PANA_INVALID_AVP_LENGTH                 5014

      The PaC can/will use [RFC3456] to configure a new IP address
         after PANA.

      I (IKEv2) message contained an AVP with an invalid length.  The
      PANA-Error-Request message indicating this error MUST include the
      offending AVPs within a Failed-AVP AVP.

   PANA_INVALID_MESSAGE_LENGTH             5015

      This error is returned when a message is received with an invalid
      message length.

   PANA_PROTECTION_CAPABILITY_UNSUPPORTED  5016

      This error is returned when the PaC can/will use [I-D.ietf-ipsec-ikev2] to configure receives a new
         IP address after PANA.

      Reserved

         These flag bits are reserved for future use, and MUST be set to
         zero, PANA-Bind-Request
      message with a Protection-Capability AVP and ignored by a valid MAC AVP but
      does not support the receiver.

   Unless protection capability specified in the N-flag is set,
      Protection-Capability AVP.  Only the PaC MUST configure a new IP address
   using one of can generate this code.

   PANA_PPAC_CAPABILITY_UNSUPPORTED  5017
      This error is returned when there is no match between the list of
      PPAC methods indicated offered by the other flags.  Refer to
   [I-D.ietf-pana-framework] for a detailed discussion PAA and the ones available on the PaC.
      Only the PaC can generate this code.

   PANA_INVALID_IP_ADDRESS  5018

      This error is returned in a PANA-Error-Request message when these
   methods the
      IP-Address AVP in the received PANA-Update-Request message is
      invalid (e.g., a non-unicast address).  Only the PAA can be used.

8.3.17  Nonce generate
      this code.

7.3.17  Session-Id AVP

   The Nonce

   All messages pertaining to a specific PANA session MUST include a
   Session-Id AVP (AVP Code 17) is of type OctetString.  The data
   contains which carries a randomly generated PAA-assigned fixed
   session identifier value in opaque format. throughout the lifetime of a session.  When
   present, the Session-Id AVP SHOULD appear immediately following the
   PANA header.

   The data
   length Session-Id MUST be between 8 globally and 256 bytes inclusive.

8.3.18  IP-Address eternally unique, as it is meant
   to identify a PANA session without reference to any other
   information, and may be needed to correlate historical authentication
   information with accounting information.  The PANA Session-Id AVP has
   the same format as the Diameter Session-Id AVP [RFC3588].

7.3.18  Session-Lifetime AVP

   The IP-Address Session-Lifetime AVP (AVP Code 18) contains an IP address the number of n a PaC or
   PAA. seconds
   remaining before the current session is considered expired.  The payload format AVP
   data is of the IP-Address type Unsigned32.

7.3.19  Termination-Cause AVP

   The Termination-Cause AVP (AVP Code 19) is used for indicating the same as that of
   reason why a session is terminated by the Device-Id requester.  The AVP (see See Section 8.3.2).  Address families for IPv4
   or IPv6 MUST be data is
   of type Enumerated.  The following Termination-Cause data values are
   used for this AVP.  Address families for IPv4 with PANA.

   LOGOUT                   1  (PaC -> PAA)

      The client initiated a disconnect

   ADMINISTRATIVE           4  (PAA -> PaC)

      The client was not granted access, or IPv6
   MUST be used for this AVP.

9.  PANA Protocol Message Retransmissions was disconnected, due to
      administrative reasons.

   SESSION_TIMEOUT          8  (PAA -> PaC)

      The session has timed out, and service has been terminated.

8.  Retransmission Timers

   The PANA protocol provides retransmissions for the PANA-PAA-Discover
   message and all request messages.

   The rule is that messages, with the sender of exception that the request
   PANA-Start-Answer message retransmits the
   request if the corresponding answer is not received in time.  Answer
   messages are sent as answers to retransmitted instead of the request messages, not based on a
   timer.

   PaC MUST retransmit PANA-PAA-Discover if a subsequent
   PANA-Start-Request is not received message in time.  Even though a
   PANA-Start-Request is received, PANA-PAA-Discover may still have to
   be retransmitted.  This is because a stateless PANA handshake
   requires one time transmission of a PANA-Start-Request. PAA MUST NOT
   start a timer and retransmit the request if it wants to avoid state
   creation.  If the received PANA-Start-Request included a Cookie AVP
   (an indication of stateless handshake), PaC MUST retransmit
   PANA-PAA-Discover until the first PANA-Auth-Request is received. discovery.

   PANA retransmission timers are based on the model used in DHCPv6
   [RFC3315].  Variables used here are also borrowed from this
   specification.  PANA is a request response like protocol.  The
   message exchange terminates when either the request sender
   successfully receives the appropriate answer, or when the message
   exchange is considered to have failed according to the retransmission
   mechanism described below.

   The retransmission behavior is controlled and described by the
   following variables:

         RT     Retransmission timeout

         IRT    Initial retransmission time

         MRC    Maximum retransmission count

         MRT    Maximum retransmission time

         MRD    Maximum retransmission duration

         RAND   Randomization factor

   With each message transmission or retransmission, the sender sets RT
   according to the rules given below.  If RT expires before the message
   exchange terminates, the sender recomputes RT and retransmits the
   message.

   Each of the computations of a new RT include a randomization factor
   (RAND), which is a random number chosen with a uniform distribution
   between -0.1 and +0.1.  The randomization factor is included to
   minimize synchronization of messages.

   The algorithm for choosing a random number does not need to be
   cryptographically sound.  The algorithm SHOULD produce a different
   sequence of random numbers from each invocation.

   RT for the first message transmission is based on IRT:

         RT = IRT + RAND*IRT
   RT for each subsequent message transmission is based on the previous
   value of RT:

         RT = 2*RTprev + RAND*RTprev

   MRT specifies an upper bound on the value of RT (disregarding the
   randomization added by the use of RAND).  If MRT has a value of 0,
   there is no upper limit on the value of RT.  Otherwise:

         if (RT > MRT)
            RT = MRT + RAND*MRT

   MRC specifies an upper bound on the number of times a sender may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the sender has transmitted the message MRC times.

   MRD specifies an upper bound on the length of time a sender may
   retransmit a message.  Unless MRD is zero, the message exchange fails
   once MRD seconds have elapsed since the client first transmitted the
   message.

   If both MRC and MRD are non-zero, the message exchange fails whenever
   either of the conditions specified in the previous two paragraphs are
   met.

   If both MRC and MRD are zero, the client continues to transmit the
   message until it receives a response.

9.1

8.1  Transmission and Retransmission Parameters

   This section presents a table of values used to describe the message
   retransmission behavior of PANA requests and answers that are
   retransmitted (REQ_*) and PANA-PAA-Discover message (PDI_*).  The
   table shows default values.

           Parameter       Default   Description
           ------------------------------------------------
           PDI_IRT           1 sec   Initial PDI timeout.
           PDI_MRT         120 secs  Max PDI timeout value.
           PDI_MRC           0       Configurable.
           PDI_MRD           0       Configurable.

           REQ_IRT           1 sec   Initial Request timeout.
           REQ_MRT          30 secs  Max Request timeout value.
           REQ_MRC          10       Max Request retry attempts.
           REQ_MRD           0       Configurable.

   So for example the first RT for the PBR message is calculated using
   REQ_IRT as the IRT:

           RT = REQ_IRT + RAND*REQ_IRT

10.

9.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the PANA
   protocol, in accordance with BCP 26 [IANA].  The following policies
   are used here with the meanings defined in BCP 26: "Private Use",
   "First Come First Served", "Expert Review", "Specification Required",
   "IETF Consensus", "Standards Action".

   This section explains the criteria to be used by the IANA for
   assignment of numbers within namespaces defined within this document.

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  For Designated Expert with Specification
   Required, the request is posted to the PANA WG mailing list (or, if
   it has been disbanded, a successor designated by the Area Director)
   for comment and review, and MUST include a pointer to a public
   specification.  Before a period of 30 days has passed, the Designated
   Expert will either approve or deny the registration request and
   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,
   in the cases where it is possible, concrete suggestions on how the
   request can be modified so as to become acceptable.

10.1

9.1  PANA UDP Port Number

   PANA uses one well-known UDP port number (Section 5.2, 5.1, Section 4.1 4.2
   and Section 7.1, 6.1), which needs to be assigned by the IANA.

10.2

9.2  PANA Multicast Address

   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
   well-known IPv6 link-local scoped multicast address (Section 4.1 4.2 and
   Section 7.1), 6.1), which need to be assigned by the IANA.

10.3

9.3  PANA Header

   As defined in Section 7.2, 6.2, the PANA header contains two fields that
   requires IANA namespace management; the Message Type and Flags field.

10.3.1

9.3.1  Message Type

   The Message Type namespace is used to identify PANA messages.  Values
   0-65,533 are for permanent, standard message types, allocated by IETF
   Consensus [IANA].  This document defines the Message Types 1-10.  See
   Section 8.2.1 7.2.1 through Section 8.2.19 7.2.19 for the assignment of the
   namespace in this specification.

   The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are
   reserved for experimental messages.  As these codes are only for
   experimental and testing purposes, no guarantee is made for
   interoperability between the communicating PaC and PAA using
   experimental commands, as outlined in [IANA-EXP].

10.3.2

9.3.2  Flags

   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
   ('N'AP Authentication).  The remaining bits MUST only be assigned via
   a Standards Action [IANA].

10.4

9.4  AVP Header

   As defined in Section 7.3, 6.3, the AVP header contains three fields that
   requires IANA namespace management; the AVP Code, AVP Flags and
   Vendor-Id fields where only the AVP Code and AVP Flags create new
   namespaces.

10.4.1

9.4.1  AVP Code

   The AVP Code namespace is used to identify attributes.  There are
   multiple namespaces.  Vendors can have their own AVP Codes namespace
   which will be identified by their Vendor-ID (also known as
   Enterprise-Number) and they control the assignments of their
   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
   controlled AVP Codes namespace.  The AVP Codes and sometimes also
   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. 1-19.
   See Section 8.3.1 7.3.8 through Section 8.3.18 7.3.5 for the assignment of the
   namespace in this specification.

   AVPs may be allocated following Designated Expert with Specification
   Required [IANA].  Release of blocks of AVPs (more than 3 at a time
   for a given purpose) should require IETF Consensus.

   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.
   Vendor-Specific AVPs codes are for Private Use and should be
   encouraged instead of allocation of global attribute types, for
   functions specific only to one vendor's implementation of PANA, where
   no interoperability is deemed useful.  Where a Vendor-Specific AVP is
   implemented by more than one vendor, allocation of global AVPs should
   be encouraged instead.

10.4.2

9.4.2  Flags

   There are 16 bits in the AVP Flags field of the AVP header, defined
   in Section 7.3. 6.3.  This document assigns bit 0 ('V'endor Specific) and
   bit 1 ('M'andatory).  The remaining bits should only be assigned via
   a Standards Action .

10.5

9.5  AVP Values

   Certain AVPs in PANA define a list of values with various meanings.
   For attributes other than those specified in this section, adding
   additional values to the list can be done on a First Come, First
   Served basis by IANA [IANA].

10.5.1

9.5.1  Algorithm Values of MAC AVP

   As defined in Section 8.3.1, 7.3.8, the Algorithm field of MAC AVP (AVP Code
   1)
   8) defines the value of 1 (one) for HMAC-SHA1.

   All remaining values are available for assignment via IETF Consensus
   [IANA].

10.5.2  Protection-Capability

9.5.2  Post-PANA-Address-Configuration AVP Values

   As defined in Section 8.3.5, 7.3.12, the Protection-Capability Post-PANA-Address-Configuration AVP
   (AVP Code
   5) 12) defines the values bits 0 ('N': no configuration), 1 ('D':
   DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with IPsec
   tunnel mode) and 1. 4 ('I': IKEv2).

   All remaining values are available for assignment via a Standards
   Action [IANA].

10.5.3  Termination-Cause

9.5.3  Protection-Capability AVP Values

   As defined in Section 8.3.6, 7.3.13, the Termination-Cause Protection-Capability AVP (AVP Code 6)
   13) defines the values 1, 4 0 and 8. 1.

   All remaining values are available for assignment via IETF Consensus a Standards
   Action [IANA].

10.5.4

9.5.4  Result-Code AVP Values

   As defined in Section 8.3.7.1 7.3.16.1 and Section 8.3.7.2 7.3.16.2 the Result-Code
   AVP (AVP Code 7) 16) defines the values 2001, 3001-3002, 3008-3009,
   4001, 5001-5009 and 5011-5019.

   All remaining values are available for assignment via IETF Consensus
   [IANA].

10.5.5  Post-PANA-Address-Configuration

9.5.5  Termination-Cause AVP Values

   As defined in Section 8.3.16, 7.3.19, the Post-PANA-Address-Configuration Termination-Cause AVP (AVP Code 17) 19)
   defines the bits 0 ('N': no configuration), 1 ('D':
   DHCP), 2 ('A' stateless autoconfiguration), 3 ('T': DHCP with IPsec
   tunnel mode) and values 1, 4 ('I': IKEv2). and 8.

   All remaining values are available for assignment via a Standards
   Action IETF Consensus
   [IANA].

11.

10.  Security Considerations

   The PANA protocol defines a UDP-based EAP encapsulation that runs
   between two IP-enabled nodes on the same IP link.  Various security
   threats that are relevant to a protocol of this nature are outlined
   in [I-D.ietf-pana-threats-eval].  Security considerations stemming
   from the use of EAP and EAP methods are discussed in [RFC3748].  This
   section provides a discussion on the security-related issues that are
   related to PANA framework and protocol design.

   An important element in assessing security of PANA design and
   deployment in a network is the presence of lower-layer (physical and
   link-layer) security.  In the context of this document, lower-layers
   are said to be secure if they can prevent eavesdropping and spoofing
   of packets.  Examples of such networks are physically-secured DSL
   networks and 3GPP2 networks with crytographically-secured cdma2000
   link-layer.  In these examples, the lower-layer security is enabled
   even before running the first PANA-based authentication.  In the
   absence of such a pre-established secure channel, one needs to be
   created in conjunction with PANA using a link-layer or network-layer
   cryptographic mechanism (e.g., IPsec).

11.1

10.1  General Security Measures

   PANA provides multiple mechanisms to secure a PANA session.

   Since the PaC and PAA are on the same IP link, a simple TTL check on
   the received PANA messages prevents off-link attacks.

   PANA messages carry sequence numbers, which are monotonically
   incremented by 1 with every new request message.  These numbers are
   randomly initialized at the beginning of the session, and verified
   against expected numbers upon receipt.  A message whose sequence
   number is different than the expected one is silently discarded.  In
   addition to accomplishing orderly delivery of EAP messages and
   duplicate elimination, this scheme also helps prevent an adversary
   spoof messages to disturb ongoing PANA and EAP sessions unless it EAP sessions unless it can
   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
   also eavesdrop trigger transmission of the cached answer (i.e., no need
   to synchronize on process the expected sequence number. request and generate a new answer).

   The PANA framework defines EP which is ideally located on a network
   device that can filter traffic from the PaCs before the traffic
   enters the Internet. Internet/intranet.  A set of filters can be used to
   discard unauthorized packets, such as a PANA-Start-Request message
   that is received from the segment of the access network where only
   the PaCs are supposed to be connected.

   The protocol also provides authentication and integrity protection to
   PANA messages when the used EAP method can generate cryptographic
   session keys.  A PANA SA is generated based on the AAA-Key exported
   by the EAP method.  This SA is used for generating per-packet MAC to
   protect the PANA header and payload (including the complete EAP
   message).

   The cryptographic protection prevents an adversary from acting as a
   man-in-the-middle, injecting messages, replaying messages and
   modifying the content of the exchanged messages.  Any packet that
   fails to pass the MAC verification is silently discarded.  The
   earliest this protection can be enabled is when the very first
   PANA-Bind-Request or PANA-FirstAuth-End-Request message that signals
   a successful authentication is generated.  Starting with the PANA-Bind-Request and PANA-Bind-Answer, these
   messages, any subsequent PANA message until the session gets torn
   down can be cryptographically protected.

   The PANA SA enables authenticated and integrity protected exchange of
   the device ID information between the PaC and PAA.  This ensures
   there were no man-in-the-middle during the PANA authentication.

   The lifetime of the PANA SA is set to PANA session lifetime which is
   bounded by the AAA-authorized session lifetime with an additional granted by the authentication server.  An
   implementation MAY add a tolerance period. period to that value.  Unless the
   PANA state session is
   updated 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
   by the used EAP method, which is generally dictated by the deployment
   environment.  Insecure lower-layers necessitate use of key-generating
   EAP methods.  In networks where lower-layers are already secured,
   cryptographic protection of PANA messages is not necessary.

11.2

10.2  Discovery

   The discovery and handshake phase is vulnerable to spoofing attacks
   as these messages are not authenticated and integrity protected.  In
   order to prevent very basic denial-of service attacks an adversary
   should not be able to cause state creation by sending discovery
   messages to the PAA.  This protection is achieved by using a
   cookie-based scheme (similar to [RFC2522] which allows the responder
   (PAA) to be stateless in the first round of message exchange.  A
   return-routability test does not provide additional protection as
   PANA traffic is not routed but simply forwarded on-link.  It is
   difficult to prevent this threat entirely.

   In networks where lower-layers are not secured prior to running PANA,
   the capability discovery enabled through inclusion of
   Protection-Capability and Post-PANA-Address-Configuration AVPs in a
   PANA-Start-Request message is susceptible to spoofing leading to
   denial-of service attacks.  Therefore, usage of these AVPs during the
   discovery and handshake phase in such insecure networks is NOT
   RECOMMENDED.  The same AVPs are delivered via an integrity-protected
   PANA-Bind-Request upon successful authentication.

11.3

10.3  EAP Methods

   Eavesdropping EAP packets messages might cause problems when the EAP method
   is weak and enables dictionary or replay attacks or even allows an
   adversary to learn the long-term password directly.  Furthermore, if
   the optional EAP Identity Response/Identity payload is used then it allows the
   adversary to learn the identity of the PaC.  In such a case a privacy
   problem is prevalent.

   To prevent these threats, [I-D.ietf-pana-framework] suggests using
   proper EAP methods for particular environments.  Depending on the
   deployment environment an EAP authentication method which supports
   user identity confidentiality, protection against dictionary attacks
   and session key establishment must be used.  It is therefore the
   responsibility of the network operators and users to choose a proper
   EAP method.

11.4

10.4  Separate NAP and ISP Authentication

   The PANA design allows running two separate EAP sessions for the same
   PaC in a single the authentication and authorization phase: one with the NAP,
   and one with the ISP.  The process of arriving at the resultant
   authorization, which is a combination of the individual
   authorizations obtained from respective service providers, is outside
   the scope of this protocol.  In the absence of lower-layer security,
   both authentications MUST be able to generate a AAA-Key, leading to
   generation of a PANA SA.  The resultant PANA SA cryptographically
   binds the two AAA-Keys together, hence it prevents man-in-the-middle
   attacks.

11.5

10.5  Cryptographic Keys

   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
   is unique to the PANA session, and takes PANA-based nonce values into
   computation to cryptographically separate itself from the AAA-Key.

   The PANA_MAC_KEY is solely used for authentication and integrity
   protection of the PANA messages within the designated session.

   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
   the combination of both keys.

   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
   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
   enabled as a result of successful PANA authentication, a separate
   PaC-EP master key is generated based on the AAA-Key, session ID,
   identifier, key ID, identifier, and EP ID. device identifier.

   The lifetime of this PaC-EP master key is bounded by the lifetime of the
   PANA SA.  This key may be used with a secure association protocol
   [I-D.ietf-ipsec-ikev2] to produce further cipher-specific and
   transient keys.

11.6

10.6  Per-packet Ciphering

   Networks that are not secured at the lower-layers prior to running
   PANA can rely on enabling per-packet data traffic ciphering upon
   successful PANA session establishment.  The PANA framework allows
   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
   ciphering [I-D.ietf-pana-ipsec].  In case the master key is not
   readily useful to the ciphering mechanism, an additional secure
   association protocol [I-D.ietf-ipsec-ikev2] may be needed to produce
   the required keying material.  These mechanisms ultimately establish
   a cryptographic binding between the data traffic generated by and for
   a client and the authenticated identity of the client.  Data traffic
   must be minimally data origin authenticated, replay and integrity
   protected, and optionally encrypted.

11.7

10.7  PAA-to-EP Communication

   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 provisioning
   authorized PaC information on the EP.  This exchange MUST be always
   physically or cryptographically protected for authentication,
   integrity and replay protection.  It MUST also be privacy-protected
   when per-PaC PaC-EP master key for per-packet ciphering is transmitted to the
   EP.

   The per-packet ciphering PaC-EP master key MUST be unique to the PaC and EP pair.  The
   session ID identifier and EP's the device ID identifier of the EP are taken into
   computation for achieving this effect [I-D.ietf-pana-ipsec].
   Compromise of an EP does not automatically lead to compromise of
   another EP or the PAA.

11.8  Livenes

10.8  Liveness Test

   A PANA session is associated with a session lifetime.  The session is
   terminated unless it is refreshed by a new round of EAP
   authentication before it expires.  Therefore, at the latest a
   disconnected client can be detected when its lifetime session expires.  A
   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
   and the peer must respond with an answer message.  A successful
   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 peer
   might have disconnected (e.g., after the discontinuation of data
   traffic).
   traffic for an extended period of time).  Periodic use of this
   exchange as a keep-alive requires
   additional care as it might result in congestion and hence false
   alarms.  This exchange is cryptographically protected when a PANA SA
   is available in order to prevent threats associated with the abuse of
   this functionality.

11.9  Mobility Optimization

   The mobility optimization described in Section 4.12 involves the
   previous PAA providing a AAA-Key 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 keep-alive requires additional care as it might result
   in congestion and hence false alarms.

   This exchange is cryptographically protected when a compromised previous PAA along with the
   intercepted nonce values on the current link leads PANA SA is
   available in order to prevent threats associated with the compromise
   of AAA-Key-new.  Operators should be aware of the potential risk abuse of
   using
   this optimization.  An operator can reduce the risk exposure by
   forcing the PaC functionality.

   Any valid PANA answer message received in response to perform a recently sent
   request message can be taken as an EAP-based authentication immediately
   after the indication of peer's liveness.
   The PaC gains access to new link via or PAA MAY forgo sending an explicit PANA-Ping-Request if a
   recent exchange has already confirmed that the optimized PANA
   execution.

11.10 peer is alive.

10.9  Updating PaC's IP Address

   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
   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
   address.

11.11

10.10  Early Termination of a Session

   The PANA protocol supports the ability for both the PaC and the PAA
   to transmit a tear-down message before the session lifetime expires.
   This message causes state removal, a stop of the accounting procedure
   and removes the installed per-PaC state on the EP(s).  This message
   is cryptographically protected when PANA SA is present.

12.

11.  Acknowledgments

   We would like to thank Jari Arkko, Mohan Parthasarathy, Julien
   Bournelle, Rafael Marin Lopez, Pasi Eronen, Randy Turner, Erik
   Nordmark
   Nordmark, Lionel Morand, Avi Lior, Susan Thomson, Giaretta Gerardo
   and all members of the PANA working group for their valuable comments
   to this document.

13.

12.  References

13.1

12.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
              Timer", RFC 2988, November 2000.

   [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
              M. Carney, "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", RFC 3315, July 2003.

   [RFC3456]  Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic
              Host Configuration Protocol (DHCPv4) Configuration of
              IPsec Tunnel Mode", RFC 3456, January 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
              3748, June 2004.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-03
              Management Framework", draft-ietf-eap-keying-04 (work in
              progress), November 2004.

   [IANA]     Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",  BCP 26, RFC 2434,
              October 1998.

12.2  Informative References

   [I-D.ietf-pana-requirements]
              Yegin, A. and Y. Ohba, "Protocol for Carrying
              Authentication for Network Access (PANA)Requirements",
              draft-ietf-pana-requirements-09 (work in progress), August
              2004.

   [RFC2522]  Karn, P. and W. Simpson, "Photuris: Session-Key Management
              Protocol", RFC 2522, March 1999.

   [I-D.ietf-pana-threats-eval]
              Parthasarathy, M., "Protocol for Carrying Authentication
              and Network Access Threat Analysis and  Security
              Requirements", draft-ietf-pana-threats-eval-07 (work in
              progress), August 2004.

   [I-D.ietf-pana-ipsec]
              Parthasarathy, M., "PANA enabling IPsec based Access
              Control", draft-ietf-pana-ipsec-05 (work in progress),
              December 2004.

   [I-D.ietf-pana-framework]
              Jayaraman, P., "PANA Framework",
              draft-ietf-pana-framework-02 (work in progress), September
              2004.

   [I-D.ietf-pana-snmp]
              Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for
              PAA-2-EP interface", draft-ietf-pana-snmp-02 (work in
              progress), October 2004.

   [I-D.ietf-eap-statemachine]
              Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba,
              "State Machines for Extensible Authentication Protocol
              (EAP) Peer and  Authenticator",
              draft-ietf-eap-statemachine-05 (work in progress),
              September 2004.

   [I-D.ietf-ipsec-ikev2]
              Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              draft-ietf-ipsec-ikev2-17 (work in progress), July October
              2004.

   [IANA]

   [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-07 (work in progress),
              December 2004.

   [ianaweb]  IANA, "Number assignment",  http://www.iana.org.

   [IANA-EXP]
              Narten, T. T., "Assigning Experimental and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section Testing Numbers
              Considered Useful",  BCP 82, RFC 3692, January 2004.

   [RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

Authors' Addresses

   Dan Forsberg
   Nokia Research Center
   P.O. Box 407
   FIN-00045 NOKIA GROUP
   Finland

   Phone: +358 50 4839470
   EMail: dan.forsberg@nokia.com

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Phone: +1 732 699 5305
   EMail: yohba@tari.toshiba.com

   Basavaraj Patil
   Nokia
   6000 Connection Dr.
   Irving, TX  75039
   USA

   Phone: +1 972-894-6709
   EMail: Basavaraj.Patil@nokia.com
   Hannes Tschofenig
   Siemens Corporate Technology
   Otto-Hahn-Ring 6
   81739 Munich
   Germany

   EMail: Hannes.Tschofenig@siemens.com

   Alper E. Yegin
   Samsung Advanced Institute of Technology
   75 West Plumeria Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 544 5656
   EMail: alper.yegin@samsung.com

Appendix A.  Example Sequence of Separate NAP and ISP Authentication

   A PANA message sequence with separate NAP and ISP authentication is
   illustrated in Figure 12.  The example assumes the following
   scenario:

   o  The PaC initiates the discovery and handshake phase.

   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
      from PAA, with choosing "ISP1" as the ISP.

   o  NAP authentication and ISP authentication is performed in this
      order in RFCs",  BCP 26, RFC 2434,
              October 1998.

13.2  Informative References

   [I-D.ietf-pana-requirements]
              Yegin, A. the authentication and Y. Ohba, "Protocol for Carrying
              Authentication for Network Access (PANA)Requirements",
              draft-ietf-pana-requirements-09 (work authorization phase.

   o  An EAP authentication method with a single round trip is used in progress), August
              2004.

   [RFC2522]  Karn, P.
      each EAP sequence.

   o  After a PANA SA is established, all messages are integrity and W. Simpson, "Photuris: Session-Key Management
              Protocol", RFC 2522, March 1999.

   [I-D.ietf-pana-threats-eval]
              Parthasarathy, M., "Protocol for Carrying
      replay protected with MAC AVPs.

   o  The access, re-authentication and termination phases are not
      shown.

      PaC      PAA  Message(sequence number)[AVPs]
      -----------------------------------------------------
      // Discovery and handshake phase
         ----->     PANA-PAA-Discover(0)
         <-----     PANA-Start-Request(x)               // S-flag set
                       [Nonce, Cookie,
                        ISP-Information("ISP1"),
                        ISP-Information("ISP2"),
                        NAP-Information("MyNAP")]
         ----->     PANA-Start-Answer(x)                // S-flag set
                       [Nonce, Cookie,                  // PaC chooses "ISP1"
                        ISP-Information("ISP1")]

      // Authentication and Network Access Threat Analysis authorization phase
         <-----     PANA-Auth-Request(x+1)              // NAP authentication
                       [Session-Id, EAP{Request}]       // S- and  Security
              Requirements", draft-ietf-pana-threats-eval-07 (work in
              progress), August 2004.

   [I-D.ietf-pana-ipsec]
              Parthasarathy, M., "PANA enabling IPsec based Access
              Control", draft-ietf-pana-ipsec-04 (work in progress),
              September 2004.

   [I-D.ietf-pana-framework]
              Jayaraman, P., "PANA Framework",
              draft-ietf-pana-framework-02 (work in progress), September
              2004.

   [I-D.ietf-pana-snmp]
              Mghazli, Y., Ohba, Y. N-flags set
         ----->     PANA-Auth-Answer(x+1)               // S- and J. Bournelle, "SNMP usage for
              PAA-2-EP interface", draft-ietf-pana-snmp-01 (work in
              progress), July 2004.

   [I-D.irtf-aaaarch-handoff]
              Arbaugh, W. N-flags set
                       [Session-Id]                     // No piggybacking
         ----->     PANA-Auth-Request(y)                // S- and B. Aboba, "Experimental Handoff Extension
              to RADIUS", draft-irtf-aaaarch-handoff-04 (work in
              progress), November 2003.

   [I-D.ietf-eap-statemachine]
              Vollbrecht, J., Eronen, P., Petroni, N. N-flags set
                       [Session-Id, EAP{Response}]
         <-----     PANA-Auth-Answer(y)[Session-Id]     // S- and N-flags set
         <-----     PANA-Auth-Request(x+2)              // S- and N-flags set
                       [Session-Id, EAP{Request}]
         ----->     PANA-Auth-Answer(x+2)               // S- and N-flags set
                       [Session-Id, EAP{Response}]      // Piggybacking
         <-----     PANA-FirstAuth-End-Request(x+3)     // S- and Y. Ohba,
              "State Machines for Extensible Authentication Protocol
              (EAP) Peer N-flags set
                       [Session-Id, EAP{Success}, Key-Id, MAC]
         ----->     PANA-FirstAuth-End-Answer(x+3)      // S- and  Authenticator",
              draft-ietf-eap-statemachine-05 (work in progress),
              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]
              Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              draft-ietf-ipsec-ikev2-17 (work in progress), October
              2004.

   [ianaweb]  IANA, "Number assignment",  http://www.iana.org.

   [IANA-EXP]
              Narten, T., "Assigning Experimental N-flags set
                       [Session-Id, Key-Id, MAC]
         <-----     PANA-Auth-Request(x+4)              // ISP authentication
                       [Session-Id, EAP{Request}, MAC]  // S-flag set
         ----->     PANA-Auth-Answer(x+4)               // S-flag set
                       [Session-Id, MAC]                // No piggybacking
         ----->     PANA-Auth-Request(y+1)              // S-flag set
                       [Session-Id, EAP{Response}, MAC]
         <-----     PANA-Auth-Answer(y+1)               // S-flag set
                       [Session-Id, MAC]
         <-----     PANA-Auth-Request(x+5)              // S-flag set
                       [Session-Id, EAP{Request}, MAC]
         ----->     PANA-Auth-Answer(x+5)               // S-flag set
                       [Session-Id, EAP{Response}, MAC] // Piggybacking
         <-----     PANA-Bind-Request(x+6)              // S-flag set
                       [Session-Id, Result-Code, EAP{Success}, Device-Id,
                       IP-Address, Key-Id, Lifetime,
                       Protection-Cap., PPAC, MAC]
         ----->     PANA-Bind-Answer(x+6)               // S-flag set
                       [Session-Id, Device-Id, Key-Id,
                        PPAC, MAC]

    Figure 12: A Complete Message Sequence for Separate NAP and Testing Numbers
              Considered Useful",  BCP 82, RFC 3692, January 2004.

Authors' Addresses

   Dan Forsberg
   Nokia Research Center
   P.O. Box 407
   FIN-00045 NOKIA GROUP
   Finland

   Phone: +358 50 4839470
   EMail: dan.forsberg@nokia.com

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Phone: +1 732 699 5305
   EMail: yohba@tari.toshiba.com

   Basavaraj Patil
   Nokia
   6000 Connection Dr.
   Irving, TX  75039
   USA

   Phone: +1 972-894-6709
   EMail: Basavaraj.Patil@nokia.com
   Hannes Tschofenig
   Siemens Corporate Technology
   Otto-Hahn-Ring 6
   81739 Munich
   Germany

   EMail: Hannes.Tschofenig@siemens.com

   Alper E. Yegin
   Samsung Advanced Institute of Technology
   75 West Plumeria Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 544 5656
   EMail: alper.yegin@samsung.com ISP
                             Authentication

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.