[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Issue 226: RFC 3576bis and Renumbering



Hi Bernard,


From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Saturday, May 26, 2007 12:04 PM
To: Alan DeKok; Avi Lior
Cc: David B. Nelson; radiusext@ops.ietf.org; Bernard Aboba
Subject: RE: Issue 226: RFC 3576bis and Renumbering



> Date: Sat, 26 May 2007 15:46:46 +0100
> From: aland@nitros9.org
> To: avi@bridgewatersystems.com
> CC: dnelson@elbrysnetworks.com; radiusext@ops.ietf.org; bernarda@windows.microsoft.com
> Subject: Re: Issue 226: RFC 3576bis and Renumbering
>
> Avi Lior wrote:
> > Accounting Session ID only identifies an accounting session Start/Stop
> > and its interims, if any. A given "session" (IP Session or
> > Access-Session) may contain a number of parallel accounting sessions, or
> > a sequence of accounting sessions.
>
> I see what you're saying, but I'm not sure I agree. The
> Acct-Session-Id defines a session that the Acct-Session-Id refers to.
> It's a circular reference, but not much else is true.
>
> The problem at hand, I think, is less Acct-Session-Id than in
> figuring out what the CoA packet refers to. My proposal is to key the
> CoA to a session Id (whatever it's called), which now allows the CoA to
> request changes to other portions of the session.
>
> If we key off of IP/port, then as Bernard pointed out, we can't send
> Framed-IP-Address as both a session key and as an indication to "use
> this new value".
>
> > When it comes to 3576 and DM or even COA:
> >
> > We need to be able to terminate or modify the Session WRT to A. That
> > is, sending a DM with an NAI or some other user identification, we
> > terminate all of the users IP sessions.
> >
> > We need to be able to terminate or modify any of the users IP sessions.
> > Therefore sending a DM which includes a user identification and an IP
> > address will only terminate that users IP session.
>
> Using IP's as a key to terminate a session is fine. Using them as a
> key *and* as a "new value" in a change request is not.

[BA] It would be somewhat complicated to define a different set of session identification attributes for CoA and Disconnect-Requests. 
[Avi] Correct.
 
[BA] Also, unless the NAS previously received Framed-IP-Address or Framed-IPv6-Prefix/Framed-Interface-Id attributes in an Access-Accept it typically will not know the user's IP address.  This is the situation with most NAS-Port-Type values, with the exception of PPP or protocols depending on PPP (e.g. PPPOE, PPPOA, L2TP, PPTP, etc.)
[Avi]  
[Avi]  In most cases that I am aware of, the NAS is the Point of Attachement to the internet and it knows the IP address(es) assigned to the user. So it is IP Session aware.  In any case, there are scenarios where it is IP session aware and it should be possible to make modification to those Sessions using DM or COA using the IP address as the Session Identifier.
 
[BA] Where an Access-Request was received with an Acct-Session-Id or an Accounting-Request is received, the Acct-Session-Id can be used as the session identifier.
[Avi] Yes I agree that it "can" be used.  But Alan seems to make it mandatory. And to mandatory require that it be sent in the Access-Request packet.  I dont agree with that.  I think if the deployement requires it to be in the access request then it can be sent.  The current RFCs are fine.
 
Where only an Access-Request is available, with no Acct-Session-Id, other session identification attributes can be used (NAS-Port/NAS-Port-Id, User-Name). 
[Avi] Yes I agree and even VSAs. 

[BA] So it's hard to imagine a case where the IP address is *required* as a session identifier.   And there are quite a few situations in which the NAS will be unable to identify the session by IP address.   Given this, encouraging the use of the IP address as a session identifier seems like a bad idea.
[Avi] I agree that the IP Address is not *required*.  I think that nothing should be *required*  because different scenarios will use different session identifiers.  Furthermore, I think they should be used in combination.  For example, User-Name + Accounting Session Id to delete the session associated with Accounting session id is better practice then just using Accounting Session Id.  

>
> Alan DeKok.
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>