Subject: [Pana] issue 105 (proposal)

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 30 Sep 2004 18:08:53 -0400

This is my proposal on an IKEv2-like sequence number scheme for PANA,
based on the recent discussion.

Comments are appreciated,

Proposal:

o Only one sequence number is included in each message, but each peer
has its own sequence number space for the requests it generates.
Answers have the sequence number of the corresponding requests.

o A sequence number starts from a non-zero initial sequence number
(ISN) negotiated in a PSR-PSA exchange and incremented by one (1)
before composing a new request except for PDI.

o All messages (including PER and PAR) but PDI have answers.
Retransmission of those messages are taken care of at PANA layer.
EAP-layer retransmission MUST be turned off.  A retransmitted message
has the same sequence number as the original one.

o A PDI message does not have a corresponding answer.  When a PaC
sends a PDI message to establish a PANA session, a sequence number of
zero (0) MUST be used for the PDI.  When a PaC sends a PDI message to
initiate a PANA re-authentication procedure, the sequence number of
the last answered request MUST be used.  If there is an established
PANA SA, a MAC AVP as well as a Session-Id AVP MUST be inserted in the
PDI.

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 01 Sep 2004 17:11:23 -0700

Hi Yoshi,

I have some clarification questions and comments.

> o All messages (including PER and PAR) but PDI have answers.

So, you are proposing defining a PEA (PANA-Error-Answer) as well, right?

Are you also proposing PAN is used to simply acknowledge receipt of a
PAR. (PaC would generate a PAR in order to deliver the EAP response,
which is also acked by PAA sending back a PAN)?

> EAP-layer retransmission MUST be turned off. 

Actually, PANA reliability sub-layer can eliminate duplicates before
sending them up for processing.

> A retransmitted message
> the last answered request MUST be used.  

Rather than having this special case, how about we define a new
request-answer type message for "re-auth" (instead of re-using PDI),
which triggers PAA to send a PAR?

> If there is an established

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 30 Sep 2004 19:55:13 -0400

> So, you are proposing defining a PEA (PANA-Error-Answer) as well, right?

Yes.

> which is also acked by PAA sending back a PAN)?

I did not mean that.  I just considered in this proposal a model where
PAN carries EAP-Response.  I think the scheme you mentioned above is
good in that the requester can distintiguish the case in which the
request is lost from the case the request was actually received but
receiver is taking time (due to, e.g., human intervention at the PaC
or AAA protocol interaction at the PAA) to generate a message which is
to be sent in response to the request.

> sending them up for processing.

I think so.

> which triggers PAA to send a PAR?

Hmm, I am interested in that.  Are you proposing something like this?

PaC                   PAA
 |  "reauth"-Request   |
 |-------------------->|
 |  "reauth"-Answer    |
 |<--------------------|
 |       PAR           |
 |<--------------------|
 |       PAN           |
 |-------------------->|
 |         .           |
 |         .           |

If so, I have one question.  If the PAR is received by the PaC before
"reauth"-Answer, should the PaC discard the PAR until "reauth"-Answer
is received?  Or should the PaC send PAN even if it does not receive
"reauth"-Answer?  I think we should do the latter since the PAR might
have been sent even the PAA receives the "reauth"-Request if PAA
initiated the re-authentication procedure.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 01 Sep 2004 19:29:53 -0700

> > So, you are proposing defining a PEA (PANA-Error-Answer) as well,
right?

Than every PER must be replied by a PEA. Any issues here?

> PAN carries EAP-Response.  

Without what I proposed, when EAP peer does not respond to a message,
the PAR would time out and PANA session gets torn down. (normally this
shouldn't happen. If EAP peer has not responded to an EAP message, AS
would retransmit the EAP message. No tear down by the EAP lower layer.)

> I think the scheme you mentioned above is

The latter may create complexity, when the accepted PAR immediately
generates an EAP response (another PAR) on the PaC, while PaC still has
an outstanding request (still unanswered reauth-request). This is like
having two outstanding requests.

The former does not have that. The unsolicited PAR may be tossed, but
PAA would rexmit it again at a later time. Finally the PaC would receive
an aswer to its reauth-request, and later receive a PAR.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 30 Sep 2004 20:36:38 -0400

> Than every PER must be replied by a PEA. Any issues here?

This is what IKEv2 does and I don't see any issues here.

> would retransmit the EAP message. No tear down by the EAP lower layer.)

I agree (except that it would be the EAP authenticator not the AS that
restranmits the EAP message when EAP-layer retransmission is turned
on).  An issue is that when using PAN as acknowledgment of PAR that
carries EAP message we might want to allow piggybacking an EAP message
in the PAN when the EAP-layer generates the EAP message within a
reasonable time frame.  This would add some complexity but can save
the number of total messages exchanged during authentication phase.  A
similar scheme is described in section 3.2 of
http://www.toshiba.com/tari/pana/sequence-number.txt.

> having two outstanding requests.

I agree.

> an aswer to its reauth-request, and later receive a PAR.

I think this is nice.

Yoshihiro Ohba