Subject: [Pana] issue 106 and 109

From: Alper Yegin <[email-masked]>
Date: Thu, 02 Sep 2004 17:27:46 -0700

Here is the proposed text for taking care of issues 106 and 109.

Let me summarize the intended changes. I hope the proposed text
satisfies the intent without breaking things (well, it is pretty
comprehensive ;-)

- Now we have only one seq. no in each packet, which is maintained
across retransmissions.
- Only one pending request is allowed from each side.
- The size fields in the header are re-adjusted.
- New PANA-Reauth-Request/answer message is defined. Now PDI is strictly
used for the very initial discovery and initiation.
- A PAR transmitted by PAA is first acknowledged by PaC sending back a
PAN, followed by PaC sending a PAR (that carries the EAP response). So,
now the
PAR can be sent from either side. [optionally EAP-response can be
piggybacked on PAN]
- PER is acknowledged by a PEA (PANA-Error-Answer).

Here we go.....

[1] Section 4.1.4

4.1.4  Sequence Number and Retransmission

   PANA uses sequence numbers to provide ordered and reliable delivery 
   of messages. 

   PaC and PAA maintain two sequence numbers: the next one 
   to be used for a request it initiates and the next one it expects to 
   see in a request from the other end. These sequence numbers are
   monotonically incremented by 1 as new requests are generated and
   received. Answers always contain the same sequence number as the
   corresponding request. Retransmissions maintain the same sequence
   number.

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

   When a request message is 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 PANA-PAA-Discover,
   and the very first request messages.
 
   When an answer message is received, it is considered valid in terms
of
   sequence numbers if and only if its sequence number matches that of
   the currently outstanding request. A peer can only have one
outstanding
   request at a time.

   PANA layer messages are retransmitted based on timer at
   until a response is received (in which case the
   retransmission timer is stopped) or the number of retransmission
   reaches the maximum value (in which case the PANA session MUST be
   deleted immediately).  The retransmission timer SHOULD be calculated 
   as described in [RFC2988] to provide congestion control.  See Section
7
   for default timer and maximum retransmission count parameters.

   PaC and PAA MUST respond to duplicate requests. Last transmitted PANA
   answer MAY be cached in case it is not received by the peer and that
   generates a retransmission of the last request. When availabe, a
cached
   answer can be used instead of fully processing the retransmitted
   request and forming a new answer from scratch.
 
   PANA MUST NOT generate EAP message duplication. EAP payload of a 
   retransmitted PANA message MUST NOT be passed to the EAP layer.   

[2] Section 4.1.5

Change:

      *  Last transmitted tseq value

      *  Last received rseq value

To:

      *  Sequence number of the last transmitted request

      *  Sequence number of the last received request

[3] Section 4.1.7

Change:

   Invalid messages MUST be discarded in order to provide robustness
   against DoS attacks.  In addition, a non-acknowledged error
   notification message MAY be returned to the sender.  See Section
   4.1.8 for details.

To:

   Invalid messages MUST be discarded in order to provide robustness
   against DoS attacks.  In addition, an  error
   notification message MAY be returned to the sender.  See Section
   4.1.8 for details.

[4] Section 4.1.8

4.1.8  Error Handling

   PANA-Error-Request message MAY be sent by either PaC or PAA when a
badly
   formed PANA message is received or in case of other errors. The
receiver
   of this request MUST respond with a PANA-Error-Answer message. If the
   cause of this error message was a request message (e.g.,
   PANA-PAA-Discover or *-Request), then the request MAY be
   retransmitted immediately without waiting for its retransmission
   timer to go off.  If the cause of the error was a response message,
   the receiver of the PANA-Error-Request message SHOULD NOT resend the 
   same response until it receives the next request.

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

   When an error message is sent unprotected with MAC AVP and the
   lower-layer is insecure, the error message is treated as an
   informational message.  The receiver of such an error message MUST
   NOT change its state unless the error persists and the PANA session
   is not making any progress.

[5] Section 4.2

Change:

   A PANA-Start-Request message MAY carry a Cookie AVP that contains a
   cookie.  The rseq field of the header is set to zero (0).  The tseq
   field of the header contains the initial sequence number.  

To:

   A PANA-Start-Request message MAY carry a Cookie AVP that contains a
   cookie.  The sequence number is set to a randomly picked ISN.

[6] Section 4.2.1

Change:

   When a PaC receives the PANA-Start-Request message in response to the
   PANA-PAA-Discover message, it responds with a PANA-Start-Answer
   message if it wishes to enter the authentication phase.  The
   PANA-Start-Answer message contains the initial sequence numbers in
   the tseq and rseq fields of the PANA header, a copy of the received
   Cookie (if any) as the PANA payload. 

To:

   When a PaC receives the PANA-Start-Request message in response to the
   PANA-PAA-Discover message, it responds with a PANA-Start-Answer
   message if it wishes to enter the authentication phase. The answer
   message copies the sequence number and the cookie (if any) from the
   received request.

[7] Section 4.3

Change:

   The main task in authentication phase is to carry EAP messages
   between PaC and PAA.  EAP Request messages are carried in
   PANA-Auth-Request messages and optionally carried in
   PANA-Start-Request messages.  EAP Response messages are carried in
   PANA-Auth-Answer messages and optionally carried in PANA-Start-Answer
   messages.  When an EAP Success/Failure message is sent from a PAA,
   the message is carried in a PANA-Bind-Request (PBR) or
   PANA-FirstAuth-End-Request (PFER) message.  The
   PANA-FirstAuth-End-Request message MUST be used at the end of the
   first EAP when the PaC and PAA have negotiated during the discovery
   and initial handshake phase to perform separate NAP and ISP
   authentications in a single PANA authentication phase.  Otherwise,
   the PANA-Bind-Request message MUST be used.  The PANA-Bind-Request
   and PANA-FirstAuth-End-Request messages MUST be acknowledged with a
   PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA)
   messages, respectively.  Figure 5 shows an example sequence for the
   authentication phase without separating NAP and ISP authentications.

To:

   The main task in authentication phase is to carry EAP messages
   between PaC and PAA.  EAP Request and Response messages are 
   carried in PANA-Auth-Request messages. PANA-Auth-Answer is simply
   used to acknowledge receipt of the request. As an optimization,
   a PANA-Auth-Answer message MAY include the EAP Response. Another
   optimization allows optionally carrying the first EAP
Request/Response
   in PANA-Start-Request/Answer message. 

   When an EAP Success/Failure message is sent from a PAA,
   the message is carried in a PANA-Bind-Request (PBR) or
   PANA-FirstAuth-End-Request (PFER) message.  The
   PANA-FirstAuth-End-Request message MUST be used at the end of the
   first EAP authentication when the PaC and PAA have negotiated during 
   the discovery and initial handshake phase to perform separate NAP and
   ISP authentications in a single PANA authentication phase.
Otherwise,
   the PANA-Bind-Request message MUST be used.  The PANA-Bind-Request
   and PANA-FirstAuth-End-Request messages MUST be acknowledged with a
   PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA)
   messages, respectively.  Figure 5 shows an example sequence for the
   authentication phase without separating NAP and ISP authentications.

Change:

   EAP authentication can fail at a pass-through authenticator without
   sending an EAP-Failure message [I-D.ietf-eap-statemachine].  When
   this occurs, the PAA SHOULD send a PANA-Error message to the PaC with
   using PANA_UNABLE_TO_COMPLY result code.  The PaC SHOULD ignore the
   message unless it is secured by PANA or lower layer.  In any case, a
   more appropriate way is to rely on a timeout on the PaC.

To:

   EAP authentication can fail at a pass-through authenticator without
   sending an EAP-Failure message [I-D.ietf-eap-statemachine].  When
   this occurs, the PAA SHOULD send a PANA-Error-Request message to the
PaC 
   with using PANA_UNABLE_TO_COMPLY result code.  The PaC SHOULD ignore
the
   message unless it is secured by PANA or lower layer.  In any case, a
   more appropriate way is to rely on a timeout on the PaC.

[8] Section 4.4 

4.4  Re-authentication

   An already established PANA session can enter an authentication phase
   by re-executing EAP.  

   When a PaC wants to initiate re-authentication, it sends a
   PANA-Reauth-Request message to the PAA.  This message MUST
   contain a Session-Id AVP which is used for identifying the PANA
   session on the PAA. If the PAA already has an established PANA
   session for the PaC with the matching identifier, it MUST first
   respond with a PANA-Reauth-Answer, followed by a PANA-Auth-Request
   that starts a new EAP authentication. If PAA cannot identify the
   session, it MUST respond with a PANA-Error-Request with the error
   code PANA_UNKNOWN_SESSION_ID.                 
   
   PaC may receive a PANA-Auth-Request before receiving the answer
   to its outstanding PANA-Reauth-Request. This condition can arise
   due to packet re-ordering or a race condition between the PaC and PAA
   when they both attempt to engage in reauthentication. 
   PaC MUST keep discarding the received PANA-Auth-Requests until it
   receives the answer to its request.

   When the PAA initiates re-authentication, it
   sends a PANA-Auth-Request message containing the session identifier
   for the PaC to enter an authentication phase.  PAA SHOULD initiate
   EAP authentication before the current session lifetime expires.  

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

   For any re-authentication, if there is an
   established PANA SA, PANA-Auth-Request and PANA-Auth-Answer messages
   MUST be protected by adding a MAC AVP to each message.  Any
   subsequent EAP-based authentication MUST be performed with the same
   ISP and NAP that was selected during the initial authentication.  An
   example sequence for a re-authentication initiated by a PaC is shown
   in Figure 6.

      PaC      PAA  Message
      ------------------------------------------------------
         ----->     PANA-Reauth-Request(p)[Session-Id]
         <-----     PANA-Reauth-Answer(p)[Session-Id]

         <-----     PANA-Auth-Request(q)[Session-Id, EAP, MAC]
         ----->     PANA-Auth-Answer(q)[Session-Id, EAP, MAC]
         ----->     PANA-Auth-Request(p+1)[Session-Id, EAP, MAC]
         <-----     PANA-Auth-Answer(p+1)[Session-Id, EAP, MAC]

         <-----     PANA-Auth-Request(q+1)[Session-Id, EAP, MAC]
         ----->     PANA-Auth-Answer(q+1)[Session-Id, EAP, MAC]
         ----->     PANA-Auth-Request(p+2)[Session-Id, EAP, MAC]
         <-----     PANA-Auth-Answer(p+2)[Session-Id, EAP, MAC]

         <-----     PANA-Bind-Request(q+2)
                       [Session-Id, EAP{Success}, Device-Id, IP-Address,
                        Key-Id, Lifetime, Protection-Cap., PPAC, MAC]
         ----->     PANA-Bind-Answer(q+2)
                       [Session-Id, Device-Id, Key-Id, PPAC, MAC]

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

[9] Section 4.7

I think we can safely remove this section now.

[10] Section 4.10

Change:

   If the address contained in
   the request is invalid, the PAA MUST send a PANA-Error message with
   the result code PANA_INVALID_IP_ADDRESS.

To:

   If the address contained in
   the request is invalid, the PAA MUST send a PANA-Error-Request
message
   with the result code PANA_INVALID_IP_ADDRESS.

[11] Section 6.2

6.2  PANA Header

   A summary of the PANA header 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |         Message Length          |  Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Flags              |        Message Type           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sequence Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version

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

   Message Length

      The Message Length field is two octets and indicates the length
      of the PANA message including the header fields.

   Reserved

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

   Flags

      The 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R S N r r r r r r r r r r r r r|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      R(equest)

         If set, the message is a request.  If cleared, the message is
         an answer.

      S(eparate)

         When the S-flag is set in a PANA-Start-Request message it
         indicates that PAA is willing to offer separate EAP
         authentications for NAP and ISP.  When the S-flag is set in a
         PANA-Start-Answer message it indicates that PaC accepts on
         performing separate EAP authentications for NAP and ISP.  When
         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 authentications are being
         performed in the authentication phase.

      N(AP authentication)

         When the N-flag is set in a PANA-Auth-Request message, it
         indicates that PAA is performing NAP authentication.  When the
         N-flag is unset in a PANA-Auth-Request message, it indicates
         that PAA is performing ISP authentication. The PaC MUST copy
the
         flag status in its requests and answers from PAA. 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.

   Message Type

      The Message Type field is two octets, and is used in order to
      communicate the message type with 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 a method of encapsulating information relevant to the
      PANA message.  See section Section 6.3 for more information on
      AVPs.

[12] Section 6.3

6.3  AVP Header

   Each AVP of type OctetString MUST be padded to align on a 32-bit
   boundary, while other AVP types align naturally.  A number of
   zero-valued bytes are added to the end of the AVP Data field till a
   word boundary is reached.  The length of the padding is not reflected
   in the AVP Length field [RFC3588].

   The fields in the AVP header MUST be sent in network byte order.  The
   format of the header is:

       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            |           AVP Flags           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Vendor-Id (opt)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   AVP Code

      The AVP Code, combined with the Vendor-Id field, identifies the
      attribute uniquely.  AVP numbers are allocated by IANA [ianaweb].
      PANA uses its own address space for this field although some of
      the 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 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 is required.

      V(endor)

         The 'V' bit, known as the Vendor-Specific bit, indicates
         whether the optional Vendor-Id field is present in the AVP
         header.

      r(eserved)

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

   AVP Length

      The AVP Length field is four octets, and indicates the number of
      octets in this AVP including the AVP Code, AVP Length, AVP Flags,
      and the AVP data

   Reserved

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

   Vendor-Id

      The Vendor-Id field is present if the 'V' bit is set in the AVP
      Flags field.  The optional four-octet Vendor-Id field contains the
      IANA assigned "SMI Network Management Private Enterprise Codes"
      [ianaweb] value, encoded in network byte order.  Any vendor
      wishing to implement a vendor-specific PANA AVP 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 zero or more octets and contains information
      specific to the Attribute.  The format and length of the Data
      field is determined by the AVP Code and AVP Length fields.

[13] Section 6.4

6.4  PANA Messages

   Figure 11 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 11: PANA Message Overview

[14] Section 6.4.2

6.4.2  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 >
                    *  [ AVP ]

[15] Section 6.4.3

6.4.3  PANA-Start-Request (PSR)

   PANA-Start-Request (PSR) is sent by the PAA to the PaC.  The PAA sets
   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 ]

[16] Section 6.4.4

6.4.4  PANA-Start-Answer (PSA)

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

         PANA-Start-Answer ::= < PANA-Header: 2 [SEP] >
                       { Nonce }
                       [ Session-Id ]
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ ISP-Information ]
                    *  [ AVP ]
                   0*1 < MAC >

[17] Section 6.4.6:

6.4.6  PANA-Auth-Answer (PAN)

   PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a
   PANA-Auth-Request message.

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

[18] Insert new subsection after 6.4.6

6.4.7  PANA-Reauth-Request (PRAR)

   PANA-Reauth-Request (PRAR) is sent by the PaC to the PAA.

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

6.4.8  PANA-Reauth-Answer (PRAA)

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

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

[19] Update 6.4.13 and insert a new 6.4.14

6.4.13  PANA-Error-Request (PER)

   PANA-Error-Request is sent either by the PaC or the PAA.

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

6.4.13  PANA-Error-Answer (PEA)

   PANA-Error-Answer is sent in response to a PANA-Error-Request.

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

[20] section 6.5.7.2

Change:

  PANA_UNABLE_TO_COMPLY                   5012

      This error is returned when a 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 the PAA, a Result-Code AVP with this error code is carried in
      PANA-Error message.

To:

  PANA_UNABLE_TO_COMPLY                   5012

      This error is returned when a 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 the PAA, a Result-Code AVP with this error code is carried in
      PANA-Error-Request message.

Change:

PANA_INVALID_IP_ADDRESS  5018

      Error code from PAA to PaC.  This error is returned in a
      PANA-Error message when the IP-Address AVP in the received
      PANA-Update-Request message is invalid (e.g., a non-unicast
      address).

To:

PANA_INVALID_IP_ADDRESS  5018

      Error code from PAA to PaC.  This error is returned in a
      PANA-Error-Request message when the IP-Address AVP in the received
      PANA-Update-Request message is invalid (e.g., a non-unicast
      address).

[21] Section 6.6

Reworked tables.

                          +-----------------------------------------+
                          |                 Message                 |
                          |                   Type                  |
                          +-----+-----+-----+-----+-----+-----+-----+
      Attribute 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  |  0  |
      EAP-Payload         | 0-1 | 0-1 |  1  | 0-1 | 0-1 |  0  |  0  |
      MAC                 |  0  | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 |  0  |
      Nonce               |  1  |  1  |  0  |  0  |  0  |  0  |  0  |
      Device-Id           |  0  |  0  |  0  |  0  |  0+ | 0-1 |  0  |
      Cookie              | 0-1 | 0-1 |  0  |  0  |  0  |  0  |  0  |
      Protection-Cap.     | 0-1 |  0  |  0  |  0  | 0-1 |  0  |  0  |
      PPAC                | 0-1 |  0  |  0  |  0  |  1  | 0-1 |  0  |
      Session-Lifetime    |  0  |  0  |  0  |  0  | 0-1 |  0  |  0  |
      Failed-AVP          |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
      ISP-Information     |  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 | 0-1 |  0  |
      IP-Address          |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
      --------------------+-----+-----+-----+-----+-----+-----+-----+

                 Figure 12: 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  |  1  |  1  |  1   |  1   |
      Termination-Cause   |  0  |  0  |  1  |  0  |  0   |  0   |
      EAP-Payload         |  0  |  0  |  0  |  0  |  1   |  0   |
      MAC                 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1  | 0-1  |
      Nonce               |  0  |  0  |  0  |  0  |  0   |  0   |
      Device-Id           |  0  |  0  |  0  |  0  |  0   |  0   |
      Cookie              |  0  |  0  |  0  |  0  |  0   |  0   |
      Protection-Cap.     |  0  |  0  |  0  |  0  |  0   |  0   |
      PPAC                |  0  |  0  |  0  |  0  |  0   |  0   |
      Session-Lifetime    |  0  |  0  |  0  |  0  |  0   |  0   |
      Failed-AVP          |  0  |  0  |  0  |  0  |  0   |  0   |
      ISP-Information     |  0  |  0  |  0  |  0  |  0   |  0   |
      NAP-Information     |  0  |  0  |  0  |  0  |  0   |  0   |
      Key-Id              |  0  |  0  |  0  |  0  | 0-1  | 0-1  |
      IP-Address          |  0  |  0  |  0  |  0  |  0   |  0   |
      --------------------+-----+-----+-----+-----+------+------+

                 Figure 13: AVP Occurrence Table (2/3)

                          +-----------------------+
                          |         Message       |
                          |           Type        |
                          +-----+-----+-----+-----+
      Attribute Name      | PUR | PUA | PER | PEA |
      --------------------+-----+-----+-----+-----+
      Result-Code         |  0  |  0  |  1  |  0  |
      Session-Id          |  1  |  1  |  1  |  1  |
      Termination-Cause   |  0  |  0  |  0  |  0  |
      EAP-Payload         |  0  |  0  |  0  |  0  |
      MAC                 | 0-1 | 0-1 | 0-1 | 0-1 |
      Nonce               |  0  |  0  |  0  |  0  |
      Device-Id           |  0  |  0  |  0  |  0  |
      Cookie              |  0  |  0  |  0  |  0  |
      Protection-Cap.     |  0  |  0  |  0  |  0  |
      PPAC                |  0  |  0  |  0  |  0  |
      Session-Lifetime    |  0  |  0  |  0  |  0  |
      Failed-AVP          |  0  |  0  |  1  |  0  |
      ISP-Information     |  0  |  0  |  0  |  0  |
      NAP-Information     |  0  |  0  |  0  |  0  |
      Key-Id              |  0  |  0  |  0  |  0  |
      IP-Address          |  1  |  0  |  0  |  0  |
      --------------------+-----+-----+-----+-----+

                 Figure 14: AVP Occurrence Table (3/3)

[22] Section 7

Change:

   The PANA protocol provides retransmissions for all the message
   exchanges except PANA-Auth-Request/Answer.  PANA-Auth-Request
   messages carry EAP requests which are retransmitted by the EAP
   protocol entities when needed.  The messages that need PANA-level
   retransmissions are listed below:

         PANA-PAA-Discover (PDI)
         PANA-Start-Request (PSR)*
         PANA-Start-Answer (PSA)**
         PANA-Bind-Request (PBR)
         PANA-FirstAuth-End-Request (PFER)
         PANA-Reauth-Request (PRAR)
         PANA-Termination-Request (PTR)
         PANA-Update-Request (PUR)

         *)  PSR that carries a Cookie AVP is not retransmitted.
         **) PSA that does not carry a Cookie AVP is not retransmitted.

   The PDI and PSA messages are always sent by the PaC.  PBR is sent by
   PAA.  The last two messages, PRAR and PTR are sent either by PaC or
   PAA.

   The rule is that the sender of the request message retransmits the
   request if the corresponding answer is not received in time.  Answer
   messages are sent as answers to the request messages, not based on a
   timer.  Exception to this rule is the PSA message.  Because of the
   stateless nature of the PAA in the beginning PaC provides
   retransmission also for the PSA message.  PANA-Error messages MUST
   NOT be retransmitted.  See Section 4.1.8 for more details of PANA
   error handling.

To:

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

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

   PaC MUST retransmit PANA-PAA-Discover if a subsequent
PANA-Start-Request
   is not received 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. 

[23] 7.1  Transmission and Retransmission Parameters

   This section presents a table of values used to describe the message
   retransmission behavior of PANA requests (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

[24] In Section 8

Rewritten sub-sections:

8.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 6.4.1 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 communicating PaC and PAA using experimental
   commands, as outlined in [IANA-EXP].

8.3.2  Flags

   There are eight 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].

8.4.2  Flags

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

[25] Section 9.1 (from snapshot 6b)

Change:

   PANA messages carry both a transmission sequence number and an
   acknowledgement of the received sequence number.  These numbers are
   randomly initialized at the beginning of the session, and verified
   against expected numbers upon receipt.  A message whose sequence
   numbers fall outside of the expected range are 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 can
   also eavesdrop to synchronize on the sequence numbers.

To:

   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 can
   also eavesdrop to synchronize on the expected sequence number.

[26] Update all examples, so that only one sequence number is used, and
each PAR generates an immediate PAN, and another PAR (when received by
PaC).

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 01 Oct 2004 09:36:24 -0400

Hi Alper,

I have read the proposed text and I think this is really neat.

Please see my comments in line.

>    answer MAY be cached in case it is not received by the peer and that

I think the "MAY" should be "MUST" if PaC and PAA MUST respond to
duplicate requests.

>    message copies the sequence number and the cookie (if any) from the

Where the ISN of the PaC is carried?  Maybe the PSR and PSA carry an
ISN in an AVP (e.g., Initial-Sequence-Number AVP) using the sequence
number of zero if the PSR and PSA.

>    more appropriate way is to rely on a timeout on the PaC.

The PaC at least needs to return a PANA-Error-Answer message.  

How about this?

"The PaC SHOULD not change its state unless it is secured by PANA or
lower layer.  In any case, a more appropriate way is to rely on a
timeout on the PaC."

>    MUST be protected by adding a MAC AVP to each message.  Any

I think PANA-Reauth-Request/Answer can also be protected with a MAC AVP.

>    example sequence for a re-authentication initiated by a PaC is shown

We might add MAC AVP in PRAR/PRAA.

>    transmitted in network byte order.

Can we swap Reserved and Message Length fields?

Reserved field has only 7-bit in the figure.

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

PRAR and PRAA are missing.

OK, I will do that.  As the new sequence number scheme is pretty
straightforward, can we remove the sequence numbers from all examples
figures?

Thank you,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 03 Sep 2004 15:33:48 -0700

> I think the "MAY" should be "MUST" if PaC and PAA MUST respond to

You can still respond to dup request even if you hadn't cached your last
response. You can fully process the request (again) and form the same
response from scratch. I tried to explain this (see below).

> >    message if it wishes to enter the authentication phase. The
answer
> Where the ISN of the PaC is carried? 

It doesn't show up until the first request is sent by the PaC. Any
issues?

> Maybe the PSR and PSA carry an

> lower layer.  In any case, a more appropriate way is to rely on a

This is better.

> I think PANA-Reauth-Request/Answer can also be protected with a MAC
AVP.

OK, I'll add this somewhere.

> We might add MAC AVP in PRAR/PRAA.

OK.

> >       |            Flags              |        Message Type
|
> >       |                      Sequence Number
|
> Can we swap Reserved and Message Length fields?

OK.

> Reserved field has only 7-bit in the figure.

Will fix that.

> PRAR and PRAA are missing.

Duh! I'll add them.

> straightforward, can we remove the sequence numbers from all examples

I guess so. Actually, maybe we keep them in one of the examples, remove
from others. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 01 Oct 2004 10:40:36 -0400

> response from scratch. I tried to explain this (see below).

If the dup contains an EAP message, doesn't full processing mean
passing the EAP message to the EAP layer (which is "MUST NOT" in the
following text)?

"
"

> It doesn't show up until the first request is sent by the PaC. Any

I see.  It seems to work.

OK.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 03 Sep 2004 17:25:42 -0700

> > > >    PaC and PAA MUST respond to duplicate requests. Last
transmitted
> > PANA
> > > >    answer MAY be cached in case it is not received by the peer
and
> > that

The implementation could fully process the packet, except passing the
EAP payload to EAP. This is doable.

My point is, caching the last response is not the only way to reproduce
the same response, hence we must not mandate it. It is just listed as
one possible way. 

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 03 Sep 2004 17:51:08 -0700

[1] Section 4.1.4

 

 

[2] Section 4.1.5

Change:

To:

[3] Section 4.1.7

Change:

To:

[4] Section 4.1.8

4.1.8  Error Handling

[5] Section 4.2

Change:

To:

[6] Section 4.2.1

Change:

To:

[7] Section 4.3

Change:

To:

Change:

To:

   EAP authentication can fail at a pass-through authenticator without
   sending an EAP-Failure message [I-D.ietf-eap-statemachine].  When
   this occurs, the PAA SHOULD send a PANA-Error-Request message to the
PaC 
   with using PANA_UNABLE_TO_COMPLY result code. The PaC SHOULD not
change
   its state unless the error message is secured by PANA or lower layer.
   In any case, a more appropriate way is to rely on a timeout on the
PaC.

[8] Section 4.4 

4.4  Re-authentication

   code PANA_UNKNOWN_SESSION_ID. PANA-Reauth-Request/Answer messages
   MUST contain a MAC AVP when PANA SA is available.

      PaC      PAA  Message
      ------------------------------------------------------
         ----->     PANA-Reauth-Request(p)[Session-Id, MAC]
         <-----     PANA-Reauth-Answer(p)[Session-Id, MAC]

[9] Section 4.7

[10] Section 4.10

Change:

To:

[11] Section 6.2

6.2  PANA Header

       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         |

   Version

   Reserved

   Message Length

   Flags

       0                   1          

      R(equest)

      S(eparate)

      N(AP authentication)

      r(eserved)

   Message Type

   Sequence Number

   AVPs

[12] Section 6.3

6.3  AVP Header

       0                   1                   2                   3

   AVP Code

   AVP Flags

       0                   1          

      M(andatory)

      V(endor)

      r(eserved)

   AVP Length

   Reserved

   Vendor-Id

   Data

[13] Section 6.4

6.4  PANA Messages

[14] Section 6.4.2

[15] Section 6.4.3

[16] Section 6.4.4

[17] Section 6.4.6:

[20] section 6.5.7.2

Change:

To:

Change:

To:

[21] Section 6.6

Reworked tables.

                          +-------------------------------------+
                          |              Message                |
                          |                Type                 |
                          +-----+-----+-----+-----+------+------+
      Attribute Name      | PUR | PUA | PER | PEA | PRAR | PRAA |
      --------------------+-----+-----+-----+-----+------+------+
      Result-Code         |  0  |  0  |  1  |  0  |  0   |  0   |
      Session-Id          |  1  |  1  |  1  |  1  |  1   |  1   |
      Termination-Cause   |  0  |  0  |  0  |  0  |  0   |  0   |
      EAP-Payload         |  0  |  0  |  0  |  0  |  0   |  0   | 
      MAC                 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1  | 0-1  |
      Nonce               |  0  |  0  |  0  |  0  |  0   |  0   |
      Device-Id           |  0  |  0  |  0  |  0  |  0   |  0   |
      Cookie              |  0  |  0  |  0  |  0  |  0   |  0   |
      Protection-Cap.     |  0  |  0  |  0  |  0  |  0   |  0   |
      PPAC                |  0  |  0  |  0  |  0  |  0   |  0   |
      Session-Lifetime    |  0  |  0  |  0  |  0  |  0   |  0   |
      Failed-AVP          |  0  |  0  |  1  |  0  |  0   |  0   |
      ISP-Information     |  0  |  0  |  0  |  0  |  0   |  0   |
      NAP-Information     |  0  |  0  |  0  |  0  |  0   |  0   |
      Key-Id              |  0  |  0  |  0  |  0  |  0   |  0   |
      IP-Address          |  1  |  0  |  0  |  0  |  0   |  0   |
      --------------------+-----+-----+-----+-----+------+------+

[22] Section 7

Change:

         PANA-PAA-Discover (PDI)

To:

[24] In Section 8

Rewritten sub-sections:

8.3.1  Message Type

8.3.2  Flags

8.4.2  Flags

Change:

To:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 05 Sep 2004 16:29:10 -0400

I have couple of comments (most are editorial).  Please see below.

>    retransmitted PANA message MUST NOT be passed to the EAP layer.   

I think we should specify what to do when the sequence number wraps
up.

>    notification message MAY be returned to the sender.  See Section

The list of invalid messages should also be updated from (text from
-06b):

"
      *  After successful PANA authentication:

         +  PANA-Start-Request as well as a non-duplicate
            PANA-Bind-Request (see section Section 4.8 for definition of
            duplicate requests).

         +  PANA-PAA-Discover without a Session-Id AVP.
"

to:

"
      *  After successful PANA authentication:

         +  PANA-Start-Request as well as a non-duplicate
            PANA-Bind-Request (see section Section 4.8 for definition of
            duplicate requests).

         +  PANA-PAA-Discover.
"

>    transmitted in network byte order.

I think we should also specify the N-bit value to be placed in PAR
sent from the PaC and PAN sent from the PAA.

>    PANA-Auth-Request message.

A PAN is sent not only by the PaC but also by the PAA.  Also, section
6.4.5 (PAR) needs to be updated specify that a PAR is sent not only by
the PAA but also by the PaC.

>    There are eight bits in the Flags field of the PANA header.  This

16 bits.

>    1 ('M'andatory).  The remaining bits should only be assigned via a

Regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Sun, 05 Sep 2004 20:32:23 -0700

Reflected Yoshi's comments.

Btw, why do we have this statement under 6.4.5:

   (Both NAP-Information and ISP-Information MUST NOT be included at the
   same time)

Is PAR really supposed to carry NAP/ISP-info?

Alper

[1] Section 4.1.4

   PaC and PAA maintain two sequence numbers: the next one 
   to be used for a request it initiates and the next one it expects to 
   see in a request from the other end. These sequence numbers are
32-bit
   unsigned numbers. They are monotonically incremented by 1 as new
   requests are generated and received, and wrapped to zero on the next
   message after 2^32-1. Answers always contain the same sequence number
   as the corresponding request. Retransmissions maintain the same 
   sequence number.

 

 

[2] Section 4.1.5

Change:

To:

[3] Section 4.1.7

Change:

To:

Change:

To:

            PANA-Bind-Request.

         +  PANA-PAA-Discover.

[4] Section 4.1.8

4.1.8  Error Handling

[5] Section 4.2

Change:

To:

[6] Section 4.2.1

Change:

To:

[7] Section 4.3

Change:

To:

Change:

To:

[8] Section 4.4 

4.4  Re-authentication

   

      PaC      PAA  Message

[9] Section 4.7

[10] Section 4.10

Change:

To:

[11] Section 6.2

6.2  PANA Header

       0                   1                   2                   3

   Version

   Reserved

   Message Length

   Flags

       0                   1          

      R(equest)

      S(eparate)

      N(AP authentication)

         When the N-flag is set in a PANA-Auth-Request message, it
         indicates that PAA is performing NAP authentication.  When the
         N-flag is unset in a PANA-Auth-Request message, it indicates
         that PAA is performing ISP authentication. 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)

   Message Type

   Sequence Number

   AVPs

[12] Section 6.3

6.3  AVP Header

       0                   1                   2                   3

   AVP Code

   AVP Flags

       0                   1          

      M(andatory)

      V(endor)

      r(eserved)

   AVP Length

   Reserved

   Vendor-Id

   Data

[13] Section 6.4

6.4  PANA Messages

[14] Section 6.4.2

[15] Section 6.4.3

[16] Section 6.4.4

[17] Section 6.4.5:

6.4.5  PANA-Auth-Request (PAR)

   PANA-Auth-Request (PAR) is sent by either the PAA or the PaC.

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

   (Both NAP-Information and ISP-Information MUST NOT be included at the
   same time)

[18] Section 6.4.6:

   PANA-Auth-Answer (PAN) is sent in response to a PANA-Auth-Request
   message.

[19] Insert new subsection after 6.4.6

[20] Update 6.4.13 and insert a new 6.4.14

[21] section 6.5.7.2

Change:

To:

Change:

To:

[22] Section 6.6

Reworked tables.

[23] Section 7

Change:

         PANA-PAA-Discover (PDI)

To:

[24] 7.1  Transmission and Retransmission Parameters

[25] In Section 8

Rewritten sub-sections:

8.3.1  Message Type

8.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].

8.4.2  Flags

[26] Section 9.1 (from snapshot 6b)

Change:

To:

[27] Update all examples, so that only one sequence number is used, and 
each PAR generates an immediate PAN, and another PAR (when received by
PaC).