State Machines for the Protocol for Carrying Authentication for Network Access (PANA)
RFC 5609

There has been a debate whether this version is sufficient with respect to how one issue from Pasi's review was resolved. Alper has raised an issue in that and wanted to create an improved solution. However, after going around a few times in trying to find a solution without other side-effects, polling the WG for objection, and considering the entire process, I have decided to approve the draft regardless. I have asked Alper to submit another draft that eventually obsoletes this RFC, as soon as he has a solution that works.

[Ballot comment]
Opening caveat: I am not really a state machine guy, so this may all be normal accepted
practice.  That is why it's a discuss discuss.

I found the use of the eap_piggyback procedure in the exit conditions to be very confusing.
I would expect exit conditions to be specified in terms of the rec'd messages and state
variables, but not locally executed procedures.

In a number of cases, there are two exit conditions that differ solely in the value returned
by this procedure.  It would make more sense to me if the exit condition was specified without
eap_piggyback, and the call to eap_piggyback was the first step in the exit condition.  This
has an unfortunate side effect (multiple exit states, depending on the result), which may
explain the methodology

I will give one example to provide a basis for discussion.  As dscribed above, note that collapsing
the two states into one results in two different exit states:

Current text, page 21:


  - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - -
  Rx:PAR[S] &&            EAP_Restart();            INITIAL
  PAR.exist_avp            TxEAP();
  ("EAP-Payload") &&      SessionTimerReStart
  eap_piggyback()            (FAILED_SESS_TIMEOUT);

  Rx:PAR[S] &&            EAP_Restart();            WAIT_EAP_MSG
  PAR.exist_avp            TxEAP();
  ("EAP-Payload") &&      SessionTimerReStart
  !eap_piggyback()          (FAILED_SESS_TIMEOUT);
                            if (generate_pana_sa())
                                Tx:PAN[S]("PRF-Algorithm",
                                  "Integrity-Algorithm");
                            else
                                Tx:PAN[S]();

What I would have expected:

  - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - -
  Rx:PAR[S] &&            if eap_piggyback()              INITIAL
  PAR.exist_avp                EAP_Restart();
  ("EAP-Payload")              TxEAP();
                                SessionTimerReStart
                                  (FAILED_SESS_TIMEOUT);
                            else
                                EAP_Restart();            WAIT_EAP_MSG
                                TxEAP();
                                SessionTimerReStart
                                    (FAILED_SESS_TIMEOUT);
                                if (generate_pana_sa())
                                    Tx:PAN[S]("PRF-Algorithm",
                                        "Integrity-Algorithm");
                                else
                                    Tx:PAN[S]();

[Ballot discuss]
This is a discuss discuss.  I will clear after the call unless the sponsoring AD asks me to
hold.  (Note this discuss is going to the iesg only...)

Opening caveat: I am not really a state machine guy, so this may all be normal accepted
practice.  That is why it's a discuss discuss.

I found the use of the eap_piggyback procedure in the exit conditions to be very confusing.
I would expect exit conditions to be specified in terms of the rec'd messages and state
variables, but not locally executed procedures.

In a number of cases, there are two exit conditions that differ solely in the value returned
by this procedure.  It would make more sense to me if the exit condition was specified without
eap_piggyback, and the call to eap_piggyback was the first step in the exit condition.  This
has an unfortunate side effect (multiple exit states, depending on the result), which may
explain the methodology

I will give one example to provide a basis for discussion.  As dscribed above, note that collapsing
the two states into one results in two different exit states:

Current text, page 21:


  - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - -
  Rx:PAR[S] &&            EAP_Restart();            INITIAL
  PAR.exist_avp            TxEAP();
  ("EAP-Payload") &&      SessionTimerReStart
  eap_piggyback()            (FAILED_SESS_TIMEOUT);

  Rx:PAR[S] &&            EAP_Restart();            WAIT_EAP_MSG
  PAR.exist_avp            TxEAP();
  ("EAP-Payload") &&      SessionTimerReStart
  !eap_piggyback()          (FAILED_SESS_TIMEOUT);
                            if (generate_pana_sa())
                                Tx:PAN[S]("PRF-Algorithm",
                                  "Integrity-Algorithm");
                            else
                                Tx:PAN[S]();

What I would have expected:

  - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - -
  Rx:PAR[S] &&            if eap_piggyback()              INITIAL
  PAR.exist_avp                EAP_Restart();
  ("EAP-Payload")              TxEAP();
                                SessionTimerReStart
                                  (FAILED_SESS_TIMEOUT);
                            else
                                EAP_Restart();            WAIT_EAP_MSG
                                TxEAP();
                                SessionTimerReStart
                                    (FAILED_SESS_TIMEOUT);
                                if (generate_pana_sa())
                                    Tx:PAN[S]("PRF-Algorithm",
                                        "Integrity-Algorithm");
                                else
                                    Tx:PAN[S]();

[Ballot discuss]
I didn't do a full review of the state machines, but I noticed one
difference between the PANA-EAP interface and RFC 4137:

The interface between the PANA state machine and EAP doesn't seem to
support the case when when EAP silently discards a packet (eapNoResp
and eapNoReq variables in the RFC 4137 state machines).  Is this a
limitation of the PANA protocol, or just a corner case that wasn't
included in these state machines?

[Ballot comment]
I'm clearing as Jari has pointed me at Section 4 that covers my most significant issue.

There are two important points that are shown in the Abstract that I would like you to consider adding to the main body of the text.

- "The statemachines and associated model are informative only."
- "Implementations may achieve the same results using different methods."

[Ballot discuss]
It may seem a small point and "obvious" to the authors and the working group, but I would like to see more clarity about what these state machines are *not*.

Currently I find in the Abstract
  This document defines the conceptual state machines
But the word "conceptual" does not reappear in the Introduction.

At the end of the Introduction, I find
  it is not a specification but an implementation guideline.
This is a helpful statement.

What I would like to see is:

1. A statement that these state machines are not normative to the protocol definition. The authorative definition of protocol is found in [RFC5191] and in case of any conflict between this document and [RFC5191], [RFC5191] shall take precedence. You could add that the state machines may be used to help a reader understand the protocol.

2. An expansion on the "implementation guideline" theme to make it clear to implementers that they are free to implement these state machines as described, but that they are not required to. (This may be a bit obvious to most people, but believe me people will try to implement these state machines.)

Apologies for taking some time to do this. I have reviewed the draft and I think it is in very good shape. There are one or two technical problems that require the draft to be revised, unless I missed something. Please discuss this with me and, if needed, revise the draft accordingly.

Here are my comments:

> 7.2. Constants
>
>    FAILED_SESS_TIMEOUT
>
>      Configurable value ...

Small editorial problem: Something is inconsistent here.... maybe call the section "7.2. Configurable Values"?

>    State: WAIT_PNA

Three technical problems:

1. You enter this state in two ways, either because you sent a PING, or because you wanted to re-authenticate. However, coming back from the state you go to re-authentication or ping processing depending on the flag in the answer message. So, if the peer responds with the wrong flag value, you might accidentally go into, say, OPEN state even if you really were going to do re-authentication...

The fix is is to either note the limitation or split WAIT_PNA into two different states.

2. What happens if you want to initiate re-auth while waiting for ping response? Perhaps you could state that the relevant variables are not supposed to be set until you are in OPEN... or you could do some more radical change.

3. More seriously, I think you need to support the case that you are doing ping on one side while the other guy initiates re-authentication. WAIT_PNA does not support reception of the relevant messages. This needs to be fixed somehow.

Generalizing the last point a little bit, what do you do when there's termination / ping / re-authentication / initialization in parallel with something else that the other peer is doing? At the very least, you need to explicitly decide to discard undesired events in states (and show that its still according to the RFC). Or, some other type of a change is needed in the draft.

>    ------------------------------
>    State: INITIAL (Initial State)
>    ------------------------------
>
>    Initialization Action:
>
>      OPTIMIZED_INIT=Set|Unset;
>      NONCE_SENT=Unset;
>      RTX_COUNTER=0;
>      RtxTimerStop();
>
>    ...
>
>    - - - - - - - - - - - - - - (PAN Handling)  - - - - - - - - - -
>    Rx:PAN[S] &&            if (PAN.exist_avp          WAIT_EAP_MSG
>    ((OPTIMIZED_INIT ==        ("EAP-Payload"))
>      Unset) ||                TxEAP();
>    PAN.exist_avp            else {
>      ("EAP-Payload"))        EAP_Restart();
>                              SessionTimerReStart
>                                (FAILED_SESS_TIMEOUT);
>                            }
>
>    Rx:PAN[S] &&            None();                    WAIT_PAN_OR_PAR
>    (OPTIMIZED_INIT ==
>      Set) &&
>    ! PAN.exist_avp
>    ("EAP-Payload")

Observation: the two actions do not cover all possible combinations, e.g., not Rx:PAN[S] && OPTIMIZED_INIT == Unset && !PAN.exist_avp("EAP-Payload").

You are setting OPTIMIZED_INIT to a value at the time that the state machine is created. What if it disagrees with the contents of the PAN that you receive from the network?

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document Shepherd: Basavaraj Patil.
I have reviewed this version of the I-D and believe it is ready to be
forwarded to the IESG for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed adequately by WG members and non-WG
members. I do not have any concerns about the breadth of depth of the
reviews that have been performed.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No. The document has been adequately reviewed. No further reviews are
necessary.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No specific concerns/issues with the document exist. This document is
intended to be pulished as an Informational RFC and it is primarily
targeted at implementers of PANA protocol to better understand the
state machine.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Two WG last calls have been run. The WG is solidly in support of this
document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No threats of appeals have been made. Nor is there any discontent
among any of the WG members and participants.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Yes.
Output of the IDnits tool:
Summary: 0 errors (**), 4 warnings (==), 0 comments (--).

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes. The references are split into normative and informative ones.
No open-ended references exist.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG
Evaluation?

The document does have an IANA considerations section. The document
does not specify any IANA actions.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Document does not use any XML code or BNF rules etc.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document defines the state machines for Protocol Carrying
Authentication for Network Access (PANA) [RFC5191]. There are state
machines for the PANA client (PaC) and for the PANA Authentication
Agent (PAA). Each state machine is specified through a set of
variables, procedures and a state transition table.

Working Group Summary

The WG has reviewed this document at length. It has also been
presented and discussed at several WG meetings. Two WG last calls have
also been run on it. The WG is satisfied with the quality of the
document and there is consensus on publishing it.

Document Quality
Implemenations of PANA protocol itself exist. This I-D is intended to
be published as an Informational RFC. It captures the state machine of
the PANA protocol. The quality of the document is satisfactory.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Document shepherd: Basavaraj Patil
Responsible AD: Jari Arkko

No IANA experts are needed since it does not specify any IANA actions.