Subject: Re: [AAA-WG]: [Issue] Missing ABNFs in NASREQ?

From: David Mitton <[email-masked]>
Date: Fri, 09 Jan 2004 10:12:31 -0500

On 1/9/2004 12:16 PM +0200, Jari Arkko wrote:
>Bernard Aboba wrote:
>>Jari Arkko said:
>>
>>>Lets talk more in depth about the kind of situations that would warrant
>>>the use of additional AVPs. The base does allow the use of additional
>>>AVPs in these contexts, but I'm searching for the specific reason to
>>>include NASREQ AVPs.
>>>
>>>I'm not sure the Calling-Station-Id case is a good example. The STR
>>>and RAR commands have been designed to affect a given, existing session
>>>which is identified via the Session-ID AVP.
>>
>>The problem is that RFC 3576 allows for the session to be identified by
>>more than just its session-ID.  So what happens if a Diameter/RADIUS
>
>Ouch.
>
>>gateway gets a Disconnect or Change of Authorization request that doesn't
>>contain a session-Id?
>
>I can see the problem now. I wonder why RFC 3576 made that design decision,
>it would appear that a session id should be known to the home aaa server.

Session-IDs in RADIUS are an accounting artifact.  RADIUS Authorization is 
"stateless".
;^)
This is a key difference, we now have potential state and handles for such.

<digression>
RADIUS Access-Requests don't have a unique service identifier on them.  For 
a server to do duplicate detection it often used the concatenation of 
NAS-IP-Address, NAS-Port, Service-Type, User-Name, (and Port-Type if 
available).  There was still possible confusion if the same user attempts 
to login to the same physical port in a close time period.

>Anyway, maybe the point is moot because the RFC is already out there, so
>we have to comply with that.
>
>But if you can omit the session-id AVP, wouldn't that break the base
>BNF for STR, for instance? If that's the case, then maybe there should
>be the STR command for use when the session-id is known, and the
>Nasreq-Super-Termination-Request for the other cases?

I sense we have a generic RADIUS/Diameter problem here.  Diam-Nasreq sect 
9.1, bullet 7, says that for a RADIUS to Diameter request, the gateway will 
have to generate the required Session-Id.
And Sect 9.2 Diameter/RADIUS case, the Session-Id is to be captured and 
preserved in the State attribute.

In the case Bernard raises, we have a RADIUS speaking server attempting to 
Change Attributes or Disconnect a Diameter NAS session.

<hand wave>
Can we assume that it only knows about this session because it was involved 
in the authorization?
And that the authorization took place via same the Diameter/RADIUS gateway 
that is receiving the CoA-Req or Disc-Req?  In which case, then the gateway 
may be given the chore of maintaing session state, and having to re-insert 
the Session-Id from a local database.

A thought....

Dave.

>>Also, what if the session-id may not be known?  For example, in handoff
>>situations, the station may have moved to another access point and so
>>while the userid and calling-station-id is known, the new session-id is
>
>Two cases:
>
>1) Context transfer. Maybe the session id should be transferred? Presumably
>    some AAA-related data has to be transferred anyway, otherwise you won't
>    be able to generate accounting records with the right username, session-id
>    etc
>2) Pre-emptive AAA setup to the nearby APs. The session id is already
>    given from the AAA.
>
>Conclusion: In any case, in order to enable RFC 3576 translation to Diameter,
>we probably have to support session-id-less STR and other commands. Details to
>be worked out, but it looks preliminarily like this may require a new command.
>Unless someone invents another way to do it.
>
>--Jari
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Jan 2004 12:16:31 +0200

Ouch.

Two cases:

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 9 Jan 2004 00:19:39 -0800 (PST)

Also, what if the session-id may not be known?  For example, in handoff
situations, the station may have moved to another access point and so
while the userid and calling-station-id is known, the new session-id is
not known yet, yet it may be desirable to be able to purge the NAS devices
of the key state associated with the session.  RFC 3576 can identify the
session in a variety of ways:  userid, calling-station-id, nas-port, etc.

> which would imply that the usual NASREQ commands could carry the authz
> attributes.

Yes, that is fine.  It's session (and NAS) identification which I think is
the issue.