[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 226: RFC 3576bis and Renumbering
Hi
Bernard,
> 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/>