Subject: RE: [AAA-WG]: Wrapping up Diameter EAP...

From: <[email-masked]>
Date: Tue, 18 May 2004 10:21:55 +0300

Yoshihiro Ohba wrote:

>>> - What the Diameter EAP client (i.e., the NAS) should do 
>>> when EAP is reset while it has an outstanding DER?  (a) Can 
>>> the Diameter EAP client immediately send a new DER used for 
>>> restarting EAP conversation without waiting for a DEA for the 
>>> outstanding DER, or (b) Should the Diameter EAP client wait for 
>>> a DEA for the outstanding DER before sending a new DER used for 
>>> restarting EAP conversation?
>> 
>> This seems to be related to the question when the NAS should
>> pick a new Session-Id... I think that at least (a) with a new 
>> Session-Id would be one reasonable choice.
> 
> With using a new Session-Id how the EAP server can choose which 
> EAP session to restart (I guess a State AVP should be included 
> in the DER that is used for restarting the EAP conversation for 
> this purpose)?

Does the EAP server even need to know which EAP session to restart?  
It does not seem to need any information from the old EAP session,
and the state allocated it will eventually time out and get freed.
I'm quite sure that the State AVP should not be included, because
after all we've been talking about using the _lack_ of a State AVP 
to signal a restarted EAP session...

Best regards,
Pasi

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 May 2004 04:47:02 -0700

> to signal a restarted EAP session...

Now I see what you suggest and I think that is good.  Then a State AVP
is not needed for distinguishing a restarted EAP session from a
continuing EAP session, and thus the AVP does not need to be carried
even for a continueing EAP session, right?  A State AVP might be used
for some other purposes but I don't care about it.

BTW, in the suggested scheme, a Diameter EAP client implementation may
send a STR to quickly terminate the old EAP session while sending a
DER for a new (restarted) EAP session, instead of waiting for the old
EAP session to time out and get freed.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 May 2004 15:18:21 +0300

> EAP session to time out and get freed.

Sure. But if we want this to work with RADIUS too, I'm not sure we
have other alternatives than signaling with the presence or lack of
the State AVP.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 May 2004 05:58:44 -0700

> have other alternatives than signaling with the presence or lack of

I don't think we need to define the same method for RADIUS and
Diameter to support EAP restart.  Diameter can be smarter as it has
Session-Id and is able to terminate a session.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 May 2004 17:00:22 +0300

> Session-Id and is able to terminate a session.

Ok. That's reasonable. But are you saying

  1) We don't need Diameter and RADIUS to interoperate upon EAP restart.

or

  2) If we use Session-Id to support EAP restart in Diameter, we can
  make that work also through a D-R gateway so that it works even in
  RADIUS, which has to use State attribute?

I'd be happy with alt 2, but has someone looked at the details,
and can we make it work?

I would rather not have alt 1 myself.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 May 2004 08:07:17 -0700

> I'd be happy with alt 2, but has someone looked at the details,

I also support alt 2.  I think translation between RADIUS and Diameter
can be done in the following way (assuming that a State AVP is always
carried in RADIUS Access-Answer and Access-Accept messages when an
EAP-Message attribute is carried):

- Translation from DER to RADIUS Access-Request:

If the translation agent receives a DER with a new Session-Id, then it
generates a RADIUS Access-Request without a State attribute.  The
RADIUS server will treat the request as a signal to restart the EAP
session if the NAS and session identification attributes corresponds
to an existing EAP session.

If the translation agent receives a DER with an existing Session-Id,
then it generates a RADIUS Access-Request with a State attribute that
was contained in the message that was previously sent by the RADIUS
server.

- Translation from RADIUS Access-Request to DER:

If the translation agent receives a RADIUS Access-Request without a
State attribute, then it creates a new Diameter session and 
generates a DER with a new Session-Id.

If the translation agent receives a RADIUS Access-Request with a State
attribute as well as the NAS and session identification attributes
corresponding to an existing EAP session, then it generates a DER with
the corresponding Session-Id.

But I am pretty sure Pasi will come up with better text. :)

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 May 2004 10:06:20 -0700 (PDT)

>   RADIUS, which has to use State attribute?

I think it is ok for the Diameter NAS to send *both* State and Session-Id,
no?

Doesn't NASREQ require the Diameter client to respond with State if it's
included in the Diameter Answer?

If the Diameter client doesn't respond with State, I think this would
break both Diameter EAP and NASREQ NASen for compatiblity with a RADIUS
server, no?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 May 2004 13:00:31 -0700

> break both Diameter EAP and NASREQ NASen for compatiblity with a RADIUS

I think inclusion of a State AVP in DER/DEA is needed only when there
is a RADIUS server or proxy on the signaling path, but in this case
the State AVP is used only for restarting EAP session, but not for
some other purposes.

On the other hand, when all AAA nodes on the path is Diameter nodes,
the State AVP is not needed and the AVP could be used for some other
purposes.  (So Diameter only network could provide more flexibility.)

Regards,

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 May 2004 10:59:07 +0300

> EAP-Message attribute is carried):

We can say that this is necessary for the translation and restart
to work, and point out that currently RFC 3579 does not require State
to be used.

> the corresponding Session-Id.

This works for me.

--Jari