Subject: RE: RFC3576bis and Session State
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Date: Wed, 30 May 2007 16:45:27 -0400

All of this discussion leads me to believe we need a document that describes
the current state of affairs with the creation, naming and modification of
sessions, sub-sessions, multi-sessions and the like in RADIUS deployments.
This could be a section of RFC3576bis or it could be stand-alone document.

Do I recall that someone once attempted to write such a document?  Or am I
just remembering a long thread from the RADEXT list about three or four
years ago?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 20:33:49 +0000
Subject: RE: RFC3576bis and Session State
Date: Wed, 30 May 2007 16:33:19 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

See inline....=20

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]=20
Sent: Tuesday, May 29, 2007 4:10 AM
To: Avi Lior
Cc: Bernard Aboba; [email-masked]
Subject: Re: RFC3576bis and Session State

Avi Lior wrote:
> What session identifiers I include in the COA or DM message should=20
> indicate what I want to effect.

  The word "session" is being used in multiple contradictory ways.  Your
previous message indicated that one login "session" may result in
multiple Acct-Session-Id's.  In that case, keying off of Acct-Session-Id
to change a session would make sense.

[Avi] Session is overloaded.  I tried to define what the different
possible sessions are.  To me Acct-Session-Id represents a segement of a
session -- or an Accounting Segment of a session. If that is the case,
killing an accounting-segment is not very useful unless you were sure
that killing that segment would kill that session.  And you cant always
be sure of that.

  You now seem to be saying that sessions are *independent* of
Acct-Session-Id's, and that you do *not* want to use Acct-Session-Id as
a key for a session, but rather something else.

[Avi] Yes.  See above. And let me give you an example.

NAS
 |
 |<--IP-Session starts
 |
 |-------------------Acct Start (Acct-Session-Id 1)--->
 |
 |<-QoS Change
 |
 |-------------------Acct Stop (Acct-Session-ID 1) --->
 |                   Reporting usage on original QoS
 |-------------------Acct Start (Acct-Session-ID 2) --->
 |                   Starting to record usage on  new QoS
 |
=20
[Avi] Also I don't want to dig through accounting message to find the
current Acct-Session Id

[Avi] And accounting may not be used.

[Avi] And accounting may be delayed.  Accounting is not realtime. And
using information from the accounting stream is  not a good idea.  Hence
I like the logoff draft.

> If I only inlcude the User Identity (NAI, CUI, or some other identity)

> then I want to effect the user session being identified which may=20
> inlcude all of the users IP sessions and all the flows etc...

  Yes.  That's a wonderful idea.  So... why can't the NAS include an
Acct-Session-Id in the Access-Request, in conjunction with the NAI?  Any
request to affect the "user session" would then just use that
Acct-Session-Id.

[Avi] That is just a bad handle.  It can only have one Acct-Session-ID
that may only be valid for a short time.  Acct-Session-Id is used for
correlating a Start and a Stop.

> If I inlcude the Acct-Mutli-Session-Id attribute, then I want to=20
> effect all the sessions that are being identitified by the=20
> Acct-Multi-Session-Id.

  Yes.  That's a wonderful idea.

> If I include the Acct-Session-Id attribute then I want only to effect=20
> the session that is being identified by that handle.

  Yes, that's a wonderful idea.

> If I inlcude the Framed-IP-Address, then I want to effect the sessions

> that are identified by the IP address (IPv4 or IPv6)

  And there's the problem.  Those IPv4 sessions don't exist in a vacuum.
 Are you really saying that the CoA client will try to change a session
where it *only* knows the IP address?  That looks to me like an open
invitation to a security attack.

[Avi] No. It can include the CUI, NAI and the IP-Session.  And do you
think that an attacker that can inject a COA with an IP-address cant
find the CUI and NAI to include in the message as well?  Be real, this
only works in the security model of AAA.

  Also, you still haven't addressed the point where you can't use the IP
address as both a key, and an update attribute.  If the IP "session" has
an Acct-Session-Id associated with it, they key is Acct-Session-Id, and
the updated information is the Framed-IP-Address.

[Avi] I have never run across a case where I need to update the IP
address. If I were to run into such a case I would create another
attribute called newIPAddress. But I have run into many situartion where
I a given User session has multiple IP sessions, and I need to modify a
specific IP session.

  On top of that, your rules above for using "CUI, or NAI, or
Acct-Multi-Session-Id, or Acct-Session-Id, or Framed-IP-Address" are
guaranteed to prevent interoperability.  The CoA client will have NO
IDEA what it's supposed to send to affect a session.

[Avi] Not true. The COA will have all the information it needs to modify
the a specific session or subsession.  You use the attributes like a
path to drill down to a specific session: Here is an example:
/username or Acct-Multi-Session-id or CUI/framedIp : to effect an IP
session of a given user.

  That's what keys are for: they act as unique identifiers, independent
of the data being updated.

> There may even be some VSA that can be used as well....

  If we allow that, we've given up on interoperability.

[avi] In the general case yes.  But an SDO may want to do just that. We
always need to allow folks to extend the protocol.

> Which as i pointed out only works in very simple cases. And in some=20
> cases Acct-Session-Id is totally useless.

  Then the NAS needs to be fixed to generate a useful Acct-Session-Id.

[Avi] That is not acceptable to me at all.  Its okay perhaps in an
simple enterprise model. But does not work in my world at all.

  If there are "sessions" you need to refer to that are not authorized
or authenticated via RADIUS, then my suggestion would be that using
RADIUS to change those "sessions" is flat-out wrong.  You're trying to
get RADIUS to control pieces of the network that it doesn't even know
exists, which is always difficult.

[Avi] I disagree.  An access request can download policy or
authorization to create session at the NAS. Each one of these session
will have its own Accounting Stream ie its own Start/Stop with its own
Acctounting Session ID.

[Avi]Also Alan, you can have Accounting without
Authentication/Authorization.  There are many deployements that use
RADIUS Accounting without RADIUS Authentication/Authorization. And
perhaps -- and I know you wont like this at all, COA/DM without RADIUS
Authetnication/Authorization.  But I am not asking the IETF to
standerdize that. Just don't prohibit it.

> Bernard wrote:  "Actually, it seems like it might make it unnecessary=20
> to use an IP address as a session identification attribute."
>=20
> IMO are not appropriate because they are useful in only some=20
> deployements.

  If the session involves RADIUS knowing about a Framed-IP-Address, then
the Acct-Session-Id can be included in the protocol flow, and it can be
used as a key instead.  If the session does not involve RADIUS knowing
about a Framed-IP-Address, then RADIUS should not be used for session
change control.

[Avi] No. Because in the case of flow based accounting, the
Acct-Session-ID identifies a flow and not necessarily the IP session.
So if you want to kill the IP session you could only do that by killing
all the flows.  Not a good idea since you would have to search through
rims of accounting messages, and these may arrive a day later at the AAA
server, or not at all if the no accounting is used.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 20:14:24 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Wed, 30 May 2007 16:12:28 -0400
Organization: Elbrys Networks, Inc.

Avi Lior writes...
 
> [Avi] In WiMAX the AAA sends a session id to the NAS in an Access
> Accept, this session ID is then sent in any Access-Requests associated
> with that user. It can also be sent in COA/DM messages.

Where is this behavior documented?  What attribute is used?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 20:07:06 +0000
Subject: RE: RFC3576bis and Session State
Date: Wed, 30 May 2007 16:06:22 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, <[email-masked]>

Hi Alan,
=20

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]=20
Sent: Tuesday, May 29, 2007 4:39 AM
To: Avi Lior
Cc: David B. Nelson; [email-masked]
Subject: Re: RFC3576bis and Session State

Avi Lior wrote:
>   Which is why I didn't suggest that the server receive accounting=20
> messages.  What I said was that it should receive a=20
> protocol-independent session identification key... sometimes called
Acct-Session-Id.
>=20
> [Avi] Yes but it can only receive one and there can be many Accounting

> Session Ids, and they can change.

  Then we need a new session identification attribute that doesn't
change.

[Avi] Yes we have done that in WIMAX and in 3GPP2.  In WiMAX we have a
session key for the entire user session.  It is generated by the AAA and
sent to the NAS.  The NAS includes it in all subsequent AAA exchanges
and puts it in the Accounting as Acct-Multi-Session ID.  It also
survives mobility, that is when the MS hands off to another NAS and
reauthentication takes place, the same AAA session id is returned from
the HAAA to the new NAS.  And thus, we can correlate accounting that is
generated across different NASes.

[Avi] But note that this session id is *not* really required for COA or
DM. We can use NAI or CUI.  It is useful for other reasons and could be
usefull for COA and DM.  Again I designed this Session Key into WiMAX so
I cant really argue against this.

> [Avi] It may want to kill all the "sessions" that are associated with=20
> a given User Identity.  The po0int of the above is that there are many

> things you can call a "session". You seem to focus on only one of them

> which is a session represented by a Start/Stop record.

  No.  I'm focusing on a session key that is independent of protocol,
NAI, CUI, or anything else.  If you pick an attribute that MAY be used
as a key, I can pick a scenario where that attribute does not exist, and
is therefore useless for CoA.

  We can say that the RADIUS server trolls through it's database,
looking for an attribute that *might* be a session key, or we can say
that the RADIUS server uses the session key sent to it by the NAS.  I
have my belief about which one is simpler to implement, deploy, and be
interoperable.

[Avi] I agree. But this Session Key is not enough.  It can only be used
to effect the entire user session.  If you want to effect or target
other sessions (sub-sessions for a lack of a better term), such as IP
sessions etc, you need another identifier to classify the COA/DM
message.

[Avi] In WiMAX the AAA sends a session id to the NAS in an Access
Accept, this session ID is then sent in any Access-Requests associated
with that user. It can also be sent in COA/DM messages.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 18:32:33 +0000
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Wed, 30 May 2007 14:31:39 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "David B. Nelson" <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>

See inline...=20

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]=20
Sent: Wednesday, May 30, 2007 3:59 AM
To: Avi Lior
Cc: Bernard Aboba; David B. Nelson; [email-masked]; Bernard
Aboba
Subject: Re: Issue 226: RFC 3576bis and Renumbering

Avi Lior wrote:
> [Avi] Yes I agree that it "can" be used.  But Alan seems to make it=20
> mandatory.

  To clarify: If Acct-Session-Id is improper for any reason, we should
create a new session identification attribute specifically for this use.

[Avi] It is in WiMAX and 3GPP2.  Hence we invented a correaltion-id in
3GPP2 and in WiMAX.  These attributes are placed in
Acct-Multi-Session-Id.  In these SDO we can contorl (DM,COA) the
'sessions' using these attributes and other paramets such as IP address
etc. There is no need for Acct-Session-Id other then to correlate
Start,Interims,Stop.

I don't think we need to add a new attribute.

> [Avi] I agree that the IP Address is not *required*.  I think that=20
> nothing should be *required*  because different scenarios will use=20
> different session identifiers.

  How does the CoA client know what to send as session identifiers?  How
does the recipient of the CoA message know what to do, given that the
session identifiers you talk about can apply to many sessions?

[Avi] The COA Client will send the session identifiers that are
appropriate to identify the session it wants to control (DM.COA)

So here are some examples:

[1] If the COA/DM Client sends just the User Identity (CUI and/or NAI)
and/or some other identity that identifies the subscription session (in
WiMAX it's the AAA-Session-ID) Then the COA/DM Server will effect or
delete all the 'sessions' that are associated with that user. =20

[2] If the COA/DM Client, in addtion to one sends includes an IP
address, then only the IP session associated with that subscription will
be modified.

[3] If the COA/DM Client, in addition to [2] Includes a flow-id (in
WiMAX PDFID) then only the flow(s) associated with that IP Session
(identified in [2]) of the Subscription (identified in[1]) will be
modified/deleted.

  My proposal involves  mandating a new session key.  This key ensures
that everyone agrees which session the CoA request applies to.  I would
recommend *also* using Acct-Session-Id, because it applies to the
individual sessions you want to control.

[Avi] Sorry.  Not needed. It works fine as you can see/

  Every single session you want to control can be individually addressed
using those two keys.  There is no need for a guesswork: "try CUI, or
maybe Framed-IP-Address, or maybe something else will work".

[Avi] We have all the identifiers we need. What makes you think that
another session identifier will help? I don't get it!  What I described
above is very deterministic.  We have this already working.

  If those two keys are NOT sufficient, then I again question how RADIUS
is being used to control sessions it knows nothing about.

[Avi] Can you please show me in the examples I gave you where RADIUS is
asked to control session it is not aware of?

>  Furthermore, I think they should be used in combination.  For=20
> example, User-Name + Accounting Session Id to delete the session=20
> associated with Accounting session id is better practice then just=20
> using Accounting Session Id.

  And for sessions that don't have User-Name, which attribute do you
choose, and why?  That's why I suggest using a new key.  It avoids all
of the problems with guessing which attribute will be accepted by the
NAS as a session key.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 13:54:06 +0000
Date: Wed, 30 May 2007 15:53:54 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue 226:  RFC 3576bis and Renumbering

David B. Nelson wrote:
> Yes, but you'd need Accounting START messages, as well.

  Yes.  But no interim updates, and no normal accounting activities.

> While I agree that one _could_ start sending Accounting-Request messages to
> RADIUS Servers, that seems to be a muddling of the authentication and
> authorization vs. accounting roles.

  There are a lot of startups in the Bay Area building multi-protocol
equipment and doing cross-protocol user identity management.  So
muddling roles isn't a new idea.  In this case, all we're really saying
is that for CoA, it's best for all A's in AAA to be co-resident.

  There's no need for the NAS to generate the accounting messages,
either.  The accounting server could just as easily send the
notifications to the authentication server, if they're not co-resident.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 13:35:52 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Wed, 30 May 2007 09:33:23 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   It would be just as easy to update implementations to permit
> accounting STOP messages to be sent to authentication servers.  Some
> implementations already support this.  It doesn't require a new command,
> and it has all of the features of the logoff draft.

Yes, but you'd need Accounting START messages, as well.  With all due
respect to Glen, his draft is oddly named, as it encompasses more than
notification of session termination.  It also includes notification of
session origination, presumably including sessions that were spontaneously
created at the NAS without the benefit of a directly corresponding
Access-Request/Accept exchange.

While I agree that one _could_ start sending Accounting-Request messages to
RADIUS Servers, that seems to be a muddling of the authentication and
authorization vs. accounting roles.  Maybe that is acceptable for the
special case of Dynamic RADIUS support.  What do others think?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 13:17:27 +0000
Date: Wed, 30 May 2007 15:17:24 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue 226:  RFC 3576bis and Renumbering

David B. Nelson wrote:
> Actually, I take that back.  One possible answer has been mentioned briefly
> in this thread, Glen's "logoff" draft
> http://www.ietf.org/internet-drafts/draft-zorn-radius-logoff-09.txt
> which allows a NAS to send messages to the RADIUS Server, and a co-located
> Dynamic Authorization Client, indicating the beginning and end of sessions.
> We have not discussed this draft in RADEXT because it relies on new RADIUS
> command codes, which are currently out of scope.

  It would be just as easy to update implementations to permit
accounting STOP messages to be sent to authentication servers.  Some
implementations already support this.  It doesn't require a new command,
and it has all of the features of the logoff draft.

  i.e. "A RADIUS authentication server MAY choose to accept
Accounting-Request packets contain Acct-Status-Type = Stop.  These
requests SHOULD be treated as a notification from the NAS that the
session has terminated.  The authentication server SHOULD update any
session database it maintains, to indicate that the session has stopped,
and then reply with an Accounting-Response packet.  The authentication
server SHOULD NOT perform any other activities normally performed by an
accounting server.  If the authentication server does not maintain a
session database, it SHOULD reply with an Accounting-Response packet,
and take no other action."

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 13:08:07 +0000
Date: Wed, 30 May 2007 15:08:05 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue 226:  RFC 3576bis and Renumbering

David B. Nelson wrote:
> Glen Zorn reminds us that there are implementations in which the NAS
> responds to a user request for an additional service, based on the broad
> authorization contained in previous Access-Accept, creating a new service
> session and a new Acct-Session-Id, without ever sending a new
> Access-Request.  Only the RADIUS Accounting server would have seen the new
> value of Acct-Session-Id.

  I will re-phrase that as: The CoA client can send a CoA request for a
session when it has not seen any (or all) RADIUS traffic for that session.

  Since the CoA client isn't party to the RADIUS traffic, it's likely
that the RPF checks described elsewhere in the document will fail.
Perhaps a better solution is to have what would otherwise be the CoA
client send the packet to a RADIUS server for forwarding, rather than
contacting the NAS itself.

  i.e. if the CoA client is in the same administrative domain as the
RADIUS servers, then the RADIUS server MAY bypass its RPF checks.

> Avi Lior reminds us that implementers would like to use identifying
> attributes as a set of "match filters" to select a group of sessions (i.e. a
> group of Acct-Session-Id values) for action.

  That is a very useful feature.

> Glen Zorn reminds us that the semantics of session attribute identification
> is likely to be extended and further defined in documents from non-IETF
> SDOs, covering particular application areas.

  That would be a very useful feature.  But it's not required if the
session identifiers are protocol-independent RADIUS attributes.

> While only the market can validate whether these extended notions of session
> identification are good ideas, it's probably not appropriate to prohibit
> them in RFC3576bis.

  I agree.  Prohibiting them is bad.  Requiring ONLY them is just as bad.

>  I recommend that we define some base session
> identification attributes for "generic", RFC2865-style RADIUS sessions, and
> make them SHOULDs or MAYs in RFC3576bis.

  I prefer MUST over SHOULD, and SHOULD over MAY.

>  I further recommend that we add
> some text indicating that other documents, covering specific areas of
> application, may in the future recommend or require different sets of
> session identifier attributes.

  I'll see if I can come up with something acceptable.

> We should also acknowledge, for the benefit of the reader, that the nature
> of RADIUS "session" definition, i.e. concurrent, sequential and nested
> service provisioning, is not well standardized, and that the session ID
> attribute (whatever its name) included in the Access-Request messages may
> not describe all of the actual sessions that CoA-Request or
> Disconnect-Request messages may wish to address. 

  It's OK if that identifier doesn't describe all of the sessions.  It's
only necessary that the identifer act as a key to limit the scope of the
per-session and protocol-specific identifiers.

> The only alternative to
> this, IMHO, is to restrict session creation in the NAS to a one-to-one
> relationship with Access-Request messages (i.e. vanilla RADIUS as it existed
> in the 1980's).  I suspect that will meet with some resistance.

  I like that idea, but recognize that it's unworkable.

>>   If those two keys are NOT sufficient, then I again question how RADIUS
>> is being used to control sessions it knows nothing about.
> 
> Secret sauce?  That is a very valid question, to which I'm sure there is an
> answer.  I'm equally sure that it hasn't been provided in this thread.  :-)

  Well, yes.  I understand it's useful for an IDS box to send a
Disconnect-Request to a NAS.  But the IDS has no inter-operable way of
knowing that it's idea of a session matches the NAS's idea of a session.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 13:00:51 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Wed, 30 May 2007 08:59:32 -0400

Amending my last post...

> Secret sauce?  That is a very valid question, to which I'm 
> sure there is an answer.  I'm equally sure that it hasn't been 
> provided in this thread.  :-)

Actually, I take that back.  One possible answer has been mentioned briefly
in this thread, Glen's "logoff" draft
http://www.ietf.org/internet-drafts/draft-zorn-radius-logoff-09.txt
which allows a NAS to send messages to the RADIUS Server, and a co-located
Dynamic Authorization Client, indicating the beginning and end of sessions.
We have not discussed this draft in RADEXT because it relies on new RADIUS
command codes, which are currently out of scope.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 12:32:26 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Wed, 30 May 2007 08:30:33 -0400

Alan DeKok writes...

>   To clarify: If Acct-Session-Id is improper for any reason, we should
> create a new session identification attribute specifically for this use.

>   How does the CoA client know what to send as session identifiers?  How
> does the recipient of the CoA message know what to do, given that the
> session identifiers you talk about can apply to many sessions?
> 
>   My proposal involves  mandating a new session key.  This key ensures
> that everyone agrees which session the CoA request applies to.  I would
> recommend *also* using Acct-Session-Id, because it applies to the
> individual sessions you want to control.

I find this proposal satisfying, because it regularizes the process, and
makes it much more likely that two implementations will interoperate,
providing exactly the same behavior.

Having expressed that personal preference, I acknowledge that some of our
colleagues envision a more complex and less regular process.

Glen Zorn reminds us that there are implementations in which the NAS
responds to a user request for an additional service, based on the broad
authorization contained in previous Access-Accept, creating a new service
session and a new Acct-Session-Id, without ever sending a new
Access-Request.  Only the RADIUS Accounting server would have seen the new
value of Acct-Session-Id.

Avi Lior reminds us that implementers would like to use identifying
attributes as a set of "match filters" to select a group of sessions (i.e. a
group of Acct-Session-Id values) for action.

Glen Zorn reminds us that the semantics of session attribute identification
is likely to be extended and further defined in documents from non-IETF
SDOs, covering particular application areas.

While only the market can validate whether these extended notions of session
identification are good ideas, it's probably not appropriate to prohibit
them in RFC3576bis.  I recommend that we define some base session
identification attributes for "generic", RFC2865-style RADIUS sessions, and
make them SHOULDs or MAYs in RFC3576bis.  I further recommend that we add
some text indicating that other documents, covering specific areas of
application, may in the future recommend or require different sets of
session identifier attributes.

Making Acct-Session-Id or something very like it a SHOULD, is a good idea.

We should also acknowledge, for the benefit of the reader, that the nature
of RADIUS "session" definition, i.e. concurrent, sequential and nested
service provisioning, is not well standardized, and that the session ID
attribute (whatever its name) included in the Access-Request messages may
not describe all of the actual sessions that CoA-Request or
Disconnect-Request messages may wish to address. The only alternative to
this, IMHO, is to restrict session creation in the NAS to a one-to-one
relationship with Access-Request messages (i.e. vanilla RADIUS as it existed
in the 1980's).  I suspect that will meet with some resistance.

>   If those two keys are NOT sufficient, then I again question how RADIUS
> is being used to control sessions it knows nothing about.

Secret sauce?  That is a very valid question, to which I'm sure there is an
answer.  I'm equally sure that it hasn't been provided in this thread.  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 30 May 2007 08:00:07 +0000
Date: Wed, 30 May 2007 09:59:01 +0200
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "David B. Nelson" <[email-masked]>, [email-masked], Bernard Aboba <[email-masked]>
Subject: Re: Issue 226:  RFC 3576bis and Renumbering

Avi Lior wrote:
> [Avi] Yes I agree that it "can" be used.  But Alan seems to make it
> mandatory.

  To clarify: If Acct-Session-Id is improper for any reason, we should
create a new session identification attribute specifically for this use.

> [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.

  How does the CoA client know what to send as session identifiers?  How
does the recipient of the CoA message know what to do, given that the
session identifiers you talk about can apply to many sessions?

  My proposal involves  mandating a new session key.  This key ensures
that everyone agrees which session the CoA request applies to.  I would
recommend *also* using Acct-Session-Id, because it applies to the
individual sessions you want to control.

  Every single session you want to control can be individually addressed
using those two keys.  There is no need for a guesswork: "try CUI, or
maybe Framed-IP-Address, or maybe something else will work".

  If those two keys are NOT sufficient, then I again question how RADIUS
is being used to control sessions it knows nothing about.

>  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.  

  And for sessions that don't have User-Name, which attribute do you
choose, and why?  That's why I suggest using a new key.  It avoids all
of the problems with guessing which attribute will be accepted by the
NAS as a session key.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 29 May 2007 19:50:49 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-07.txt 
Date: Tue, 29 May 2007 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: M. Chiba, et al.
	Filename	: draft-ietf-radext-rfc3576bis-07.txt
	Pages		: 36
	Date		: 2007-5-29
	
This document describes a currently deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, allowing
   dynamic changes to a user session, as implemented by network access
   server products.  This includes support for disconnecting users and
   changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-rfc3576bis-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 29 May 2007 17:27:13 +0000
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 29 May 2007 13:26:09 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7A216.A53D383B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Bernard,

________________________________

From: Bernard Aboba [mailto:[email-masked]]=20
Sent: Saturday, May 26, 2007 12:04 PM
To: Alan DeKok; Avi Lior
Cc: David B. Nelson; [email-masked]; Bernard Aboba
Subject: RE: Issue 226: RFC 3576bis and Renumbering

> Date: Sat, 26 May 2007 15:46:46 +0100
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked];
[email-masked]
> Subject: Re: Issue 226: RFC 3576bis and Renumbering
>=20
> 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.
>=20
> I see what you're saying, but I'm not sure I agree. The=20
> Acct-Session-Id defines a session that the Acct-Session-Id refers to.=20
> It's a circular reference, but not much else is true.
>=20
> The problem at hand, I think, is less Acct-Session-Id than in=20
> figuring out what the CoA packet refers to. My proposal is to key the=20
> CoA to a session Id (whatever it's called), which now allows the CoA
to=20
> request changes to other portions of the session.
>=20
> If we key off of IP/port, then as Bernard pointed out, we can't send=20
> Framed-IP-Address as both a session key and as an indication to "use=20
> this new value".
>=20
> > When it comes to 3576 and DM or even COA:
> >=20
> > 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.
> >=20
> > 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.
>=20
> Using IP's as a key to terminate a session is fine. Using them as a=20
> 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. =20
[Avi] Correct.
=20
[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] =20
[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.
=20
[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.=20

[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.
=20
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). =20
[Avi] Yes I agree and even VSAs.=20

[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.=20
[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. =20

>=20
> Alan DeKok.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C7A216.A53D383B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D666361715-29052007>Hi=20
Bernard,</SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<B>From:</B> Bernard Aboba [mailto:[email-masked]] =
<BR><B>Sent:</B>=20
Saturday, May 26, 2007 12:04 PM<BR><B>To:</B> Alan DeKok; Avi =
Lior<BR><B>Cc:</B>=20
David B. Nelson; [email-masked]; Bernard =
Aboba<BR><B>Subject:</B> RE:=20
Issue 226: RFC 3576bis and Renumbering<BR><BR></DIV>
<DIV></DIV>
<DIV><BR><BR>&gt; Date: Sat, 26 May 2007 15:46:46 +0100<BR>&gt; From:=20
[email-masked]<BR>&gt; To: [email-masked]<BR>&gt; CC:=20
[email-masked]; [email-masked];=20
[email-masked]<BR>&gt; Subject: Re: Issue 226: RFC =
3576bis and=20
Renumbering<BR>&gt; <BR>&gt; Avi Lior wrote:<BR>&gt; &gt; Accounting =
Session ID=20
only identifies an accounting session Start/Stop<BR>&gt; &gt; and its =
interims,=20
if any. A given "session" (IP Session or<BR>&gt; &gt; Access-Session) =
may=20
contain a number of parallel accounting sessions, or<BR>&gt; &gt; a =
sequence of=20
accounting sessions.<BR>&gt; <BR>&gt; I see what you're saying, but I'm =
not sure=20
I agree. The <BR>&gt; Acct-Session-Id defines a session that the =
Acct-Session-Id=20
refers to. <BR>&gt; It's a circular reference, but not much else is=20
true.<BR>&gt; <BR>&gt; The problem at hand, I think, is less =
Acct-Session-Id=20
than in <BR>&gt; figuring out what the CoA packet refers to. My proposal =
is to=20
key the <BR>&gt; CoA to a session Id (whatever it's called), which now =
allows=20
the CoA to <BR>&gt; request changes to other portions of the =
session.<BR>&gt;=20
<BR>&gt; If we key off of IP/port, then as Bernard pointed out, we can't =
send=20
<BR>&gt; Framed-IP-Address as both a session key and as an indication to =
"use=20
<BR>&gt; this new value".<BR>&gt; <BR>&gt; &gt; When it comes to 3576 =
and DM or=20
even COA:<BR>&gt; &gt; <BR>&gt; &gt; We need to be able to terminate or =
modify=20
the Session WRT to A. That<BR>&gt; &gt; is, sending a DM with an NAI or =
some=20
other user identification, we<BR>&gt; &gt; terminate all of the users IP =

sessions.<BR>&gt; &gt; <BR>&gt; &gt; We need to be able to terminate or =
modify=20
any of the users IP sessions.<BR>&gt; &gt; Therefore sending a DM which =
includes=20
a user identification and an IP<BR>&gt; &gt; address will only terminate =
that=20
users IP session.<BR>&gt; <BR>&gt; Using IP's as a key to terminate a =
session is=20
fine. Using them as a <BR>&gt; key *and* as a "new value" in a change =
request is=20
not.<BR><BR>[BA] It would be somewhat complicated to define a different =
set of=20
session identification attributes for CoA and Disconnect-Requests.&nbsp; =

<BR><SPAN class=3D666361715-29052007>[Avi]&nbsp;Correct.</SPAN></DIV>
<DIV><SPAN class=3D666361715-29052007></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D666361715-29052007>[BA]&nbsp;</SPAN>Also, unless the =
NAS=20
previously received Framed-IP-Address or =
Framed-IPv6-Prefix/Framed-Interface-Id=20
attributes in an Access-Accept it typically will not know the user's IP=20
address.&nbsp; This is the situation with most NAS-Port-Type values, =
with the=20
exception of PPP or protocols depending on PPP (e.g. PPPOE, PPPOA, L2TP, =
PPTP,=20
etc.)<BR><SPAN =
class=3D666361715-29052007>[Avi]&nbsp;&nbsp;</SPAN><BR><SPAN=20
class=3D666361715-29052007>[Avi]&nbsp;&nbsp;In most cases that I am =
aware of, the=20
NAS is the Point of Attachement to the internet and it knows the IP =
address(es)=20
assigned to the user. So it is IP Session aware.&nbsp; In any case, =
there are=20
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=20
Session Identifier.</SPAN><BR><SPAN=20
class=3D666361715-29052007>&nbsp;</SPAN><BR><SPAN=20
class=3D666361715-29052007>[BA]&nbsp;</SPAN>Where an Access-Request was =
received=20
with an Acct-Session-Id or an Accounting-Request is received, the=20
Acct-Session-Id can be used as the session identifier. <BR><SPAN=20
class=3D666361715-29052007></SPAN></DIV>
<DIV><SPAN class=3D666361715-29052007>[Avi]&nbsp;Yes I agree that =
it&nbsp;"can" be=20
used.&nbsp; But Alan seems to make it mandatory. And to mandatory =
require that=20
it be sent in&nbsp;the&nbsp;Access-Request&nbsp;packet.&nbsp; I dont =
agree with=20
that.&nbsp; I think&nbsp;if the deployement requires it to be in the =
access=20
request then it can be sent.&nbsp;&nbsp;The current RFCs are =
fine.</SPAN></DIV>
<DIV><SPAN class=3D666361715-29052007></SPAN><SPAN=20
class=3D666361715-29052007>&nbsp;</SPAN><BR>Where only an Access-Request =
is=20
available, with no Acct-Session-Id, other session identification =
attributes can=20
be used (NAS-Port/NAS-Port-Id, User-Name).&nbsp; <BR><SPAN=20
class=3D666361715-29052007>[Avi]&nbsp;Yes I agree and even=20
VSAs.&nbsp;</SPAN><BR><BR><SPAN =
class=3D666361715-29052007>[BA]&nbsp;</SPAN>So=20
it's hard to imagine a case where the IP address is *required* as a =
session=20
identifier.&nbsp;&nbsp; And there are quite a few situations in which =
the NAS=20
will be unable to identify the session by IP address.&nbsp;&nbsp; Given =
this,=20
encouraging the use of the IP address as a session identifier seems like =
a bad=20
idea. <BR><SPAN class=3D666361715-29052007>[Avi] I agree that the IP =
Address is=20
not *required*.&nbsp; I think that nothing should=20
be&nbsp;*required*&nbsp;&nbsp;because different scenarios will use =
different=20
session identifiers.&nbsp;&nbsp;Furthermore, I think they should be used =
in=20
combination.&nbsp; For example, User-Name + Accounting Session =
Id&nbsp;to delete=20
the session associated with Accounting session id is better practice =
then just=20
using&nbsp;Accounting Session Id.&nbsp;&nbsp;</SPAN><BR><BR>&gt; =
<BR>&gt; Alan=20
DeKok.<BR>&gt; <BR>&gt; --<BR>&gt; to unsubscribe send a message to=20
[email-masked] with<BR>&gt; the word 'unsubscribe' in a =
single=20
line as the message text body.<BR>&gt; archive:=20
&lt;http://psg.com/lists/radiusext/&gt;<BR></DIV></BODY></HTML>

------_=_NextPart_001_01C7A216.A53D383B--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 29 May 2007 08:55:39 +0000
Date: Tue, 29 May 2007 10:55:21 +0200
From: Alan DeKok <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
CC: Avi Lior <[email-masked]>,  "David B. Nelson" <[email-masked]>, [email-masked]
Subject: Re: RFC3576bis and Session State

Glen Zorn (gwz) wrote:
> I think the point is that there may be multiple accounting sessions
> (either serial or parallel) authorized by a single
> Access-Request/-Reply, all with different session IDs and maybe even
> members of different groups (so different Acct-Multi-Session-IDs, so
> unless the RADIUS server receives _all_ the stop and stop records it
> can't know about those.

  Then we need a new session key, independent of other keys.

>  Are we saying then, that _only_ the original
> session may be affected by CoA?  If so, maybe it would be better to have
> a session-ID specifically for that instead of overloading the
> Acct-Session-ID attribute.  

  I want CoA to be as flexible as possible.  i.e. Contain many
attributes to define what it is changing.

  I want CoA to be inter-operable, and implementable.  i.e. Define a key
for CoA that does not involve guessing what the NAS might think is a
unique session identifier.

> So is using the accounting session ID, for the reasons outlined above.

  Then we define a new session identification attribute.  Maybe
Acct-Multi-Session-Id can be used, as it appears to be defined as an
aggregation point for multiple sessions.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 29 May 2007 08:39:41 +0000
Date: Tue, 29 May 2007 10:39:23 +0200
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  [email-masked]
Subject: Re: RFC3576bis and Session State

Avi Lior wrote:
>   Which is why I didn't suggest that the server receive accounting
> messages.  What I said was that it should receive a protocol-independent
> session identification key... sometimes called Acct-Session-Id.
> 
> [Avi] Yes but it can only receive one and there can be many Accounting
> Session Ids, and they can change.  

  Then we need a new session identification attribute that doesn't change.

> [Avi] It may want to kill all the "sessions" that are associated with a
> given User Identity.  The po0int of the above is that there are many
> things you can call a "session". You seem to focus on only one of them
> which is a session represented by a Start/Stop record.

  No.  I'm focusing on a session key that is independent of protocol,
NAI, CUI, or anything else.  If you pick an attribute that MAY be used
as a key, I can pick a scenario where that attribute does not exist, and
is therefore useless for CoA.

  We can say that the RADIUS server trolls through it's database,
looking for an attribute that *might* be a session key, or we can say
that the RADIUS server uses the session key sent to it by the NAS.  I
have my belief about which one is simpler to implement, deploy, and be
interoperable.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 29 May 2007 08:33:28 +0000
Date: Tue, 29 May 2007 10:33:20 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC3576bis and Session State

Bernard Aboba wrote:
> How is this? 
>  
> "A NAS implementing this specification SHOULD send an Acct-Session-Id
> or Acct-Multi-Session-Id Attribute within an Access-Request.
> Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
> included within an Access-Request, the Dynamic Authorizatoin Client
> will not know the Acct-Session-Idor Acct-Multi-Session-Id of the
> session it is attempting to target,unless it also has access to
> the accounting data for that session.

  The discussion on this list is about using a session identification
attribute AND other attributes, versus ONLY using other attributes.

  I'm convinced that a session identification attribute is a MUST.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 29 May 2007 08:31:03 +0000
Date: Tue, 29 May 2007 10:10:09 +0200
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: RFC3576bis and Session State

Avi Lior wrote:
> What session identifiers I include in the COA or DM message should
> indicate what I want to effect.

  The word "session" is being used in multiple contradictory ways.  Your
previous message indicated that one login "session" may result in
multiple Acct-Session-Id's.  In that case, keying off of Acct-Session-Id
to change a session would make sense.

  You now seem to be saying that sessions are *independent* of
Acct-Session-Id's, and that you do *not* want to use Acct-Session-Id as
a key for a session, but rather something else.

> If I only inlcude the User Identity (NAI, CUI, or some other identity)
> then I want to effect the user session being identified which may
> inlcude all of the users IP sessions and all the flows etc...

  Yes.  That's a wonderful idea.  So... why can't the NAS include an
Acct-Session-Id in the Access-Request, in conjunction with the NAI?  Any
request to affect the "user session" would then just use that
Acct-Session-Id.

> If I inlcude the Acct-Mutli-Session-Id attribute, then I want to effect
> all the sessions that are being identitified by the
> Acct-Multi-Session-Id.

  Yes.  That's a wonderful idea.

> If I include the Acct-Session-Id attribute then I want only to effect
> the session that is being identified by that handle.

  Yes, that's a wonderful idea.

> If I inlcude the Framed-IP-Address, then I want to effect the sessions
> that are identified by the IP address (IPv4 or IPv6)

  And there's the problem.  Those IPv4 sessions don't exist in a vacuum.
 Are you really saying that the CoA client will try to change a session
where it *only* knows the IP address?  That looks to me like an open
invitation to a security attack.

  Also, you still haven't addressed the point where you can't use the IP
address as both a key, and an update attribute.  If the IP "session" has
an Acct-Session-Id associated with it, they key is Acct-Session-Id, and
the updated information is the Framed-IP-Address.

  On top of that, your rules above for using "CUI, or NAI, or
Acct-Multi-Session-Id, or Acct-Session-Id, or Framed-IP-Address" are
guaranteed to prevent interoperability.  The CoA client will have NO
IDEA what it's supposed to send to affect a session.

  That's what keys are for: they act as unique identifiers, independent
of the data being updated.

> There may even be some VSA that can be used as well....

  If we allow that, we've given up on interoperability.

> Which as i pointed out only works in very simple cases. And in some
> cases Acct-Session-Id is totally useless.

  Then the NAS needs to be fixed to generate a useful Acct-Session-Id.

  If there are "sessions" you need to refer to that are not authorized
or authenticated via RADIUS, then my suggestion would be that using
RADIUS to change those "sessions" is flat-out wrong.  You're trying to
get RADIUS to control pieces of the network that it doesn't even know
exists, which is always difficult.

> Bernard wrote:  "Actually, it seems like it might make it unnecessary to
> use an IP address as a session identification attribute."
> 
> IMO are not appropriate because they are useful in only some
> deployements.

  If the session involves RADIUS knowing about a Framed-IP-Address, then
the Acct-Session-Id can be included in the protocol flow, and it can be
used as a key instead.  If the session does not involve RADIUS knowing
about a Framed-IP-Address, then RADIUS should not be used for session
change control.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 29 May 2007 08:24:42 +0000
Date: Tue, 29 May 2007 10:23:43 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC3576bis and Session State

David B. Nelson wrote:
> Glen Zorn writes...
> 
>> Not necessarily.  For example, I can imagine that an SDO other than the
>> IETF might decide what constitutes a "session" for their system.  I
>> think that that qualifies as "deployment-specific", with a market
>> possibly significant enough to warrant manufacturing customization.
> 
> Ah, I see.

  If RADIUS does AAA for a session, it has access to a session key such
as Acct-Session-Id.  If RADIUS does not do AAA for a session, I'm
unclear as to why RADIUS should be used for CoA of that session.

  I think the difficulty is one of terminology, rather than anything
else.  When I say I want to use a session ID as a key, I do NOT mean I
want to forbid using any other attributes to narrowly define a portion
of the session to change.  What I mean is that using ONLY those other
attributes is completely wrong.

  Here's a nice test case:  A switch has multiple ports, all
authenticated, etc. through RADIUS.  The authentication and accounting
servers are co-resident, and co-resident with the CoA client.  The
policy of the RADIUS server puts users into multiple VLANs, each with a
private network space, as follows:

    user A, port 1, VLAN 10, IP 192.168.1.2, Acct-Session-Id YYZ
    user B, port 2, VLAN 20, IP 192.168.1.2, Acct-Session-Id AAB

  The CoA client now wants to change a parameter associated with one of
the users.

  Is the problem obvious yet?

  How does the RADIUS server know what key to use in the CoA request?
Following Avi's rules, the RADIUS server has a hard time figuring out
what it's supposed to do.

  If we ONLY use the Framed-IP-Address as a key in CoA requests, then
the NAS has no idea which login session it applies to.  We could use
NAI, but maybe the user has logged in via two ports, and is trying to
span the interfaces.

  In short, the ONLY choice to uniquely identify a session is a unique
session identifier that is independent of protocol, port, username, etc.

  That being said, we MUST also permit additional attributes in the CoA
request, which add fine-grained control over portions of the session.

> This still seems problematic for RFC 3576bis, however.  If we leave the
> selection of session "marker" attributes that need to appear in
> Access-Request and CoA-Request messages to support a particular application
> open ended, then we can't easily task someone to write a test plan to verify
> multi-vendor interoperability of RFC 3567bis, because the attribute
> selection is not deterministic, or at least not determined within the scope
> of the document.

  Exactly.  And as I pointed out above, those markers are ambiguous, and
unworkable in the absence of a session identification key.

> If we are looking at RFC 3576bis as simply a base document that is used by
> other SDO documents to form a complete solution, but that is not a complete,
> interoperable protocol unto itself, then let's at least say so.  I think it
> may be best to specify a minimum set of session "marker" attributes for
> generic RADIUS applications as SHOULDs in RFC 3567bis and indicate that
> there are an unlimited number of other session "marker" attributes that MAY
> appear, based on the requirements of other documents, e.g. from non-IETF
> SDOs.

  Given the confusion on this list, I would now say that using
Acct-Session-Id is a MUST.  The NAS MUST send it in Access-Request.  The
CoA client MUST send it in a CoA request.  Additional attributes MAY be
present, and are used to control sub-portions of a session.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 29 May 2007 01:03:57 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue: Attribute restriction
Date: Mon, 28 May 2007 18:02:55 -0700

I think it is trying to say is that the Access-Request SHOULD contain at le=
ast the NAS and session identification attributes.  It shouldn't be implyin=
g that no other attributes are permitted. =20

Can you think of a way to make this more clear?

For example, we could add "The Access-Request MAY also contain other attrib=
utes as needed."=20

________________________________
> Subject: RE: Issue: Attribute restriction
> Date: Mon, 28 May 2007 11:28:40 -0400
> From: [email-masked]
> To: [email-masked]; [email-masked]
>=20
> Bernard,
> Dont forget that in RADIUS Location Draft we want to include location inf=
ormation in this message.
> Recall, that if the NAS provided location information in an Access-Reques=
t (either because it was configured to do so, or because it received a chal=
lenge) then when issueing the Access-Request due to the receipt of COA (Aut=
horize-Only) we want it to also include the location information.  Thus thi=
s will avoid the AAA server from challenging it again to provide location i=
nformation.
> How do you want to deal with that?  Do we let that Draft specify this or =
do you want to align the draft.
> ________________________________
> From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Bernard Aboba
> Sent: Saturday, May 26, 2007 10:27 AM
> To: [email-masked]
> Subject: Issue: Attribute restriction
> Issue:  Attribute Restriction
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: May 26, 2007
> Reference:
> Document: RFC3576bis-06
> Comment type: Technical
> Priority: S
> Section: 3.2
> Rationale/Explanation of issue:
> Section 3.2 contains the following sentence:
>    This Access-Request SHOULD contain the NAS
>    identification attributes from the CoA-Request, as well as the
>    session identification attributes from the CoA-Request legal for
>    inclusion in an Access-Request as specified in [RFC2865], [RFC2868],
>    [RFC2869] and [RFC3162].
> This sentence appears to imply that only session identification attribute=
s
> from [RFC2865], [RFC2868], [RFC2869] and [RFC3162] can be included in the
> Access-Request.  In fact, RFC 3576bis adds Chargeable-User-Identity to th=
e
> list of session identification attributes; this is defined in a document
> that is not listed.
> The proposed resolution is to change this sentence to:
>    This Access-Request SHOULD contain the NAS
>    identification attributes from the CoA-Request, as well as the
>    session identification attributes from the CoA-Request legal for
>    inclusion in an Access-Request.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 21:24:39 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 12:57:22 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Monday, May 28, 2007 12:14 PM:

> Glen Zorn writes...
>=20
>> I'm saying that it is quite possible (& efficient) to authorize a
>> variety of services with a single Access-Accept, not all of which may
>> be instantiated simultaneously.
>=20
> Using a single Service-Type attribute?  Which one?  I'm not aware of
> any RADIUS service types that convey a multi-session connotation.=20

Service-Type is by no means the only way to signal service
authorization; in fact (in a move shortsighted even by IETF standards
;-) RADIUS only allows the authorization of the use of one framed
protocol at a time, even though PPP doesn't have this restriction &
multi-stack machines existed even back then.  I mention this only to
point out the inadequacy of RADIUS' existing session model, which I
think is pretty relevant.

>=20
> Or are you thinking of VSAs?  I remember doing something like that
> back in my days at DEC, as a VSA.=20

Possibly, yes. =20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 19:35:30 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 15:24:10 -0400

Glen Zorn writes...

> Not necessarily.  For example, I can imagine that an SDO other than the
> IETF might decide what constitutes a "session" for their system.  I
> think that that qualifies as "deployment-specific", with a market
> possibly significant enough to warrant manufacturing customization.

Ah, I see.

This still seems problematic for RFC 3576bis, however.  If we leave the
selection of session "marker" attributes that need to appear in
Access-Request and CoA-Request messages to support a particular application
open ended, then we can't easily task someone to write a test plan to verify
multi-vendor interoperability of RFC 3567bis, because the attribute
selection is not deterministic, or at least not determined within the scope
of the document.

If we are looking at RFC 3576bis as simply a base document that is used by
other SDO documents to form a complete solution, but that is not a complete,
interoperable protocol unto itself, then let's at least say so.  I think it
may be best to specify a minimum set of session "marker" attributes for
generic RADIUS applications as SHOULDs in RFC 3567bis and indicate that
there are an unlimited number of other session "marker" attributes that MAY
appear, based on the requirements of other documents, e.g. from non-IETF
SDOs.

That would at least put the implementer on notice.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 19:22:43 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 15:14:21 -0400

Glen Zorn writes...

> I'm saying that it is quite possible (& efficient) to authorize a
> variety of services with a single Access-Accept, not all of which may be
> instantiated simultaneously.

Using a single Service-Type attribute?  Which one?  I'm not aware of any
RADIUS service types that convey a multi-session connotation.

Or are you thinking of VSAs?  I remember doing something like that back in
my days at DEC, as a VSA.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 18:33:48 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 11:33:08 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Monday, May 28, 2007 11:06 AM:

> Glen Zorn writes...
>=20
>> If the definition of "session" was vendor- or
>> implementation-specific, I would agree with you, but it appears to
>> me that it is actually -deployment-specific; therefore, it's not
>> clear to me that this has anything to do with multi-vendor
>> interoperability.=20
>=20
> By "deployment-specific" I presume you to infer customization by (or
> on behalf of) the end-user, by others than the equipment
> manufacturer. =20

Not necessarily.  For example, I can imagine that an SDO other than the
IETF might decide what constitutes a "session" for their system.  I
think that that qualifies as "deployment-specific", with a market
possibly significant enough to warrant manufacturing customization.

> I still fail to see how the NAS behavior regarding
> session identification information in a CoA-Request can be modified
> at the time of deployment, unless the NAS operating firmware can be
> modified by the installer or customer. =20

The only reason firmware modification would be necessary is if the
equipment vendor didn't include a session ID "marker" that was required
in a particular situation (note that the creation of that situation (by
this WG) is exactly what I'm arguing against).  OTOH, maybe the rest of
the folks on this list are bright enough to be able to predict & specify
now and forever what the identifying characteristics of any session
would be; in that case, carry on.

> I'm not aware of any such
> equipment.  Please enlighten me.     =20
>=20
> Maybe someone has a NAS implementation that allows such customization
> via a CLI or MIB?  If so, details would be instructive.=20

Cisco provides a range of configurable means to identify sessions of
various varieties; every once in a while, we have to change the firmware
because the existing set of markers is insufficient.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 18:10:14 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 14:06:13 -0400

Glen Zorn writes...
 
> If the definition of "session" was vendor- or implementation-specific, I
> would agree with you, but it appears to me that it is actually
> -deployment-specific; therefore, it's not clear to me that this has
> anything to do with multi-vendor interoperability.

By "deployment-specific" I presume you to infer customization by (or on
behalf of) the end-user, by others than the equipment manufacturer.  I still
fail to see how the NAS behavior regarding session identification
information in a CoA-Request can be modified at the time of deployment,
unless the NAS operating firmware can be modified by the installer or
customer.  I'm not aware of any such equipment.  Please enlighten me.

Maybe someone has a NAS implementation that allows such customization via a
CLI or MIB?  If so, details would be instructive.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 17:39:40 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 10:39:23 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Monday, May 28, 2007 10:00 AM:

> Avi Lior writes...
>=20
>> I don't think therefore that 3576 should prohibit any of the above.
>> It really is up to deployments to determine how these are used.
>=20
> Freedom to innovate and differentiate your product is a wonderful
> thing, but so is multi-vendor interoperability based on the formal
> specification alone. =20

If the definition of "session" was vendor- or implementation-specific, I
would agree with you, but it appears to me that it is actually
-deployment-specific; therefore, it's not clear to me that this has
anything to do with multi-vendor interoperability.  As Alan noted, the
server must know which session it wants to modify or terminate and thus
it must also know what set of attributes is required to uniquely
identify it.

> I understand that you may wish to have a rich vocabulary to specify
> the "filter" on which sessions to affect, but it also seems to me
> that writing down the rules for everyone to see and implement is
> required. =20

The problem is that the "rules" are not & cannot be fixed a priori.=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 17:14:50 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 10:14:23 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>

David B. Nelson <> allegedly scribbled on Monday, May 28, 2007 9:55 AM:

> Glen Zorn writes...
>=20
>> I think the point is that there may be multiple accounting sessions
>> (either serial or parallel) authorized by a single
>> Access-Request/-Reply...
>=20
> How does that happen?  You're saying that the NAS=20

user

> decides to start up
> another service all of its own accord, without receiving another
> Access-Accept?  Or a CoA-Request? =20

I'm saying that it is quite possible (& efficient) to authorize a
variety of services with a single Access-Accept, not all of which may be
instantiated simultaneously.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 17:06:28 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 13:00:19 -0400

Avi Lior writes...

> I don't think therefore that 3576 should prohibit any of the above.
> It really is up to deployments to determine how these are used.

Freedom to innovate and differentiate your product is a wonderful thing, but
so is multi-vendor interoperability based on the formal specification alone.
I understand that you may wish to have a rich vocabulary to specify the
"filter" on which sessions to affect, but it also seems to me that writing
down the rules for everyone to see and implement is required.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 16:56:04 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 12:54:53 -0400

Glen Zorn writes...

> I think the point is that there may be multiple accounting 
> sessions (either serial or parallel) authorized by a single
> Access-Request/-Reply...

How does that happen?  You're saying that the NAS decides to start up
another service all of its own accord, without receiving another
Access-Accept?  Or a CoA-Request?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 16:35:10 +0000
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 12:34:48 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, <[email-masked]>

See inline....=20

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]=20
Sent: Monday, May 28, 2007 11:37 AM
To: Avi Lior
Cc: David B. Nelson; [email-masked]
Subject: Re: RFC3576bis and Session State

Avi Lior wrote:
>    I suggest we can request that they implement it now, *if* they also

> support CoA or Disconnect request.
>=20
> [Avi] I strongly disagree.  Requiring that a RADIUS server that will=20
> issue a COA or DM receive accounting messages is inappropriate.

  Which is why I didn't suggest that the server receive accounting
messages.  What I said was that it should receive a protocol-independent
session identification key... sometimes called Acct-Session-Id.

[Avi] Yes but it can only receive one and there can be many Accounting
Session Ids, and they can change. =20

> [Avi] A session id for what? Accounting Session ID identifies a An=20
> accounting session delineated by a Start Record and a Stop Record.
> Including Acct-Session-Id in a DM or COA means you want to effect that

> session that is being represented by that Accounting Session.  That=20
> session could be:
> 1) The entire session;
> 2) An IP session;
> 3) An IP flow;
> 4) Something else that generates an Accounting Record.

  If the the CoA client doesn't know what session it's trying to change,
it shouldn't be sending a CoA request.

[Avi] It may want to kill all the "sessions" that are associated with a
given User Identity.  The po0int of the above is that there are many
things you can call a "session". You seem to focus on only one of them
which is a session represented by a Start/Stop record.

  If it does know what session it's trying to change, it should inform
the NAS that the *session* needs changing.  Using IP
address/port/whatever as session identification keys is unacceptable.
It may work sometimes, but it has the problem of being protocol
specific, in addition to making impossible to change protocol parameters
mid-session.

[Avi] We are building a toolkit.  There are many different kinds of
sessions.  Even Acct-Session-Id is ambiguous at best. What session is it
representing?  The only thing you can say it that it is representing a
particular Start/Stop accounting segment.  Beyond that you cant say
anything unless you know when an accounting start/stop segement is being
generated.

> So I am okay with including Accounting Session Id.  But we need some=20
> clarification text. Something like:
>=20
> "If Acct-Session-Id is included in the COA or DM, then that message=20
> SHALL effect the session that is identified by the Acct-Session-Id=20
> only."

  Pretty much, yes.

[Avi] Good.  But note that I am not mandating its includsion. So I am
glad you agree.  And it should not be mandate to include in an
Access-Request either.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 16:25:43 +0000
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 12:25:30 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7A145.03BB0962
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

See inline....

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Sunday, May 27, 2007 4:10 PM
To: Alan DeKok
Cc: [email-masked]
Subject: RE: RFC3576bis and Session State

How is this?=20
=20
"A NAS implementing this specification SHOULD send an Acct-Session-Id
or Acct-Multi-Session-Id Attribute within an Access-Request.
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
included within an Access-Request, the Dynamic Authorizatoin Client will
not know the Acct-Session-Id
or Acct-Multi-Session-Id of the session it is attempting to target,
unless it also has access to the accounting data for that session.
=20
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
present in a CoA-Request or Disconnect-Request, it is possible that the
the User-Name or Chargeable-User-Identity attributes will not be=20
sufficient to uniquely identify the session (e.g. if the same
user has multiple sessions on the NAS, or if the privacy NAI is used).=20
In this case, session identification MAY be performed by using one or
more of
the Called-Station-Id, Calling-Station-Id, NAS-Port and
NAS-Port-Id attributes."

[Avi] No I dont agree.  See my previous emails on this topic.=20

------_=_NextPart_001_01C7A145.03BB0962
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D594032516-28052007>See=20
inline....</SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<B>From:</B> [email-masked] =
[mailto:[email-masked]]=20
<B>On Behalf Of </B>Bernard Aboba<BR><B>Sent:</B> Sunday, May 27, 2007 =
4:10=20
PM<BR><B>To:</B> Alan DeKok<BR><B>Cc:</B>=20
[email-masked]<BR><B>Subject:</B> RE: RFC3576bis and Session=20
State<BR><BR></DIV>
<DIV></DIV>How is this? <BR>&nbsp;<BR>"A NAS implementing this =
specification=20
SHOULD send an Acct-Session-Id<BR>or Acct-Multi-Session-Id Attribute =
within an=20
Access-Request.<BR>Where an Acct-Session-Id or Acct-Multi-Session-Id =
Attribute=20
is not<BR>included within an Access-Request, the Dynamic Authorizatoin =
Client=20
will not know the Acct-Session-Id<BR>or Acct-Multi-Session-Id of the =
session it=20
is attempting to target,<BR>unless it also has access to the accounting =
data for=20
that session.<BR>&nbsp;<BR>Where an Acct-Session-Id or =
Acct-Multi-Session-Id=20
Attribute is not<BR>present in a CoA-Request or Disconnect-Request, it =
is=20
possible that the<BR>the User-Name or Chargeable-User-Identity =
attributes will=20
not be <BR>sufficient to uniquely identify the session (e.g. if the =
same<BR>user=20
has multiple sessions on the NAS, or if the privacy NAI is used). <BR>In =
this=20
case, session identification MAY be performed by using one or more =
of<BR>the=20
Called-Station-Id, Calling-Station-Id, NAS-Port and<BR>NAS-Port-Id=20
attributes."<BR><BR><SPAN class=3D594032516-28052007>[Avi]&nbsp;No I =
dont=20
agree.&nbsp; See my previous emails on this=20
topic.&nbsp;</SPAN><BR><BR></BODY></HTML>

------_=_NextPart_001_01C7A145.03BB0962--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 16:24:44 +0000
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 12:24:27 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

See inline......

> Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not=20
> present in a CoA-Request or Disconnect-Request,

Alan wrote:

  the User-Name or Chargeable-User-Identity attributes may be sufficient
to uniquely identify the session.  However, if the same user has
multiple sessions on the NAS, or if the privacy NAI is used, that
information may be insufficient to uniquely identify a session.  Session
identification MAY be performed by using one or more of the
Called-Station-Id, Calling-Station-Id,  NAS-Port and NAS-Port-Id
attributes.

[Avi] Or having only the User-Name or CUI (or a VSA) is exactly what I
want to do.  In this case I want to effect all of the user's sessions.

> I can add a sentence to Section saying "A NAS implementing this=20
> specification SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id=20
> Attribute within an Access-Request."

Alan wrote:

   Yes.  Also note that doing so makes the CoA network much simpler and
more robust.  I would prefer it to be a MUST, but that's probably too
strong.  Maybe a strong recommendation in addition to SHOULD.

[Avi] No. Not even a SHOULD.  It will be up to deployements to decide
which attributes to include and where. As I said again and again,
Acct-Session-Id is often useless.

   Alan DeKok.

--

to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 16:19:52 +0000
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 12:19:40 -0400
From: "Avi Lior" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>

David Nelson wrote:

"Of course, charters are subject to revision, especially if there is a
demonstrated need in the Internet community and all the rest of the
chartered work has been completed."

Or work can proceed even without modification to the charter. Right?

--

to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 16:16:01 +0000
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 12:15:47 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Alan DeKok" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7A143.A7B5124A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have an issue with some of the statement being made below:
=20
What session identifiers I include in the COA or DM message should
indicate what I want to effect.
=20
If I only inlcude the User Identity (NAI, CUI, or some other identity)
then I want to effect the user session being identified which may
inlcude all of the users IP sessions and all the flows etc...
=20
If I inlcude the Acct-Mutli-Session-Id attribute, then I want to effect
all the sessions that are being identitified by the
Acct-Multi-Session-Id.
=20
If I include the Acct-Session-Id attribute then I want only to effect
the session that is being identified by that handle.
=20
If I inlcude the Framed-IP-Address, then I want to effect the sessions
that are identified by the IP address (IPv4 or IPv6)
=20
There may even be some VSA that can be used as well....
=20
I dont think therefore that 3576 should prohibit any of the above.  It
really is up to deployements to determine how these are used.
=20
3576 should simply state that the COA and DM should identify the session
to be effected using any of the session attributes available (including
VSAs). Some examples may be appropriate.
=20
Statements like:
=20
Alan worte: "I can add a sentence to Section saying "A NAS implementing
this specification SHOULD send
an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an
Access-Request." "

Which as i pointed out only works in very simple cases. And in some
cases Acct-Session-Id is totally useless.
=20
Or
=20
Bernard wrote:  "Actually, it seems like it might make it unnecessary to
use an IP address as a session identification attribute."

IMO are not appropriate because they are useful in only some
deployements.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Saturday, May 26, 2007 12:15 PM
To: Alan DeKok; [email-masked]
Subject: RE: RFC3576bis and Session State

> Date: Sat, 26 May 2007 16:16:31 +0100
> From: [email-masked]
> To: [email-masked]
> Subject: Re: RFC3576bis and Session State
>=20
> Bernard Aboba wrote:
> > > I suggest we can request that they implement it now, *if* they
also
> > > support CoA or Disconnect request.
> >=20
> > [BA] Are you suggesting that NASes implementing RFC 3576bis SHOULD
send=20
> > the Acct-Session-Id within an Access-Request?
>=20
> Yes. Or, Acct-Multi-Session-Id, which may address Avi's concerns=20
> over multiple Acct-Session-Id's for one "session".\

[BA]  Hmm...  Perhaps we need a change in Section 3 from:

"As noted in [RFC2866] Section 5.5:

An Accounting-Request packet MUST have an Acct-Session-Id.  An
Access-Request packet MAY have an Acct-Session-Id; if it does,
then the NAS MUST use the same Acct-Session-Id in the Accounting-Request
packets for that session.

Since the Acct-Session-Id is optional in Access-Requests,
if the Dynamic Authorization Client only has access to
attributes sent to or by the RADIUS authentication server, then it
will not necessarily know the Acct-Session-Id of the session it is
attempting
to target.

Where the Acct-Session-Id Attribute is not present in
a CoA-Request or Disconnect-Request,
it is possible that the User-Name or Chargeable-User-Identity
attributes will not be sufficient to uniquely identify the session (e.g.
if the same
user has multiple sessions on the NAS, or the privacy NAI is used).
As a result, one or more of the Acct-Multi-Session-Id,
Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id
attributes
MAY be used as additional session identification."

To something like this:=20

"A NAS implementing this specification SHOULD send an Acct-Session-Id or
Acct-Multi-Session-Id Attribute within an Access-Request.  However,
where the Acct-Session-Id or Acct-Multi-Session-Id is not included
within an Access-Request, unless the Dynamic Authorization Client has
access to accounting data, it is possible that the Dynamic Authorization
Client will not know the Acct-Session-Id or Acct-Multi-Session-Id of the
session it is attempting to target.

Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
present in a CoA-Request or Disconnect-Request, it is possible that the
User-Name or Chargeable-User-Identity attributes will not be sufficient
to uniquely identify the session (e.g. if the same user has multiple
sessions on the NAS or the privacy NAI is used).  As a result, one or
more of the Called-Station-Id, Calling-Station-Id,  NAS-Port and
NAS-Port-Id attributes MAY be used as additional session
identification."=20

I can add a sentence to Section saying "A NAS implementing this
specification SHOULD send
an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an
Access-Request."=20

>=20
> Requiring this would avoid the issue of Framed-IP-Address being used=20
> as both a key for the session, and the target of the change request,=20
> which was the start of this thread.

[BA] Actually, it seems like it might make it unnecessary to use an IP
address as a session identification attribute.
=20
> Requiring a session identification attribute would avoid the ad-hoc=20
> session identification. i.e. IPv4, IPv6, and fields from other=20
> protocols used to identify sessions? Are we going to update the RFC's=20
> every time someone uses RADIUS to authorize a new protocol?
>
> Or, we can define a protocol-independent key, and use that for all=20
> protocols, old and new.

[BA] That seems like a better idea.=20

>=20
> Alan DeKok.

------_=_NextPart_001_01C7A143.A7B5124A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>I have an =
issue with some=20
of the statement being made below:</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>What =
session identifiers=20
I include in the COA or DM message should indicate what I want to=20
effect.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>If I only =
inlcude the=20
User Identity (NAI, CUI, or some other identity) then I want to effect =
the user=20
session being identified which may inlcude all of the users IP sessions =
and all=20
the flows etc...</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>If I =
inlcude the=20
Acct-Mutli-Session-Id attribute, then I want to effect all the sessions =
that are=20
being identitified by the Acct-Multi-Session-Id.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>If I =
include the=20
Acct-Session-Id attribute then I want only to effect the session that is =
being=20
identified by that handle.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>If I =
inlcude the=20
Framed-IP-Address, then I want to effect the sessions that are =
identified by the=20
IP address (IPv4 or IPv6)</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>There may =
even be some=20
VSA that can be used as well....</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>I dont =
think therefore=20
that 3576 should prohibit any of the above.&nbsp; It really is up to=20
deployements to determine how these are used.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>3576 should =
simply state=20
that the COA and DM should identify the session to be effected using any =
of the=20
session attributes available (including VSAs). Some examples may be=20
appropriate.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>Statements=20
like:</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007>Alan&nbsp;worte: "I can=20
add a sentence to Section saying "A NAS implementing this specification =
SHOULD=20
send<BR>an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an=20
Access-Request." "<BR></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>Which as i =
pointed out=20
only works in very simple cases. And in some cases Acct-Session-Id is =
totally=20
useless.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D120080316-28052007>&nbsp;</DIV></SPAN>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D120080316-28052007>Or</DIV>
<DIV></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D120080316-28052007>Bernard =
wrote:&nbsp;</SPAN>&nbsp;<SPAN=20
class=3D120080316-28052007>"</SPAN>Actually, it seems like it might make =
it=20
unnecessary to use an IP address as a session identification =
attribute.<SPAN=20
class=3D120080316-28052007>"</SPAN><BR></DIV>
<DIV><SPAN class=3D120080316-28052007>IMO are not appropriate because =
they are=20
useful in only some deployements.</SPAN></DIV>
<DIV><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<B>From:</B> [email-masked] =
[mailto:[email-masked]]=20
<B>On Behalf Of </B>Bernard Aboba<BR><B>Sent:</B> Saturday, May 26, 2007 =
12:15=20
PM<BR><B>To:</B> Alan DeKok; [email-masked]<BR><B>Subject:</B> =
RE:=20
RFC3576bis and Session State<BR><BR></DIV>
<DIV></DIV><BR><BR>&gt; Date: Sat, 26 May 2007 16:16:31 +0100<BR>&gt; =
From:=20
[email-masked]<BR>&gt; To: [email-masked]<BR>&gt; Subject: =
Re:=20
RFC3576bis and Session State<BR>&gt; <BR>&gt; Bernard Aboba =
wrote:<BR>&gt; &gt;=20
&gt; I suggest we can request that they implement it now, *if* they =
also<BR>&gt;=20
&gt; &gt; support CoA or Disconnect request.<BR>&gt; &gt; <BR>&gt; &gt; =
[BA] Are=20
you suggesting that NASes implementing RFC 3576bis SHOULD send <BR>&gt; =
&gt; the=20
Acct-Session-Id within an Access-Request?<BR>&gt; <BR>&gt; Yes. Or,=20
Acct-Multi-Session-Id, which may address Avi's concerns <BR>&gt; over =
multiple=20
Acct-Session-Id's for one "session".\<BR><BR>[BA]&nbsp; Hmm...&nbsp; =
Perhaps we=20
need a change in Section 3 from:<BR><BR>"As noted in [RFC2866] Section=20
5.5:<BR><BR>An Accounting-Request packet MUST have an =
Acct-Session-Id.&nbsp;=20
An<BR>Access-Request packet MAY have an Acct-Session-Id; if it =
does,<BR>then the=20
NAS MUST use the same Acct-Session-Id in the =
Accounting-Request<BR>packets for=20
that session.<BR><BR>Since the Acct-Session-Id is optional in=20
Access-Requests,<BR>if the Dynamic Authorization Client only has access=20
to<BR>attributes sent to or by the RADIUS authentication server, then =
it<BR>will=20
not necessarily know the Acct-Session-Id of the session it is =
attempting<BR>to=20
target.<BR><BR>Where the Acct-Session-Id Attribute is not present =
in<BR>a=20
CoA-Request or Disconnect-Request,<BR>it is possible that the User-Name =
or=20
Chargeable-User-Identity<BR>attributes will not be sufficient to =
uniquely=20
identify the session (e.g. if the same<BR>user has multiple sessions on =
the NAS,=20
or the privacy NAI is used).<BR>As a result, one or more of the=20
Acct-Multi-Session-Id,<BR>Called-Station-Id, Calling-Station-Id, =
NAS-Port and=20
NAS-Port-Id attributes<BR>MAY be used as additional session=20
identification."<BR><BR>To something like this: <BR><BR>"A NAS =
implementing this=20
specification SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id =
Attribute=20
within an Access-Request.&nbsp; However, where the Acct-Session-Id or=20
Acct-Multi-Session-Id is not included within an Access-Request, unless =
the=20
Dynamic Authorization Client has access to accounting data, it is =
possible that=20
the Dynamic Authorization Client will not know the Acct-Session-Id or=20
Acct-Multi-Session-Id of the session it is attempting to =
target.<BR><BR>Where an=20
Acct-Session-Id or Acct-Multi-Session-Id Attribute is not present in a=20
CoA-Request or Disconnect-Request, it is possible that the User-Name or=20
Chargeable-User-Identity attributes will not be sufficient to uniquely =
identify=20
the session (e.g. if the same user has multiple sessions on the NAS or =
the=20
privacy NAI is used).&nbsp; As a result, one or more of the =
Called-Station-Id,=20
Calling-Station-Id,&nbsp; NAS-Port and NAS-Port-Id attributes MAY be =
used as=20
additional session identification." <BR><BR><BR>I can add a sentence to =
Section=20
saying "A NAS implementing this specification SHOULD send<BR>an =
Acct-Session-Id=20
or Acct-Multi-Session-Id Attribute within an Access-Request." =
<BR><BR>&gt;=20
<BR>&gt; Requiring this would avoid the issue of Framed-IP-Address being =
used=20
<BR>&gt; as both a key for the session, and the target of the change =
request,=20
<BR>&gt; which was the start of this thread.<BR><BR>[BA] Actually, it =
seems like=20
it might make it unnecessary to use an IP address as a session =
identification=20
attribute.<BR>&nbsp;<BR>&gt; Requiring a session identification =
attribute would=20
avoid the ad-hoc <BR>&gt; session identification. i.e. IPv4, IPv6, and =
fields=20
from other <BR>&gt; protocols used to identify sessions? Are we going to =
update=20
the RFC's <BR>&gt; every time someone uses RADIUS to authorize a new=20
protocol?<BR>&gt;<BR>&gt; Or, we can define a protocol-independent key, =
and use=20
that for all <BR>&gt; protocols, old and new.<BR><BR>[BA] That seems =
like a=20
better idea. <BR><BR>&gt; <BR>&gt; Alan DeKok.<BR></BODY></HTML>

------_=_NextPart_001_01C7A143.A7B5124A--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 16:11:07 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 09:10:09 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Avi Lior" <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, <[email-masked]>

Alan DeKok <> allegedly scribbled on Monday, May 28, 2007 8:37 AM:

> Avi Lior wrote:
>>    I suggest we can request that they implement it now, *if* they
>> also support CoA or Disconnect request.
>>=20
>> [Avi] I strongly disagree.  Requiring that a RADIUS server that will
>> issue a COA or DM receive accounting messages is inappropriate.
>=20
>   Which is why I didn't suggest that the server receive accounting
> messages.  What I said was that it should receive a
> protocol-independent session identification key... sometimes called
> Acct-Session-Id.  =20
>=20
>> [Avi] A session id for what? Accounting Session ID identifies a An
>> accounting session delineated by a Start Record and a Stop Record.
>> Including Acct-Session-Id in a DM or COA means you want to effect
>> that session that is being represented by that Accounting Session.=20
>> That session could be: 1) The entire session;
>> 2) An IP session;
>> 3) An IP flow;
>> 4) Something else that generates an Accounting Record.
>=20
>   If the the CoA client doesn't know what session it's trying to
> change, it shouldn't be sending a CoA request.

I think the point is that there may be multiple accounting sessions
(either serial or parallel) authorized by a single
Access-Request/-Reply, all with different session IDs and maybe even
members of different groups (so different Acct-Multi-Session-IDs, so
unless the RADIUS server receives _all_ the stop and stop records it
can't know about those.  Are we saying then, that _only_ the original
session may be affected by CoA?  If so, maybe it would be better to have
a session-ID specifically for that instead of overloading the
Acct-Session-ID attribute. =20

>=20
>   If it does know what session it's trying to change, it should
> inform the NAS that the *session* needs changing.  Using IP
> address/port/whatever as session identification keys is unacceptable.

So is using the accounting session ID, for the reasons outlined above.

> It may work sometimes, but it has the problem of being protocol
> specific, in addition to making impossible to change protocol
> parameters mid-session. =20
>=20
>> So I am okay with including Accounting Session Id.  But we need some
>> clarification text. Something like:
>>=20
>> "If Acct-Session-Id is included in the COA or DM, then that message
>> SHALL effect the session that is identified by the Acct-Session-Id
>> only."
>=20
>   Pretty much, yes.
>=20
>   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 15:54:47 +0000
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 11:54:32 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Alan,

Again I am not opposed to using Accounting-Session-ID.

Please see inline....=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alan DeKok
Sent: Saturday, May 26, 2007 10:39 AM
To: Glen Zorn (gwz)
Cc: Bernard Aboba; [email-masked]
Subject: RFC3576bis and Session State

Glen Zorn (gwz) wrote:
...
>>   What I'm saying is that the NAS knows what a session is: the user=20
>> is connected to it.  The NAS has the information that ties=20
>> authentication packets to accounting packets:  the Acct-Session-Id.
>=20
> Only if it supports RADIUS accounting, which I believe you stated is=20
> not mandatory.

Alan wrote:

   The NAS can send Acct-Session-Id in an Access-Request without ever
sending an Accounting-Request packet.  This is permitted by the existing
specifications.

[Avi]  But it may not be sufficient.  Since an Access-Request can only
contain a single Accouting Session ID and there could be many sessions
each having their own Accounting Session Ids.  Also accounting session
id may change without an access request. =20

Therefore Acct-Session-Id can only be useful in simple deployements.
Which is fine.

In cases where there are many Acct-Session-Ids then the AAA server may
need to hunt for them in the accounting stream (which is what Glen is
eluding to).

=20
> presumably by letting the RADIUS server grovel through thousands of=20
> accounting records (if they exist).  Of course, knowing the location=20
> and format of these records doesn't constitute an "undefined but=20
> incestuous relationship".

   Maybe I'm missing something.  I thought I was proposing that the
authentication server track sessions by ID sent in Access-Request, not
in Accounting-Request.

[Avi] It can only track one of them since you can only have one in an
Access Request.

> OK, one simple question: when and how does the RADIUS server (since=20
> it's not necessarily the same as the accounting server & therefore=20
> will not necessarily receive Accounting Stop records) know that the=20
> session has ended and that it can therefore discard that data?

   When it is the same as the accounting server, there's no problem.=20
When it isn't, it can use attributes like "Session-Timeout" to track
when the session is supposed to end.

[Avi] But how does it know when the session ended as opposed to when it
was suppose to end.  Session-Timeout can be really long.  So that
doesn't really work right?

> and that RADIUS
> servers need a way to keep track of user sessions _outside_ of=20
> accounting.

   Mostly.  There are few deployments where the authentication server
needs access to the accounting data.  There are many deployments where
the accounting data triggers CoA packets... in which case the sender of
the CoA has access to the accounting information.

[Avi] Doesn't really scale Alan.  There are many many accounting
sessions being generated in some deployements for each
Access-Authentication.  These include interims but even without those
the ratio can be more then 10:1.=20

--

to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 15:36:34 +0000
Date: Mon, 28 May 2007 17:36:36 +0200
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  [email-masked]
Subject: Re: RFC3576bis and Session State

Avi Lior wrote:
>    I suggest we can request that they implement it now, *if* they also
> support CoA or Disconnect request.
> 
> [Avi] I strongly disagree.  Requiring that a RADIUS server that will
> issue a COA or DM receive accounting messages is inappropriate.

  Which is why I didn't suggest that the server receive accounting
messages.  What I said was that it should receive a protocol-independent
session identification key... sometimes called Acct-Session-Id.

> [Avi] A session id for what? Accounting Session ID identifies a An
> accounting session delineated by a Start Record and a Stop Record.
> Including Acct-Session-Id in a DM or COA means you want to effect that
> session that is being represented by that Accounting Session.  That
> session could be:
> 1) The entire session;
> 2) An IP session;
> 3) An IP flow;
> 4) Something else that generates an Accounting Record.

  If the the CoA client doesn't know what session it's trying to change,
it shouldn't be sending a CoA request.

  If it does know what session it's trying to change, it should inform
the NAS that the *session* needs changing.  Using IP
address/port/whatever as session identification keys is unacceptable.
It may work sometimes, but it has the problem of being protocol
specific, in addition to making impossible to change protocol parameters
mid-session.

> So I am okay with including Accounting Session Id.  But we need some
> clarification text. Something like:
> 
> "If Acct-Session-Id is included in the COA or DM, then that message
> SHALL effect the session that is identified by the Acct-Session-Id
> only."

  Pretty much, yes.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 15:28:52 +0000
Subject: RE: Issue: Attribute restriction
Date: Mon, 28 May 2007 11:28:40 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7A13D.0E0D9836
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bernard,
=20
Dont forget that in RADIUS Location Draft we want to include location
information in this message.

Recall, that if the NAS provided location information in an
Access-Request (either because it was configured to do so, or because it
received a challenge) then when issueing the Access-Request due to the
receipt of COA (Authorize-Only) we want it to also include the location
information.  Thus this will avoid the AAA server from challenging it
again to provide location information.
=20
How do you want to deal with that?  Do we let that Draft specify this or
do you want to align the draft.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Saturday, May 26, 2007 10:27 AM
To: [email-masked]
Subject: Issue: Attribute restriction

Issue:  Attribute Restriction
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: May 26, 2007
Reference:=20
Document: RFC3576bis-06
Comment type: Technical
Priority: S
Section: 3.2
Rationale/Explanation of issue:

Section 3.2 contains the following sentence:

   This Access-Request SHOULD contain the NAS
   identification attributes from the CoA-Request, as well as the
   session identification attributes from the CoA-Request legal for
   inclusion in an Access-Request as specified in [RFC2865], [RFC2868],
   [RFC2869] and [RFC3162]. =20

This sentence appears to imply that only session identification
attributes=20
from [RFC2865], [RFC2868], [RFC2869] and [RFC3162] can be included in
the=20
Access-Request.  In fact, RFC 3576bis adds Chargeable-User-Identity to
the=20
list of session identification attributes; this is defined in a document
that is not listed.

The proposed resolution is to change this sentence to:

   This Access-Request SHOULD contain the NAS
   identification attributes from the CoA-Request, as well as the
   session identification attributes from the CoA-Request legal for
   inclusion in an Access-Request.

------_=_NextPart_001_01C7A13D.0E0D9836
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D207212515-28052007>Bernard,</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D207212515-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D207212515-28052007>Dont forget =
that in=20
RADIUS Location Draft we want to include&nbsp;location information in =
this=20
message.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D207212515-28052007><BR>Recall, =
that if the=20
NAS provided location information in an Access-Request (either because =
it was=20
configured to do so, or because it received a challenge) then when =
issueing the=20
Access-Request due to the receipt of COA (Authorize-Only) we want it to =
also=20
include the location information.&nbsp; Thus this will avoid the AAA =
server from=20
challenging it again to provide location information.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D207212515-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D207212515-28052007>How do you =
want to deal=20
with that?&nbsp; Do we let that Draft specify this or do you want to =
align the=20
draft.</SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<B>From:</B> [email-masked] =
[mailto:[email-masked]]=20
<B>On Behalf Of </B>Bernard Aboba<BR><B>Sent:</B> Saturday, May 26, 2007 =
10:27=20
AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Issue: =
Attribute=20
restriction<BR><BR></DIV>
<DIV></DIV>Issue:&nbsp; Attribute Restriction<BR>Submitter name: Bernard =

Aboba<BR>Submitter email address: [email-masked]<BR>Date first =
submitted:=20
May 26, 2007<BR>Reference: <BR>Document: RFC3576bis-06<BR>Comment type:=20
Technical<BR>Priority: S<BR>Section: 3.2<BR>Rationale/Explanation of=20
issue:<BR><BR>Section 3.2 contains the following sentence:<BR><PRE>   =
This Access-Request SHOULD contain the NAS<BR>   identification =
attributes from the CoA-Request, as well as the<BR>   session =
identification attributes from the CoA-Request legal for<BR>   inclusion =
in an Access-Request as specified in [RFC2865], [RFC2868],<BR>   =
[RFC2869] and [RFC3162].  <BR><BR>This sentence appears to imply that =
only session identification attributes <BR>from [RFC2865], [RFC2868], =
[RFC2869] and [RFC3162] can be included in the <BR>Access-Request.  In =
fact, RFC 3576bis adds Chargeable-User-Identity to the <BR>list of =
session identification attributes; this is defined in a document<BR>that =
is not listed.<BR><BR>The proposed resolution is to change this sentence =
to:<BR><BR>   This Access-Request SHOULD contain the NAS<BR>   =
identification attributes from the CoA-Request, as well as the<BR>   =
session identification attributes from the CoA-Request legal for<BR>   =
inclusion in an Access-Request.<BR></PRE></BODY></HTML>

------_=_NextPart_001_01C7A13D.0E0D9836--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 15:24:29 +0000
Subject: RE: RFC3576bis and Session State
Date: Mon, 28 May 2007 11:24:16 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

See inline...=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alan DeKok
Sent: Saturday, May 26, 2007 10:16 AM
To: David B. Nelson
Cc: [email-masked]
Subject: RFC3576bis and Session State

David B. Nelson wrote:
> It is entirely possible that RADIUS client implementations that do not

> include RADIUS Accounting may not have implemented the Acct-Session-Id

> attribute. They would have no need to.

   I suggest we can request that they implement it now, *if* they also
support CoA or Disconnect request.

[Avi] I strongly disagree.  Requiring that a RADIUS server that will
issue a COA or DM receive accounting messages is inappropriate.  A
typical session could have 10s of accounting events and now the RADIUS
server will be flooded with messages that it really does not need.  In
many implmentation the RADIUS server does need to get notification that
the session has started and ended.  Therefore it typically needs the
first accounting message and the last accounting message. The other
accounting messages do not provide it with useful information.  Thus
Glen and I wrote the Logoff draft which allows the accounting message to
be routed to the accounting subsystem and only deliver the information
required by the RADIUS server -- so that it can maintain state and use
DM and COA.

> OTOH, I don't think we need to get too hung up about the nomenclature=20
> of the attribute.  The fact at the prefix is Acct should not be=20
> sufficient to disqualify its usage as a session identifier for the=20
> authentication server as well as the accounting server.  A session ID
is a session ID.

   I agree.  Hence my suggestion to use Acct-Session-Id.

[Avi] A session id for what? Accounting Session ID identifies a An
accounting session delineated by a Start Record and a Stop Record.
Including Acct-Session-Id in a DM or COA means you want to effect that
session that is being represented by that Accounting Session.  That
session could be:
1) The entire session;
2) An IP session;
3) An IP flow;
4) Something else that generates an Accounting Record.

So I am okay with including Accounting Session Id.  But we need some
clarification text. Something like:

"If Acct-Session-Id is included in the COA or DM, then that message
SHALL effect the session that is identified by the Acct-Session-Id
only."

   Alan DeKok.

--

to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 14:56:42 +0000
Subject: RE: Issue 223: Event-Timestamp and Duplicate Detection
Date: Mon, 28 May 2007 10:56:35 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7A138.9439A852
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Perhaps.
=20
But there are no formal words in the table.  The first three sentences
use terms like "guide" "may be".
=20
It also uses must not be present in an Accounting-Request.  So why
wouldnt the document make a similar strong statement about those
attribute,
=20
If it was intended not to be in those messages I would suggest the
attributes would have appeared in the table with zeros in the
corresponding columns.
=20
I think that document is ambiguous in this matter.

________________________________

From: Bernard Aboba [mailto:[email-masked]]=20
Sent: Friday, May 25, 2007 6:59 PM
To: Avi Lior; Alan DeKok
Cc: [email-masked]
Subject: RE: Issue 223: Event-Timestamp and Duplicate Detection

> No. If it was prohibited in an Access-Request, Accept, Reject etc...
It
> would have specifically stated that.=20

Here's what RFC 2869 Section 5.19 says:
=20
   The following table provides a guide to which attributes may be found
   in which kind of packets.  Acct-Input-Gigawords, Acct-Output-
   Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
   an Accounting-Request packet.  Connect-Info may have 0+ instances in
   an Accounting-Request packet.  The other attributes added in this
   document must not be present in an Accounting-Request.

Request  Accept  Reject  Challenge   #    Attribute
0-1      0       0       0           70   ARAP-Password [Note 1]
0        0-1     0       0-1         71   ARAP-Features
0        0-1     0       0           72   ARAP-Zone-Access
0-1      0       0       0-1         73   ARAP-Security
0+       0       0       0+          74   ARAP-Security-Data
0        0       0-1     0           75   Password-Retry
0        0       0       0-1         76   Prompt
0-1      0       0       0           77   Connect-Info
0        0+      0       0           78   Configuration-Token
0+       0+      0+      0+          79   EAP-Message [Note 1]
0-1      0-1     0-1     0-1         80   Message-Authenticator [Note 1]
0        0-1     0       0-1         84   ARAP-Challenge-Response
0        0-1     0       0           85   Acct-Interim-Interval
0-1      0       0       0           87   NAS-Port-Id
0        0-1     0       0           88   Framed-Pool
Request  Accept  Reject  Challenge   #    Attribute
=20
The first paragraph's first three sentences seem to imply that the
attributes named can *only* be present in an Acccounting-Request.
Otherwise why wouldn't that paragraph have listed all the packets that
these attributes could be included in?

------_=_NextPart_001_01C7A138.9439A852
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D918055214-28052007>Perhaps.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D918055214-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D918055214-28052007>But there =
are no formal=20
words in the table.&nbsp; The first three sentences use terms like =
"guide" "may=20
be".</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D918055214-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D918055214-28052007>It also =
uses must not be=20
present in an Accounting-Request.&nbsp; So why wouldnt the document make =
a=20
similar strong statement about those attribute,</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D918055214-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D918055214-28052007>If it was =
intended not to=20
be in those messages I would suggest the attributes would have appeared =
in the=20
table with zeros in the corresponding columns.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D918055214-28052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D918055214-28052007>I think =
that document is=20
ambiguous in this matter.</SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<B>From:</B> Bernard Aboba [mailto:[email-masked]] =
<BR><B>Sent:</B>=20
Friday, May 25, 2007 6:59 PM<BR><B>To:</B> Avi Lior; Alan =
DeKok<BR><B>Cc:</B>=20
[email-masked]<BR><B>Subject:</B> RE: Issue 223: Event-Timestamp =
and=20
Duplicate Detection<BR><BR></DIV>
<DIV></DIV>&gt; No. If it was prohibited in an Access-Request, Accept, =
Reject=20
etc... It<BR>&gt; would have specifically stated that. <BR><BR>Here's =
what RFC=20
2869 Section 5.19 says:<BR>&nbsp;<BR>&nbsp;&nbsp; The following table =
provides a=20
guide to which attributes may be found<BR>&nbsp;&nbsp; in which kind of=20
packets.&nbsp; Acct-Input-Gigawords, Acct-Output-<BR>&nbsp;&nbsp; =
Gigawords,=20
Event-Timestamp, and NAS-Port-Id may have 0-1 instances =
in<BR>&nbsp;&nbsp; an=20
Accounting-Request packet.&nbsp; Connect-Info may have 0+ instances=20
in<BR>&nbsp;&nbsp; an Accounting-Request packet.&nbsp; The other =
attributes=20
added in this<BR>&nbsp;&nbsp; document must not be present in an=20
Accounting-Request.<BR><BR>Request&nbsp; Accept&nbsp; Reject&nbsp;=20
Challenge&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp;=20
Attribute<BR>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
70&nbsp;&nbsp;=20
ARAP-Password [Note 1]<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 71&nbsp;&nbsp;=20
ARAP-Features<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
72&nbsp;&nbsp;=20
ARAP-Zone-Access<BR>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 73&nbsp;&nbsp;=20
ARAP-Security<BR>0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 74&nbsp;&nbsp;=20
ARAP-Security-Data<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
75&nbsp;&nbsp;=20
Password-Retry<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 76&nbsp;&nbsp;=20
Prompt<BR>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
77&nbsp;&nbsp;=20
Connect-Info<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
78&nbsp;&nbsp;=20
Configuration-Token<BR>0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 79&nbsp;&nbsp;=20
EAP-Message [Note 1]<BR>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 80&nbsp;&nbsp;=20
Message-Authenticator [Note =
1]<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 84&nbsp;&nbsp;=20
ARAP-Challenge-Response<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
85&nbsp;&nbsp;=20
Acct-Interim-Interval<BR>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
87&nbsp;&nbsp;=20
NAS-Port-Id<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
88&nbsp;&nbsp;=20
Framed-Pool<BR>Request&nbsp; Accept&nbsp; Reject&nbsp; =
Challenge&nbsp;&nbsp;=20
#&nbsp;&nbsp;&nbsp; Attribute<BR>&nbsp;<BR>The first paragraph's first =
three=20
sentences&nbsp;seem to imply that the attributes named can *only* be =
present in=20
an Acccounting-Request.&nbsp; Otherwise why wouldn't that paragraph have =
listed=20
all the packets that these attributes could be included=20
in?<BR><BR></BODY></HTML>

------_=_NextPart_001_01C7A138.9439A852--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 28 May 2007 14:56:18 +0000
Date: Mon, 28 May 2007 16:55:25 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue 227:  Proxy State

Bernard Aboba wrote:
> Some responses from RFC 3576 implementers are enclosed below  Any thoughts on how we should proceed?

  Update the text with the version you posted below.

  I'm a little surprised that there aren't more implementations of
proxying CoA, etc.  I guess most people decided it was too complex.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 27 May 2007 20:27:45 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Link to strawman RFC 3576bis -07 document
Date: Sun, 27 May 2007 13:27:33 -0700

--_fcb88119-43bd-4727-a3de-4268a82d8cc3_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I've now gone over the draft again, to introduce the term "Dynamic Authoriz=
ation Server" where appropriate.=20

From: [email-masked]: [email-masked]: Link to s=
trawman RFC 3576bis -07 documentDate: Sat, 26 May 2007 09:43:41 -0700

FYI, here is a link to an RFC 3576bis-07 strawman, with most of the suggest=
ed changes made:http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-rfc3=
576bis-07.txtThis strawman does not yet include changes to reflect Issue 22=
7:  Proxy State. =

--_fcb88119-43bd-4727-a3de-4268a82d8cc3_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
I've now gone over the draft again, to introduce the term "Dynamic Authoriz=
ation Server" where appropriate.&nbsp;<BR>
<BLOCKQUOTE>
<HR>
From: [email-masked]<BR>To: [email-masked]<BR>Subject: L=
ink to strawman RFC 3576bis -07 document<BR>Date: Sat, 26 May 2007 09:43:41=
 -0700<BR><BR>
<META content=3D"Microsoft SafeHTML" name=3DGenerator>
<STYLE>
.ExternalClass P
{padding:0px;}
.ExternalClass
{font-size:10pt;font-family:Tahoma;}
</STYLE>
FYI, here is a link to an RFC 3576bis-07 strawman, with most of the suggest=
ed changes made:<BR><BR>http://www.drizzle.com/~aboba/RADEXT/draft-ietf-rad=
ext-rfc3576bis-07.txt<BR><BR>This strawman does not yet include changes to =
reflect Issue 227:&nbsp; Proxy State. <BR></BLOCKQUOTE></body>
</html>=

--_fcb88119-43bd-4727-a3de-4268a82d8cc3_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 27 May 2007 20:10:10 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Sun, 27 May 2007 13:09:58 -0700

--_2af9aa07-7e42-41f4-bba1-ed88b65da6cd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

How is this?=20
=20
"A NAS implementing this specification SHOULD send an Acct-Session-Idor Acc=
t-Multi-Session-Id Attribute within an Access-Request.Where an Acct-Session=
-Id or Acct-Multi-Session-Id Attribute is notincluded within an Access-Requ=
est, the Dynamic Authorizatoin Client will not know the Acct-Session-Idor A=
cct-Multi-Session-Id of the session it is attempting to target,unless it al=
so has access to the accounting data for that session.
=20
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is notpresent i=
n a CoA-Request or Disconnect-Request, it is possible that thethe User-Name=
 or Chargeable-User-Identity attributes will not be sufficient to uniquely =
identify the session (e.g. if the sameuser has multiple sessions on the NAS=
, or if the privacy NAI is used). In this case, session identification MAY =
be performed by using one or more ofthe Called-Station-Id, Calling-Station-=
Id, NAS-Port andNAS-Port-Id attributes."> Date: Sun, 27 May 2007 13:52:46 +=
0100> From: [email-masked]> To: [email-masked]> CC: radiusext=
@ops.ietf.org> Subject: Re: RFC3576bis and Session State> > Bernard Aboba w=
rote:> ...> > To something like this:> > > > "A NAS implementing this speci=
fication SHOULD send an Acct-Session-Id or > > Acct-Multi-Session-Id Attrib=
ute within an Access-Request. However, > > where the Acct-Session-Id or Acc=
t-Multi-Session-Id is not included > > within an Access-Request,> > the Dyn=
amic Authorization Client will not know the Acct-Session-Id or> Acct-Multi-=
Session-Id of the session it is attempting to target, unless> it also has a=
ccess to the accounting data for that session.> > > Where an Acct-Session-I=
d or Acct-Multi-Session-Id Attribute is not > > present in a CoA-Request or=
 Disconnect-Request,> > the User-Name or Chargeable-User-Identity attribute=
s may be> sufficient to uniquely identify the session. However, if the same=
 user> has multiple sessions on the NAS, or if the privacy NAI is used, tha=
t > information may be insufficient to uniquely identify a session. Session=
 > identification MAY be performed by using one or more of the > Called-Sta=
tion-Id, Calling-Station-Id, NAS-Port and> NAS-Port-Id attributes.> > ? The=
 question now becomes how does the client determine which > attributes to s=
end if there's no session ID attribute? Maybe recommend: > CUI or else User=
-Name (unless it's anonymous) or Calling-Station-Id, etc.> > > I can add a =
sentence to Section saying "A NAS implementing this > > specification SHOUL=
D send> > an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an >=
 > Access-Request."> > Yes. Also note that doing so makes the CoA network m=
uch simpler and > more robust. I would prefer it to be a MUST, but that's p=
robably too > strong. Maybe a strong recommendation in addition to SHOULD.>=
 > Alan DeKok.=

--_2af9aa07-7e42-41f4-bba1-ed88b65da6cd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
How is this? <BR>
&nbsp;<BR>
"A NAS implementing this specification SHOULD send an Acct-Session-Id<BR>or=
 Acct-Multi-Session-Id Attribute within an Access-Request.<BR>Where an Acct=
-Session-Id or Acct-Multi-Session-Id Attribute is not<BR>included within an=
 Access-Request, the Dynamic Authorizatoin Client will not know the Acct-Se=
ssion-Id<BR>or Acct-Multi-Session-Id of the session it is attempting to tar=
get,<BR>unless it also has access to the accounting data for that session.<=
BR>
&nbsp;<BR>
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not<BR>prese=
nt in a CoA-Request or Disconnect-Request, it is possible that the<BR>the U=
ser-Name or Chargeable-User-Identity attributes will not be <BR>sufficient =
to uniquely identify the session (e.g. if the same<BR>user has multiple ses=
sions on the NAS, or if the privacy NAI is used). <BR>In this case, session=
 identification MAY be performed by using one or more of<BR>the Called-Stat=
ion-Id, Calling-Station-Id, NAS-Port and<BR>NAS-Port-Id attributes."<BR><BR=
><BR>&gt; Date: Sun, 27 May 2007 13:52:46 +0100<BR>&gt; From: aland@nitros9=
.org<BR>&gt; To: [email-masked]<BR>&gt; CC: [email-masked]=
rg<BR>&gt; Subject: Re: RFC3576bis and Session State<BR>&gt; <BR>&gt; Berna=
rd Aboba wrote:<BR>&gt; ...<BR>&gt; &gt; To something like this:<BR>&gt; &g=
t; <BR>&gt; &gt; "A NAS implementing this specification SHOULD send an Acct=
-Session-Id or <BR>&gt; &gt; Acct-Multi-Session-Id Attribute within an Acce=
ss-Request. However, <BR>&gt; &gt; where the Acct-Session-Id or Acct-Multi-=
Session-Id is not included <BR>&gt; &gt; within an Access-Request,<BR>&gt; =
<BR>&gt; the Dynamic Authorization Client will not know the Acct-Session-Id=
 or<BR>&gt; Acct-Multi-Session-Id of the session it is attempting to target=
, unless<BR>&gt; it also has access to the accounting data for that session=
.<BR>&gt; <BR>&gt; &gt; Where an Acct-Session-Id or Acct-Multi-Session-Id A=
ttribute is not <BR>&gt; &gt; present in a CoA-Request or Disconnect-Reques=
t,<BR>&gt; <BR>&gt; the User-Name or Chargeable-User-Identity attributes ma=
y be<BR>&gt; sufficient to uniquely identify the session. However, if the s=
ame user<BR>&gt; has multiple sessions on the NAS, or if the privacy NAI is=
 used, that <BR>&gt; information may be insufficient to uniquely identify a=
 session. Session <BR>&gt; identification MAY be performed by using one or =
more of the <BR>&gt; Called-Station-Id, Calling-Station-Id, NAS-Port and<BR=
>&gt; NAS-Port-Id attributes.<BR>&gt; <BR>&gt; ? The question now becomes h=
ow does the client determine which <BR>&gt; attributes to send if there's n=
o session ID attribute? Maybe recommend: <BR>&gt; CUI or else User-Name (un=
less it's anonymous) or Calling-Station-Id, etc.<BR>&gt; <BR>&gt; &gt; I ca=
n add a sentence to Section saying "A NAS implementing this <BR>&gt; &gt; s=
pecification SHOULD send<BR>&gt; &gt; an Acct-Session-Id or Acct-Multi-Sess=
ion-Id Attribute within an <BR>&gt; &gt; Access-Request."<BR>&gt; <BR>&gt; =
Yes. Also note that doing so makes the CoA network much simpler and <BR>&gt=
; more robust. I would prefer it to be a MUST, but that's probably too <BR>=
&gt; strong. Maybe a strong recommendation in addition to SHOULD.<BR>&gt; <=
BR>&gt; Alan DeKok.<BR><BR></body>
</html>=

--_2af9aa07-7e42-41f4-bba1-ed88b65da6cd_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 27 May 2007 19:58:59 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: <[email-masked]>
Subject: RE: Issue: RPF Check
Date: Sun, 27 May 2007 12:58:02 -0700

--_e52d9af2-e476-4082-afb8-8a4b60e3329e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Let me know whether this works for you.=20
=20
I have added a definition of "Dynamic Authorization Server" to the terminol=
ogy section:
=20
Dynamic Authorization Client (DAC)     The entity originating Change of Aut=
horization (CoA) Requests or     Disconnect-Requests.  While it is possible=
 that the DAC is co-     resident with a RADIUS authentication or accountin=
g server, this     need not necessarily be the case.Dynamic Authorization S=
erver (DAS)     The entity receiving CoA-Request or Disconnect-Request pack=
ets.     The DAS may be a NAS or a RADIUS proxy.Network Access Server (NAS)=
     The device providing access to the network.=20
Here is the new text of Section 6.1:
=20
6.1.  Authorization Issues   Where a NAS is shared by multiple providers, i=
t is undesirable for   one provider to be able to send Disconnect-Request o=
r CoA-Requests   affecting the sessions of another provider.   A Dynamic Au=
thorization Server MUST silently discard Disconnect-   Request or CoA-Reque=
st packets from untrusted sources.  In situations   where the Dynamic Autho=
rization Client is co-resident with a RADIUS   authentication or accounting=
 server, a proxy MAY perform a "reverse   path forwarding" (RPF) check to v=
erify that a Disconnect-Request or   CoA-Request originates from an authori=
zed Dynamic Authorization   Client.  In addition, it SHOULD be possible to =
explicitly authorize   additional sources of Disconnect-Request or CoA-Requ=
est packets   relating to certain classes of sessions.  For example, a part=
icular   source can be explicitly authorized to send CoA-Request packets   =
relating to users within a set of realms.   To perform the RPF check, the D=
ynamic Authorization Server uses the   session identification attributes in=
cluded in Disconnect-Request or   CoA-Request packets, in order to determin=
e the RADIUS server(s) to   which an equivalent Access-Request could be rou=
ted.  If the source   address of the Disconnect-Request or CoA-Request is w=
ithin this set,   then the CoA-Request or Disconnect-Request is forwarded; =
otherwise it   MUST be silently discarded.   Typically the Dynamic Authoriz=
ation Server will extract the realm   from the Network Access Identifier [R=
FC4282] included within the   User-Name or Chargeble-User-Identity Attribut=
e, and determine the   corresponding RADIUS servers in the realm routing ta=
bles.  If the   Dynamic Authorization Server maintains long-term session st=
ate, it   MAY perform the authorization check based on the session   identi=
fication attributes in the CoA-Request.  The session   identification attri=
butes can be used to tie a session to a   particular proxy or set of proxie=
s, as with the NAI realm.   Where no proxy is present, the RPF check can on=
ly be performed by the   NAS if it maintains its own a realm routing table.=
  If the NAS does   not maintain a realm routing table (e.g. it selects for=
warding   proxies based on primary/secondary configuration and/or liveness =
  checks), then an RPF check cannot be performed.   Since authorization to =
send a Disconnect-Request or CoA-Request is   determined based on the sourc=
e address and the corresponding shared   secret, the Dynamic Authorization =
Server SHOULD configure a different   shared secret for each Dynamic Author=
ization Client."=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> Date=
: Sun, 27 May 2007 09:39:39 +0100> From: [email-masked]> To: bernard_abo=
[email-masked]> CC: [email-masked]> Subject: Re: Issue: RPF Check> =
> Bernard Aboba wrote:> > It has been pointed out that the Dynamic Authoriz=
ation Client (the > > entity originating the CoA or Disconnect-Request) nee=
d not be > > co-resident with a RADIUS authentication or accounting server.=
 > > However, Section 6.1 seems to assume that this is the case. In cases >=
 > where the Dynamic Authorization Client is not co-resident with the > > R=
ADIUS authentication or authorization server, the RPF check cannot be > > a=
pplied. I would therefore question whether it is appropriate to > > recomme=
nd use of the RPF check by default.> > I agree. However, the RPF check was =
an attempt to prevent > unauthorized servers from performing CoA requests. =
We should make a > note of that problem, and potential methods for addressi=
ng it. See below.> > > Note that this is not the only place where the disti=
nction between a > > RADIUS server and a Dynamic Authorization Client needs=
 to be made. > > > > The proposed resolution is as follows:> ...> > I agree=
.> > > 2. Add the following terms to the terminology section:> ...> > I agr=
ee.> > We may also want to note that a proxying server acts as a NAS to the=
 > Dynamic Authorization Client, and as a Dynamic Authorization Client to >=
 the NAS. We should probably use new terminology for such a server, > rathe=
r than calling it a RADIUS server. Maybe a "Dynamic Authorization > Server"=
.> > > 3. Change Section 6.1 to the following, downgrading the RPF check to=
 a > > MAY and clarifying that it is only applicable when the RADIUS server=
 and > > Dynamic Authorization Client are co-resident.> > OK.> > > 6.1. Aut=
horization Issues> > > > Where a NAS is shared by multiple providers, it is=
 undesirable for> > one provider to be able to send Disconnect-Request or C=
oA-Requests> > affecting the sessions of another provider.> ...> > Typicall=
y the proxy will extract the realm from the Network Access> > Identifier [R=
FC4282] included within the User-Name Attribute, and> > determine the corre=
sponding RADIUS servers in the proxy routing> > tables. The RADIUS servers =
for that realm are then compared against> > the source address of the packe=
t. > > Do we want to add "or the CUI", since the NAI may be anonymized? > A=
lso, the proxying decision may be based on other attributes, such as > clie=
nt source IP, or calling station Id.> > I would then add:> > If the RADIUS =
server maintains long-term session state, it MAY > perform the authorizatio=
n checks based on the session identification > attributes in the CoA reques=
t. The session identification attributes > can be used to tie a session to =
a particular forwarding server or set of > servers, as with the NAI and rea=
lm, above.> > > Where no proxy is present, the RPF> > check will need to be=
 performed by the NAS itself.> > Only if the NAS performs policy-based rout=
ing on the RADIUS requests. > If the NAS selects servers by live/dead statu=
s, or by load-balancing, > then the RPF checks do not need to be performed.=
> > Alan DeKok.=

--_e52d9af2-e476-4082-afb8-8a4b60e3329e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Let me know whether this works for you. <BR>
&nbsp;<BR>
I have added a definition of "Dynamic Authorization Server" to the terminol=
ogy section:<BR>
&nbsp;<BR>
Dynamic Authorization Client (DAC)<BR>&nbsp;&nbsp;&nbsp;&nbsp; The entity o=
riginating Change of Authorization (CoA) Requests or<BR>&nbsp;&nbsp;&nbsp;&=
nbsp; Disconnect-Requests.&nbsp; While it is possible that the DAC is co-<B=
R>&nbsp;&nbsp;&nbsp;&nbsp; resident with a RADIUS authentication or account=
ing server, this<BR>&nbsp;&nbsp;&nbsp;&nbsp; need not necessarily be the ca=
se.<BR><BR>Dynamic Authorization Server (DAS)<BR>&nbsp;&nbsp;&nbsp;&nbsp; T=
he entity receiving CoA-Request or Disconnect-Request packets.<BR>&nbsp;&nb=
sp;&nbsp;&nbsp; The DAS may be a NAS or a RADIUS proxy.<BR><BR>Network Acce=
ss Server (NAS)<BR>&nbsp;&nbsp;&nbsp;&nbsp; The device providing access to =
the network.<BR>&nbsp;<BR>
Here is the new text of Section 6.1:<BR>
&nbsp;<BR>
6.1.&nbsp; Authorization Issues<BR><BR>&nbsp;&nbsp; Where a NAS is shared b=
y multiple providers, it is undesirable for<BR>&nbsp;&nbsp; one provider to=
 be able to send Disconnect-Request or CoA-Requests<BR>&nbsp;&nbsp; affecti=
ng the sessions of another provider.<BR><BR>&nbsp;&nbsp; A Dynamic Authoriz=
ation Server MUST silently discard Disconnect-<BR>&nbsp;&nbsp; Request or C=
oA-Request packets from untrusted sources.&nbsp; In situations<BR>&nbsp;&nb=
sp; where the Dynamic Authorization Client is co-resident with a RADIUS<BR>=
&nbsp;&nbsp; authentication or accounting server, a proxy MAY perform a "re=
verse<BR>&nbsp;&nbsp; path forwarding" (RPF) check to verify that a Disconn=
ect-Request or<BR>&nbsp;&nbsp; CoA-Request originates from an authorized Dy=
namic Authorization<BR>&nbsp;&nbsp; Client.&nbsp; In addition, it SHOULD be=
 possible to explicitly authorize<BR>&nbsp;&nbsp; additional sources of Dis=
connect-Request or CoA-Request packets<BR>&nbsp;&nbsp; relating to certain =
classes of sessions.&nbsp; For example, a particular<BR>&nbsp;&nbsp; source=
 can be explicitly authorized to send CoA-Request packets<BR>&nbsp;&nbsp; r=
elating to users within a set of realms.<BR><BR>&nbsp;&nbsp; To perform the=
 RPF check, the Dynamic Authorization Server uses the<BR>&nbsp;&nbsp; sessi=
on identification attributes included in Disconnect-Request or<BR>&nbsp;&nb=
sp; CoA-Request packets, in order to determine the RADIUS server(s) to<BR>&=
nbsp;&nbsp; which an equivalent Access-Request could be routed.&nbsp; If th=
e source<BR>&nbsp;&nbsp; address of the Disconnect-Request or CoA-Request i=
s within this set,<BR>&nbsp;&nbsp; then the CoA-Request or Disconnect-Reque=
st is forwarded; otherwise it<BR>&nbsp;&nbsp; MUST be silently discarded.<B=
R><BR>&nbsp;&nbsp; Typically the Dynamic Authorization Server will extract =
the realm<BR>&nbsp;&nbsp; from the Network Access Identifier [RFC4282] incl=
uded within the<BR>&nbsp;&nbsp; User-Name or Chargeble-User-Identity Attrib=
ute, and determine the<BR>&nbsp;&nbsp; corresponding RADIUS servers in the =
realm routing tables.&nbsp; If the<BR>&nbsp;&nbsp; Dynamic Authorization Se=
rver maintains long-term session state, it<BR>&nbsp;&nbsp; MAY perform the =
authorization check based on the session<BR>&nbsp;&nbsp; identification att=
ributes in the CoA-Request.&nbsp; The session<BR>&nbsp;&nbsp; identificatio=
n attributes can be used to tie a session to a<BR>&nbsp;&nbsp; particular p=
roxy or set of proxies, as with the NAI realm.<BR><BR>&nbsp;&nbsp; Where no=
 proxy is present, the RPF check can only be performed by the<BR>&nbsp;&nbs=
p; NAS if it maintains its own a realm routing table.&nbsp; If the NAS does=
<BR>&nbsp;&nbsp; not maintain a realm routing table (e.g. it selects forwar=
ding<BR>&nbsp;&nbsp; proxies based on primary/secondary configuration and/o=
r liveness<BR>&nbsp;&nbsp; checks), then an RPF check cannot be performed.<=
BR><BR>&nbsp;&nbsp; Since authorization to send a Disconnect-Request or CoA=
-Request is<BR>&nbsp;&nbsp; determined based on the source address and the =
corresponding shared<BR>&nbsp;&nbsp; secret, the Dynamic Authorization Serv=
er SHOULD configure a different<BR>&nbsp;&nbsp; shared secret for each Dyna=
mic Authorization Client."<BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<BR>&gt; Date: Sun, 27 May 2007 09:39:39 +0100<BR>&gt; From: al=
[email-masked]<BR>&gt; To: [email-masked]<BR>&gt; CC: radiusext=
@ops.ietf.org<BR>&gt; Subject: Re: Issue: RPF Check<BR>&gt; <BR>&gt; Bernar=
d Aboba wrote:<BR>&gt; &gt; It has been pointed out that the Dynamic Author=
ization Client (the <BR>&gt; &gt; entity originating the CoA or Disconnect-=
Request) need not be <BR>&gt; &gt; co-resident with a RADIUS authentication=
 or accounting server. <BR>&gt; &gt; However, Section 6.1 seems to assume t=
hat this is the case. In cases <BR>&gt; &gt; where the Dynamic Authorizatio=
n Client is not co-resident with the <BR>&gt; &gt; RADIUS authentication or=
 authorization server, the RPF check cannot be <BR>&gt; &gt; applied. I wou=
ld therefore question whether it is appropriate to <BR>&gt; &gt; recommend =
use of the RPF check by default.<BR>&gt; <BR>&gt; I agree. However, the RPF=
 check was an attempt to prevent <BR>&gt; unauthorized servers from perform=
ing CoA requests. We should make a <BR>&gt; note of that problem, and poten=
tial methods for addressing it. See below.<BR>&gt; <BR>&gt; &gt; Note that =
this is not the only place where the distinction between a <BR>&gt; &gt; RA=
DIUS server and a Dynamic Authorization Client needs to be made. <BR>&gt; &=
gt; <BR>&gt; &gt; The proposed resolution is as follows:<BR>&gt; ...<BR>&gt=
; <BR>&gt; I agree.<BR>&gt; <BR>&gt; &gt; 2. Add the following terms to the=
 terminology section:<BR>&gt; ...<BR>&gt; <BR>&gt; I agree.<BR>&gt; <BR>&gt=
; We may also want to note that a proxying server acts as a NAS to the <BR>=
&gt; Dynamic Authorization Client, and as a Dynamic Authorization Client to=
 <BR>&gt; the NAS. We should probably use new terminology for such a server=
, <BR>&gt; rather than calling it a RADIUS server. Maybe a "Dynamic Authori=
zation <BR>&gt; Server".<BR>&gt; <BR>&gt; &gt; 3. Change Section 6.1 to the=
 following, downgrading the RPF check to a <BR>&gt; &gt; MAY and clarifying=
 that it is only applicable when the RADIUS server and <BR>&gt; &gt; Dynami=
c Authorization Client are co-resident.<BR>&gt; <BR>&gt; OK.<BR>&gt; <BR>&g=
t; &gt; 6.1. Authorization Issues<BR>&gt; &gt; <BR>&gt; &gt; Where a NAS is=
 shared by multiple providers, it is undesirable for<BR>&gt; &gt; one provi=
der to be able to send Disconnect-Request or CoA-Requests<BR>&gt; &gt; affe=
cting the sessions of another provider.<BR>&gt; ...<BR>&gt; &gt; Typically =
the proxy will extract the realm from the Network Access<BR>&gt; &gt; Ident=
ifier [RFC4282] included within the User-Name Attribute, and<BR>&gt; &gt; d=
etermine the corresponding RADIUS servers in the proxy routing<BR>&gt; &gt;=
 tables. The RADIUS servers for that realm are then compared against<BR>&gt=
; &gt; the source address of the packet. <BR>&gt; <BR>&gt; Do we want to ad=
d "or the CUI", since the NAI may be anonymized? <BR>&gt; Also, the proxyin=
g decision may be based on other attributes, such as <BR>&gt; client source=
 IP, or calling station Id.<BR>&gt; <BR>&gt; I would then add:<BR>&gt; <BR>=
&gt; If the RADIUS server maintains long-term session state, it MAY <BR>&gt=
; perform the authorization checks based on the session identification <BR>=
&gt; attributes in the CoA request. The session identification attributes <=
BR>&gt; can be used to tie a session to a particular forwarding server or s=
et of <BR>&gt; servers, as with the NAI and realm, above.<BR>&gt; <BR>&gt; =
&gt; Where no proxy is present, the RPF<BR>&gt; &gt; check will need to be =
performed by the NAS itself.<BR>&gt; <BR>&gt; Only if the NAS performs poli=
cy-based routing on the RADIUS requests. <BR>&gt; If the NAS selects server=
s by live/dead status, or by load-balancing, <BR>&gt; then the RPF checks d=
o not need to be performed.<BR>&gt; <BR>&gt; Alan DeKok.<BR><BR></body>
</html>=

--_e52d9af2-e476-4082-afb8-8a4b60e3329e_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 27 May 2007 12:53:36 +0000
Date: Sun, 27 May 2007 13:52:46 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC3576bis and Session State

Bernard Aboba wrote:
...
> To something like this:
> 
> "A NAS implementing this specification SHOULD send an Acct-Session-Id or 
> Acct-Multi-Session-Id Attribute within an Access-Request.  However, 
> where the Acct-Session-Id or Acct-Multi-Session-Id is not included 
> within an Access-Request,

  the Dynamic Authorization Client will not know the Acct-Session-Id or
Acct-Multi-Session-Id of the session it is attempting to target, unless
it also has access to the accounting data for that session.

> Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not 
> present in a CoA-Request or Disconnect-Request,

  the User-Name or Chargeable-User-Identity attributes may be
sufficient to uniquely identify the session.  However, if the same user
has multiple sessions on the NAS, or if the privacy NAI is used, that 
information may be insufficient to uniquely identify a session.  Session 
identification MAY be performed by using one or more of the 
Called-Station-Id, Calling-Station-Id,  NAS-Port and
NAS-Port-Id attributes.

   ? The question now becomes how does the client determine which 
attributes to send if there's no session ID attribute?  Maybe recommend: 
CUI or else User-Name (unless it's anonymous) or Calling-Station-Id, etc.

> I can add a sentence to Section saying "A NAS implementing this 
> specification SHOULD send
> an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an 
> Access-Request."

   Yes.  Also note that doing so makes the CoA network much simpler and 
more robust.  I would prefer it to be a MUST, but that's probably too 
strong.  Maybe a strong recommendation in addition to SHOULD.

   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 27 May 2007 08:40:31 +0000
Date: Sun, 27 May 2007 09:39:39 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue: RPF Check

Bernard Aboba wrote:
> It has been pointed out that the Dynamic Authorization Client (the 
> entity originating the CoA or Disconnect-Request) need not be 
> co-resident with a RADIUS authentication or accounting server.   
> However, Section 6.1 seems to assume that this is the case.  In cases 
> where the Dynamic Authorization Client is not co-resident with the 
> RADIUS authentication or authorization server, the RPF check cannot be 
> applied.  I would therefore question whether it is appropriate to 
> recommend use of the RPF check by default.

   I agree.  However, the RPF check was an attempt to prevent 
unauthorized servers from performing CoA requests.  We should make a 
note of that problem, and potential methods for addressing it.  See below.

> Note that this is not the only place where the distinction between a 
> RADIUS server and a Dynamic Authorization Client needs to be made.  
> 
> The proposed resolution is as follows:
...

   I agree.

> 2. Add the following terms to the terminology section:
...

   I agree.

   We may also want to note that a proxying server acts as a NAS to the 
Dynamic Authorization Client, and as a Dynamic Authorization Client to 
the NAS.  We should probably use new terminology for such a server, 
rather than calling it a RADIUS server.  Maybe a "Dynamic Authorization 
Server".

> 3. Change Section 6.1 to the following, downgrading the RPF check to a 
> MAY and clarifying that it is only applicable when the RADIUS server and 
> Dynamic Authorization Client are co-resident.

   OK.

> 6.1.  Authorization Issues
> 
>    Where a NAS is shared by multiple providers, it is undesirable for
>    one provider to be able to send Disconnect-Request or CoA-Requests
>    affecting the sessions of another provider.
...
>    Typically the proxy will extract the realm from the Network Access
>    Identifier [RFC4282] included within the User-Name Attribute, and
>    determine the corresponding RADIUS servers in the proxy routing
>    tables.  The RADIUS servers for that realm are then compared against
>    the source address of the packet.  

   Do we want to add "or the CUI", since the NAI may be anonymized? 
Also, the proxying decision may be based on other attributes, such as 
client source IP, or calling station Id.

   I would then add:

   If the RADIUS server maintains long-term session state, it MAY 
perform the authorization checks based on the session identification 
attributes in the CoA request.  The session identification attributes 
can be used to tie a session to a particular forwarding server or set of 
servers, as with the NAI and realm, above.

 > Where no proxy is present, the RPF
 >    check will need to be performed by the NAS itself.

   Only if the NAS performs policy-based routing on the RADIUS requests. 
  If the NAS selects servers by live/dead status, or by load-balancing, 
then the RPF checks do not need to be performed.

   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 27 May 2007 02:26:40 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Sat, 26 May 2007 13:53:59 -0400

Glen Zorn writes...

> > One problem with that draft is that the RADEXT WG charter 
> > disallows the introduction of new commands.
> 
> Ah, so!  Are you _sure_?  Are you positive that 10 minutes after
> we submit it to the RFC Editor as an individual submission it won't
> magically become in conflict w/this WG's charter?

I think you're aware of the history of the RADEXT charter, but I'll review
it briefly for those who may not be.  RADEXT was formed to publish some
Proposed Standard and Informational RFCs creating narrowly targeted
extensions to RADIUS, to meet a set of requirements that were fomenting in
the Internet community and had no formal outlet.  The charter was defined
narrowly because the O&M ADs at the time (Randy Bush and Bert Wijnen), with
the support of the IESG, wanted to avoid creating a RADIUS V2 protocol.
Diameter was recently completed at that time, and enhancing RADIUS to
duplicate some of Diameter's features was considered to be a waste of time
and effort in the IETF.

The RADEXT WG charter is narrow to prevent extensive changes to RADIUS in
the RADEXT WG.  It seems ironic, if not downright odd, that the IESG would
want to see publication of documents creating extensive changes to RADIUS by
independent submission to the RFC Editor, if they don't want to see that
level of change via the WG process.  OTOH, the people are going to do what
they need to do to fulfill perceived customer demands, so I don't know that
the IETF can prevent you from extending RADIUS in ways seen to be
"detrimental".

I personally think it would be better to do that kind of work in the IETF,
or to not do it at all.  YMMV.  Of course, charters are subject to revision,
especially if there is a demonstrated need in the Internet community and all
the rest of the chartered work has been completed.  So, no, I'm not
_absolutely_ sure.  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 16:44:19 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Link to strawman RFC 3576bis -07 document
Date: Sat, 26 May 2007 09:43:41 -0700

--_03d1b9fb-10a2-4938-b3c1-b6780d533978_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FYI, here is a link to an RFC 3576bis-07 strawman, with most of the suggest=
ed changes made:http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-rfc3=
576bis-07.txtThis strawman does not yet include changes to reflect Issue 22=
7:  Proxy State. =

--_03d1b9fb-10a2-4938-b3c1-b6780d533978_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
FYI, here is a link to an RFC 3576bis-07 strawman, with most of the suggest=
ed changes made:<br><br>http://www.drizzle.com/~aboba/RADEXT/draft-ietf-rad=
ext-rfc3576bis-07.txt<br><br>This strawman does not yet include changes to =
reflect Issue 227:&nbsp; Proxy State. <br></body>
</html>=

--_03d1b9fb-10a2-4938-b3c1-b6780d533978_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 16:15:01 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Sat, 26 May 2007 09:14:50 -0700

--_2e7b6932-e1b5-445c-af18-fd1c5b203471_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Date: Sat, 26 May 2007 16:16:31 +0100> From: [email-masked]> To: berna=
[email-masked]> Subject: Re: RFC3576bis and Session State> > Bernard =
Aboba wrote:> >  > I suggest we can request that they implement it now, *if=
* they also> >  > support CoA or Disconnect request.> > > > [BA] Are you su=
ggesting that NASes implementing RFC 3576bis SHOULD send > > the Acct-Sessi=
on-Id within an Access-Request?> >    Yes.  Or, Acct-Multi-Session-Id, whic=
h may address Avi's concerns > over multiple Acct-Session-Id's for one "ses=
sion".\[BA]  Hmm...  Perhaps we need a change in Section 3 from:"As noted i=
n [RFC2866] Section 5.5:An Accounting-Request packet MUST have an Acct-Sess=
ion-Id.  AnAccess-Request packet MAY have an Acct-Session-Id; if it does,th=
en the NAS MUST use the same Acct-Session-Id in the Accounting-Requestpacke=
ts for that session.Since the Acct-Session-Id is optional in Access-Request=
s,if the Dynamic Authorization Client only has access toattributes sent to =
or by the RADIUS authentication server, then itwill not necessarily know th=
e Acct-Session-Id of the session it is attemptingto target.Where the Acct-S=
ession-Id Attribute is not present ina CoA-Request or Disconnect-Request,it=
 is possible that the User-Name or Chargeable-User-Identityattributes will =
not be sufficient to uniquely identify the session (e.g. if the sameuser ha=
s multiple sessions on the NAS, or the privacy NAI is used).As a result, on=
e or more of the Acct-Multi-Session-Id,Called-Station-Id, Calling-Station-I=
d, NAS-Port and NAS-Port-Id attributesMAY be used as additional session ide=
ntification."To something like this: "A NAS implementing this specification=
 SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id Attribute within a=
n Access-Request.  However, where the Acct-Session-Id or Acct-Multi-Session=
-Id is not included within an Access-Request, unless the Dynamic Authorizat=
ion Client has access to accounting data, it is possible that the Dynamic A=
uthorization Client will not know the Acct-Session-Id or Acct-Multi-Session=
-Id of the session it is attempting to target.Where an Acct-Session-Id or A=
cct-Multi-Session-Id Attribute is not present in a CoA-Request or Disconnec=
t-Request, it is possible that the User-Name or Chargeable-User-Identity at=
tributes will not be sufficient to uniquely identify the session (e.g. if t=
he same user has multiple sessions on the NAS or the privacy NAI is used). =
 As a result, one or more of the Called-Station-Id, Calling-Station-Id,  NA=
S-Port and NAS-Port-Id attributes MAY be used as additional session identif=
ication." I can add a sentence to Section saying "A NAS implementing this s=
pecification SHOULD sendan Acct-Session-Id or Acct-Multi-Session-Id Attribu=
te within an Access-Request." > >    Requiring this would avoid the issue o=
f Framed-IP-Address being used > as both a key for the session, and the tar=
get of the change request, > which was the start of this thread.[BA] Actual=
ly, it seems like it might make it unnecessary to use an IP address as a se=
ssion identification attribute. >    Requiring a session identification att=
ribute would avoid the ad-hoc > session identification.  i.e. IPv4, IPv6, a=
nd fields from other > protocols used to identify sessions?  Are we going t=
o update the RFC's > every time someone uses RADIUS to authorize a new prot=
ocol?>>    Or, we can define a protocol-independent key, and use that for a=
ll > protocols, old and new.[BA] That seems like a better idea. > >    Alan=
 DeKok.=

--_2e7b6932-e1b5-445c-af18-fd1c5b203471_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<br><br>&gt; Date: Sat, 26 May 2007 16:16:31 +0100<br>&gt; From: aland@nitr=
os9.org<br>&gt; To: [email-masked]<br>&gt; Subject: Re: RFC3576b=
is and Session State<br>&gt; <br>&gt; Bernard Aboba wrote:<br>&gt; &gt;  &g=
t; I suggest we can request that they implement it now, *if* they also<br>&=
gt; &gt;  &gt; support CoA or Disconnect request.<br>&gt; &gt; <br>&gt; &gt=
; [BA] Are you suggesting that NASes implementing RFC 3576bis SHOULD send <=
br>&gt; &gt; the Acct-Session-Id within an Access-Request?<br>&gt; <br>&gt;=
    Yes.  Or, Acct-Multi-Session-Id, which may address Avi's concerns <br>&=
gt; over multiple Acct-Session-Id's for one "session".\<br><br>[BA]&nbsp; H=
mm...&nbsp; Perhaps we need a change in Section 3 from:<br><br>"As noted in=
 [RFC2866] Section 5.5:<br><br>An Accounting-Request packet MUST have an Ac=
ct-Session-Id.&nbsp; An<br>Access-Request packet MAY have an Acct-Session-I=
d; if it does,<br>then the NAS MUST use the same Acct-Session-Id in the Acc=
ounting-Request<br>packets for that session.<br><br>Since the Acct-Session-=
Id is optional in Access-Requests,<br>if the Dynamic Authorization Client o=
nly has access to<br>attributes sent to or by the RADIUS authentication ser=
ver, then it<br>will not necessarily know the Acct-Session-Id of the sessio=
n it is attempting<br>to target.<br><br>Where the Acct-Session-Id Attribute=
 is not present in<br>a CoA-Request or Disconnect-Request,<br>it is possibl=
e that the User-Name or Chargeable-User-Identity<br>attributes will not be =
sufficient to uniquely identify the session (e.g. if the same<br>user has m=
ultiple sessions on the NAS, or the privacy NAI is used).<br>As a result, o=
ne or more of the Acct-Multi-Session-Id,<br>Called-Station-Id, Calling-Stat=
ion-Id, NAS-Port and NAS-Port-Id attributes<br>MAY be used as additional se=
ssion identification."<br><br>To something like this: <br><br>"A NAS implem=
enting this specification SHOULD send an Acct-Session-Id or Acct-Multi-Sess=
ion-Id Attribute within an Access-Request.&nbsp; However, where the Acct-Se=
ssion-Id or Acct-Multi-Session-Id is not included within an Access-Request,=
 unless the Dynamic Authorization Client has access to accounting data, it =
is possible that the Dynamic Authorization Client will not know the Acct-Se=
ssion-Id or Acct-Multi-Session-Id of the session it is attempting to target=
.<br><br>Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not=
 present in a CoA-Request or Disconnect-Request, it is possible that the Us=
er-Name or Chargeable-User-Identity attributes will not be sufficient to un=
iquely identify the session (e.g. if the same user has multiple sessions on=
 the NAS or the privacy NAI is used).&nbsp; As a result, one or more of the=
 Called-Station-Id, Calling-Station-Id,&nbsp; NAS-Port and NAS-Port-Id attr=
ibutes MAY be used as additional session identification." <br><br><br>I can=
 add a sentence to Section saying "A NAS implementing this specification SH=
OULD send<br>an Acct-Session-Id or Acct-Multi-Session-Id Attribute within a=
n Access-Request." <br><br>&gt; <br>&gt;    Requiring this would avoid the =
issue of Framed-IP-Address being used <br>&gt; as both a key for the sessio=
n, and the target of the change request, <br>&gt; which was the start of th=
is thread.<br><br>[BA] Actually, it seems like it might make it unnecessary=
 to use an IP address as a session identification attribute.<br>&nbsp;<br>&=
gt;    Requiring a session identification attribute would avoid the ad-hoc =
<br>&gt; session identification.  i.e. IPv4, IPv6, and fields from other <b=
r>&gt; protocols used to identify sessions?  Are we going to update the RFC=
's <br>&gt; every time someone uses RADIUS to authorize a new protocol?<br>=
&gt;<br>&gt;    Or, we can define a protocol-independent key, and use that =
for all <br>&gt; protocols, old and new.<br><br>[BA] That seems like a bett=
er idea. <br><br>&gt; <br>&gt;    Alan DeKok.<br></body>
</html>=

--_2e7b6932-e1b5-445c-af18-fd1c5b203471_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 16:04:16 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, <[email-masked]>, Bernard Aboba <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Sat, 26 May 2007 09:03:59 -0700

--_7d903fb1-29af-4533-ab1d-0c104977d1ba_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Date: Sat, 26 May 2007 15:46:46 +0100> From: [email-masked]> To: avi@b=
ridgewatersystems.com> CC: [email-masked]; [email-masked]=
rg; [email-masked]> Subject: Re: Issue 226:  RFC 3576bis an=
d Renumbering> > Avi Lior wrote:> > Accounting Session ID only identifies a=
n accounting session Start/Stop> > and its interims, if any.  A given "sess=
ion" (IP Session or> > Access-Session) may contain a number of parallel acc=
ounting 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, bu=
t not much else is true.> >    The problem at hand, I think, is less Acct-S=
ession-Id than in > figuring out what the CoA packet refers to.  My proposa=
l is to key the > CoA to a session Id (whatever it's called), which now all=
ows 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 v=
alue".> > > 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 iden=
tification 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 so=
mewhat complicated to define a different set of session identification attr=
ibutes for CoA and Disconnect-Requests.  Also, unless the NAS previously re=
ceived Framed-IP-Address or Framed-IPv6-Prefix/Framed-Interface-Id attribut=
es in an Access-Accept it typically will not know the user's IP address.  T=
his 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.)Wher=
e an Access-Request was received with an Acct-Session-Id or an Accounting-R=
equest is received, the Acct-Session-Id can be used as the session identifi=
er. Where only an Access-Request is available, with no Acct-Session-Id, oth=
er session identification attributes can be used (NAS-Port/NAS-Port-Id, Use=
r-Name).  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 t=
he 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. > >    Alan DeKok.> > --> to unsubscribe send a message to radius=
[email-masked] with> the word 'unsubscribe' in a single line as t=
he message text body.> archive: <http://psg.com/lists/radiusext/>=

--_7d903fb1-29af-4533-ab1d-0c104977d1ba_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<br><br>&gt; Date: Sat, 26 May 2007 15:46:46 +0100<br>&gt; From: aland@nitr=
os9.org<br>&gt; To: [email-masked]<br>&gt; CC: dnelson@elbrysne=
tworks.com; [email-masked]; [email-masked]<br>&gt; =
Subject: Re: Issue 226:  RFC 3576bis and Renumbering<br>&gt; <br>&gt; Avi L=
ior wrote:<br>&gt; &gt; Accounting Session ID only identifies an accounting=
 session Start/Stop<br>&gt; &gt; and its interims, if any.  A given "sessio=
n" (IP Session or<br>&gt; &gt; Access-Session) may contain a number of para=
llel accounting sessions, or<br>&gt; &gt; a sequence of accounting sessions=
.<br>&gt; <br>&gt;    I see what you're saying, but I'm not sure I agree.  =
The <br>&gt; Acct-Session-Id defines a session that the Acct-Session-Id ref=
ers to. <br>&gt; It's a circular reference, but not much else is true.<br>&=
gt; <br>&gt;    The problem at hand, I think, is less Acct-Session-Id than =
in <br>&gt; figuring out what the CoA packet refers to.  My proposal is to =
key the <br>&gt; CoA to a session Id (whatever it's called), which now allo=
ws the CoA to <br>&gt; request changes to other portions of the session.<br=
>&gt; <br>&gt;    If we key off of IP/port, then as Bernard pointed out, we=
 can't send <br>&gt; Framed-IP-Address as both a session key and as an indi=
cation to "use <br>&gt; this new value".<br>&gt; <br>&gt; &gt; When it come=
s to 3576 and DM or even COA:<br>&gt; &gt; <br>&gt; &gt; We need to be able=
 to terminate or modify the Session WRT to A.  That<br>&gt; &gt; is, sendin=
g a DM with an NAI or some other user identification, we<br>&gt; &gt; termi=
nate all of the users IP sessions.<br>&gt; &gt; <br>&gt; &gt; We need to be=
 able to terminate or modify any of the users IP sessions.<br>&gt; &gt; The=
refore sending a DM which includes a user identification and an IP<br>&gt; =
&gt; address will only terminate that users IP session.<br>&gt; <br>&gt;   =
 Using IP's as a key to terminate a session is fine.  Using them as a <br>&=
gt; key *and* as a "new value" in a change request is not.<br><br>[BA] It w=
ould be somewhat complicated to define a different set of session identific=
ation attributes for CoA and Disconnect-Requests.&nbsp; Also, unless the NA=
S previously received Framed-IP-Address or Framed-IPv6-Prefix/Framed-Interf=
ace-Id attributes in an Access-Accept it typically will not know the user's=
 IP address.&nbsp; This is the situation with most NAS-Port-Type values, wi=
th the exception of PPP or protocols depending on PPP (e.g. PPPOE, PPPOA, L=
2TP, PPTP, etc.)<br><br>Where an Access-Request was received with an Acct-S=
ession-Id or an Accounting-Request is received, the Acct-Session-Id can be =
used as the session identifier. <br><br>Where only an Access-Request is ava=
ilable, with no Acct-Session-Id, other session identification attributes ca=
n be used (NAS-Port/NAS-Port-Id, User-Name).&nbsp; <br><br>So it's hard to =
imagine a case where the IP address is *required* as a session identifier.&=
nbsp;&nbsp; And there are quite a few situations in which the NAS will be u=
nable to identify the session by IP address.&nbsp;&nbsp; Given this, encour=
aging the use of the IP address as a session identifier seems like a bad id=
ea. <br><br><br>&gt; <br>&gt;    Alan DeKok.<br>&gt; <br>&gt; --<br>&gt; to=
 unsubscribe send a message to [email-masked] with<br>&gt; =
the word 'unsubscribe' in a single line as the message text body.<br>&gt; a=
rchive: &lt;http://psg.com/lists/radiusext/&gt;<br></body>
</html>=

--_7d903fb1-29af-4533-ab1d-0c104977d1ba_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 15:36:39 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC3576bis and Session State
Date: Sat, 26 May 2007 08:36:07 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Saturday, May 26, 2007 8:22
AM:

> Alan DeKok writes...
>=20
>>>  Since both the RADIUS server and client have to change to support
>>> your suggestion, it would be really cool if we could actually
>>> _solve_ that problem here instead of just applying YABA, don't you
>>> think?
>>=20
>>    My suggestion is only relevant to new implementations of CoA, in
>> which case they're changing anyways...
>=20
> Yes, but I think Glen is fishing for support for his "logoff" draft,
> in which he introduces a new RADIUS command types, that allow the NAS
> to explicitly signal the=20

beginning and the

> end of a session to the RADIUS Server.  One
> problem with that draft is that the RADEXT WG charter disallows the
> introduction of new commands.  =20

Ah, so!  Are you _sure_?  Are you positive that 10 minutes after we
submit it to the RFC Editor as an individual submission it won't
magically become in conflict w/this WG's charter?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 15:23:15 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC3576bis and Session State
Date: Sat, 26 May 2007 11:22:05 -0400

Alan DeKok writes...

> >  Since both the RADIUS server and client have to change to
> > support your suggestion, it would be really cool if we could actually
> > _solve_ that problem here instead of just applying YABA, don't you
> > think?
> 
>    My suggestion is only relevant to new implementations of CoA, in
> which case they're changing anyways...

Yes, but I think Glen is fishing for support for his "logoff" draft, in
which he introduces a new RADIUS command types, that allow the NAS to
explicitly signal the end of a session to the RADIUS Server.  One problem
with that draft is that the RADEXT WG charter disallows the introduction of
new commands.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 15:15:29 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue: Attribute restriction
Date: Sat, 26 May 2007 11:14:15 -0400

Bernard Aboba writes...

>The proposed resolution is to change this sentence to:
>
>   This Access-Request SHOULD contain the NAS
>   identification attributes from the CoA-Request, as well as the
>   session identification attributes from the CoA-Request legal for

s/legal/permitted/

>   inclusion in an Access-Request.

I always cringe when I see the word "legal" in a protocol document.  I start
looking around for the protocol attorneys.  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 15:06:05 +0000
Date: Sat, 26 May 2007 16:06:05 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue: Attribute restriction

Bernard Aboba wrote:
> The proposed resolution is to change this sentence to:

   I agree.

   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 15:05:24 +0000
Date: Sat, 26 May 2007 16:05:15 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue: Acct-Session-Id clarification

Bernard Aboba wrote:
> The proposed resolution is to insert the following text in Section 3:

   I agree.

   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 14:46:54 +0000
Date: Sat, 26 May 2007 15:46:46 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  [email-masked], Bernard Aboba <[email-masked]>
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.

   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 14:39:07 +0000
Date: Sat, 26 May 2007 15:38:40 +0100
From: Alan DeKok <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: RFC3576bis and Session State

Glen Zorn (gwz) wrote:
...
>>   What I'm saying is that the NAS knows what a session is: the user
>> is connected to it.  The NAS has the information that ties
>> authentication packets to accounting packets:  the Acct-Session-Id. 
> 
> Only if it supports RADIUS accounting, which I believe you stated is not
> mandatory.

   The NAS can send Acct-Session-Id in an Access-Request without ever 
sending an Accounting-Request packet.  This is permitted by the existing 
specifications.

>>   Once the Acct-Session-Id is available to the authentication server,
>> it can be used to tie authentication sessions 
> 
> which don't exist

   The NAS thinks they do.  That's all that really matters.

   If the authentication server receives a session ID attribute in an 
Access-Request packet, the possible options are:

   1) Session exists on the NAS when the CoA packet is sent
   2) Session does not exist on the NAS when the CoA packet is sent.

   For condition (1), CoA works as desired.  For condition (2), the NAS 
sends a CoA-Nak, and the authentication server can nuke it's session for 
that ID.

> presumably by letting the RADIUS server grovel through thousands of
> accounting records (if they exist).  Of course, knowing the location and
> format of these records doesn't constitute an "undefined but incestuous
> relationship".

   Maybe I'm missing something.  I thought I was proposing that the 
authentication server track sessions by ID sent in Access-Request, not 
in Accounting-Request.

> OK, one simple question: when and how does the RADIUS server (since it's
> not necessarily the same as the accounting server & therefore will not
> necessarily receive Accounting Stop records) know that the session has
> ended and that it can therefore discard that data? 

   When it is the same as the accounting server, there's no problem. 
When it isn't, it can use attributes like "Session-Timeout" to track 
when the session is supposed to end.

   Note that the failure condition you're worried about is exactly the 
same as the failure condition when other attributes are used for session 
identification.  So suggesting that we use Acct-Session-Id changes nothing.

   The failure you're worried about is that the machine sending CoA may 
not have access to the accounting data.  The simple answer, then, is 
"design your network so that the machine needing data can access it".

> I really think it's been painfully obvious for some time (at least since
> the publication of RFC 3576) that RADIUS servers are no longer the nice,
> stateless things they were presumed to be by RFC 2865

   Well, yes.  That's been true for a long time now.

> and that RADIUS
> servers need a way to keep track of user sessions _outside_ of
> accounting.

   Mostly.  There are few deployments where the authentication server 
needs access to the accounting data.  There are many deployments where 
the accounting data triggers CoA packets... in which case the sender of 
the CoA has access to the accounting information.

>  Since both the RADIUS server and client have to change to
> support your suggestion, it would be really cool if we could actually
> _solve_ that problem here instead of just applying YABA, don't you
> think?

   My suggestion is only relevant to new implementations of CoA, in 
which case they're changing anyways...

   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 14:27:26 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Issue: Attribute restriction
Date: Sat, 26 May 2007 07:26:54 -0700

--_6f7839fd-11f4-49f6-bd62-fa9a014e3da1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue:  Attribute Restriction
Submitter name: Bernard AbobaSubmitter email address: [email-masked]=
te first submitted: May 26, 2007Reference: Document: RFC3576bis-06Comment t=
ype: TechnicalPriority: SSection: 3.2Rationale/Explanation of issue:Section=
 3.2 contains the following sentence:   This Access-Request SHOULD contain =
the NAS   identification attributes from the CoA-Request, as well as the   =
session identification attributes from the CoA-Request legal for   inclusio=
n in an Access-Request as specified in [RFC2865], [RFC2868],   [RFC2869] an=
d [RFC3162].  This sentence appears to imply that only session identificati=
on attributes from [RFC2865], [RFC2868], [RFC2869] and [RFC3162] can be inc=
luded in the Access-Request.  In fact, RFC 3576bis adds Chargeable-User-Ide=
ntity to the list of session identification attributes; this is defined in =
a documentthat is not listed.The proposed resolution is to change this sent=
ence to:   This Access-Request SHOULD contain the NAS   identification attr=
ibutes from the CoA-Request, as well as the   session identification attrib=
utes from the CoA-Request legal for   inclusion in an Access-Request.=

--_6f7839fd-11f4-49f6-bd62-fa9a014e3da1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>

Issue:&nbsp; Attribute Restriction<br>
Submitter name: Bernard Aboba<br>Submitter email address: [email-masked]=
om<br>Date first submitted: May 26, 2007<br>Reference: <br>Document: RFC357=
6bis-06<br>Comment type: Technical<br>Priority: S<br>Section: 3.2<br>Ration=
ale/Explanation of issue:<br><br>Section 3.2 contains the following sentenc=
e:<br><pre>   This Access-Request SHOULD contain the NAS<br>   identificati=
on attributes from the CoA-Request, as well as the<br>   session identifica=
tion attributes from the CoA-Request legal for<br>   inclusion in an Access=
-Request as specified in [RFC2865], [RFC2868],<br>   [RFC2869] and [RFC3162=
].  <br><br>This sentence appears to imply that only session identification=
 attributes <br>from [RFC2865], [RFC2868], [RFC2869] and [RFC3162] can be i=
ncluded in the <br>Access-Request.  In fact, RFC 3576bis adds Chargeable-Us=
er-Identity to the <br>list of session identification attributes; this is d=
efined in a document<br>that is not listed.<br><br>The proposed resolution =
is to change this sentence to:<br><br>   This Access-Request SHOULD contain=
 the NAS<br>   identification attributes from the CoA-Request, as well as t=
he<br>   session identification attributes from the CoA-Request legal for<b=
r>   inclusion in an Access-Request.<br></pre></body>
</html>=

--_6f7839fd-11f4-49f6-bd62-fa9a014e3da1_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 14:16:37 +0000
Date: Sat, 26 May 2007 15:16:27 +0100
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: RFC3576bis and Session State

David B. Nelson wrote:
> It is entirely possible that RADIUS client implementations that do not
> include RADIUS Accounting may not have implemented the Acct-Session-Id
> attribute. They would have no need to.

   I suggest we can request that they implement it now, *if* they also
support CoA or Disconnect request.

> OTOH, I don't think we need to get too hung up about the nomenclature of the
> attribute.  The fact at the prefix is Acct should not be sufficient to
> disqualify its usage as a session identifier for the authentication server
> as well as the accounting server.  A session ID is a session ID.

   I agree.  Hence my suggestion to use Acct-Session-Id.

   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 14:07:54 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Issue: Consolidation of "Authorize Only" Text
Date: Sat, 26 May 2007 07:07:38 -0700

--_5e88a630-8c61-486b-8574-33631f4acbe7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue:  Consolidation of "Authorize Only" Text
Submitter name: Bernard AbobaSubmitter email address: [email-masked]=
te first submitted: May 26, 2007Reference: Document: RFC3576bis-06Comment t=
ype: EditorialPriority: SSection: 3.2, 4 Rationale/Explanation of issue:Cur=
rently text relating to "Authorize Only" usage is included within Section 4=
 as well as Section 3.1.  Having normative text in two places makes the doc=
ument harder to read, and also can potentially introduce contradictions.   =
   The proposed resolution is as follows:Change the following paragraph in =
Section 4 from:"  To simplify translation between RADIUS and Diameter, a se=
rver   compliant with this specification MAY include a Service-Type   Attri=
bute with value "Authorize Only" within a CoA-Request.  Such a   CoA-Reques=
t MUST contain a State Attribute.  A NAS supporting the   "Authorize Only" =
Service-Type within a CoA-Request responds with a   CoA-NAK containing a Se=
rvice-Type Attribute with value "Authorize   Only", and an Error-Cause Attr=
ibute with value "Request Initiated".   The NAS will then send an Access-Re=
quest containing a Service-Type   Attribute with a value of "Authorize Only=
", along with a State   Attribute.  A Diameter/RADIUS gateway receiving a C=
oA-Request   containing a Service-Type with value "Authorize Only" translat=
es this   to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY=
".   The received RAA is then translated to a CoA-NAK with a Service-Type  =
 value of "Authorize Only".   If the Result-Code AVP in the RAA has a   val=
ue in the success category, then an Error-Cause Attribute with   value "Req=
uest Initiated" is included in the CoA-NAK.   If the   Result-Code AVP in t=
he RAA has a value indicating a Protocol Error or   a Transient or Permanen=
t Failure, then an alternate Error-Cause   Attribute is returned as suggest=
ed below."To:"  To simplify translation between RADIUS and Diameter, Dynami=
c   Authorization Clients can include a Service-Type Attribute with value  =
 "Authorize Only" within a CoA-Request, as described in Section 3.2.   A Di=
ameter/RADIUS gateway receiving a CoA-Request containing a   Service-Type w=
ith value "Authorize Only" translates this to a RAR   with Re-Auth-Request-=
Type AVP with value "AUTHORIZE ONLY".  The   received RAA is then translate=
d to a CoA-NAK with a Service-Type   value of "Authorize Only".   If the Re=
sult-Code AVP in the RAA has a   value in the success category, then an Err=
or-Cause Attribute with   value "Request Initiated" is included in the CoA-=
NAK.   If the   Result-Code AVP in the RAA has a value indicating a Protoco=
l Error or   a Transient or Permanent Failure, then an alternate Error-Caus=
e   Attribute is returned as suggested below."Change Section 3.2 from:"3.2.=
  Authorize Only   Support for a CoA-Request including a Service-Type Attri=
bute with   value "Authorize Only" is OPTIONAL on the NAS and RADIUS server=
.  A   Service-Type Attribute MUST NOT be included within a Disconnect-   R=
equest.   A NAS MUST respond to a CoA-Request including a Service-Type   At=
tribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST   NOT be=
 sent.  If the NAS does not support a Service-Type value of   "Authorize On=
ly" then it MUST respond with a CoA-NAK; an Error-Cause   value of 405 (Uns=
upported Service) SHOULD be included.   A CoA-Request containing a Service-=
Type Attribute with value   "Authorize Only" MUST in addition contain only =
NAS or session   identification attributes, as well as a State Attribute.  =
If other   attributes are included in such a CoA-Request, a CoA-NAK MUST be=
   sent; an Error-Cause Attribute with value 401 (Unsupported Attribute)   =
SHOULD be included.   If a CoA-Request packet including a Service-Type valu=
e of "Authorize   Only" is successfully processed, the NAS MUST respond wit=
h a CoA-NAK   containing a Service-Type Attribute with value "Authorize Onl=
y", and   an Error-Cause Attribute with value 507 (Request Initiated).  The=
 NAS   then MUST send an Access-Request to the RADIUS server including a   =
Service-Type Attribute with value "Authorize Only".  This Access-   Request=
 SHOULD contain the NAS identification attributes from the   CoA-Request, a=
s well as the session identification attributes from   the CoA-Request lega=
l for inclusion in an Access-Request as specified   in [RFC2865], [RFC2868]=
, [RFC2869] and [RFC3162].  As noted in   [RFC2869] Section 5.19, a Message=
-Authenticator attribute SHOULD be   included in an Access-Request that doe=
s not contain a User-Password,   CHAP-Password, ARAP-Password or EAP-Messag=
e Attribute.  The RADIUS   server then will respond to the Access-Request w=
ith an Access-Accept   to (re-)authorize the session or an Access-Reject to=
 refuse to   (re-)authorize it."To:"3.2 Authorize Only   Support for a CoA-=
Request including a Service-Type Attribute with   value "Authorize Only" is=
 OPTIONAL on the NAS and Dynamic   Authorization Client.  A Service-Type At=
tribute MUST NOT be included   within a Disconnect-Request.   A NAS MUST re=
spond to a CoA-Request including a Service-Type   Attribute with value "Aut=
horize Only" with a CoA-NAK; a CoA-ACK MUST   NOT be sent.  If the NAS does=
 not support a Service-Type value of   "Authorize Only" then it MUST respon=
d with a CoA-NAK; an Error-Cause   value of 405 (Unsupported Service) SHOUL=
D be included.   A CoA-Request containing a Service-Type Attribute with val=
ue   "Authorize Only" MUST in addition contain only NAS or session   identi=
fication attributes, as well as a State Attribute.  If other   attributes a=
re included in such a CoA-Request, a CoA-NAK MUST be   sent; an Error-Cause=
 Attribute with value 401 (Unsupported Attribute)   SHOULD be included.   I=
f a CoA-Request packet including a Service-Type value of "Authorize   Only"=
 is successfully processed, the NAS MUST respond with a CoA-NAK   containin=
g a Service-Type Attribute with value "Authorize Only", and   an Error-Caus=
e Attribute with value 507 (Request Initiated).  The NAS   then MUST send a=
n Access-Request to the RADIUS server including a   Service-Type Attribute =
with value "Authorize Only", along with a   State Attribute.  This Access-R=
equest SHOULD contain the NAS   identification attributes from the CoA-Requ=
est, as well as the   session identification attributes from the CoA-Reques=
t legal for   inclusion in an Access-Request as specified in [RFC2865], [RF=
C2868],   [RFC2869] and [RFC3162].  As noted in [RFC2869] Section 5.19, a  =
 Message-Authenticator attribute SHOULD be included in an Access-   Request=
 that does not contain a User-Password, CHAP-Password, ARAP-   Password or =
EAP-Message Attribute.  The RADIUS server   then will respond to the Access=
-Request with an Access-Accept to   (re-)authorize the session or an Access=
-Reject to refuse to   (re-)authorize it."=

--_5e88a630-8c61-486b-8574-33631f4acbe7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>

Issue:&nbsp; Consolidation of "Authorize Only" Text<br>
Submitter name: Bernard Aboba<br>Submitter email address: [email-masked]=
om<br>Date first submitted: May 26, 2007<br>Reference: <br>Document: RFC357=
6bis-06<br>Comment type: Editorial<br>Priority: S<br>Section: 3.2, 4 <br>Ra=
tionale/Explanation of issue:<br><br>Currently text relating to "Authorize =
Only" usage is included within Section 4 as well as Section 3.1.&nbsp; Havi=
ng normative text in two places makes the document harder to read, and also=
 can potentially introduce contradictions. &nbsp; &nbsp;  <br><br>The propo=
sed resolution is as follows:<br><br>Change the following paragraph in Sect=
ion 4 from:<br><br><pre>"  To simplify translation between RADIUS and Diame=
ter, a server<br>   compliant with this specification MAY include a Service=
-Type<br>   Attribute with value "Authorize Only" within a CoA-Request.  Su=
ch a<br>   CoA-Request MUST contain a State Attribute.  A NAS supporting th=
e<br>   "Authorize Only" Service-Type within a CoA-Request responds with a<=
br>   CoA-NAK containing a Service-Type Attribute with value "Authorize<br>=
   Only", and an Error-Cause Attribute with value "Request Initiated".<br> =
  The NAS will then send an Access-Request containing a Service-Type<br>   =
Attribute with a value of "Authorize Only", along with a State<br>   Attrib=
ute.  A Diameter/RADIUS gateway receiving a CoA-Request<br>   containing a =
Service-Type with value "Authorize Only" translates this<br>   to a RAR wit=
h Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".<br>   The received =
RAA is then translated to a CoA-NAK with a Service-Type<br>   value of "Aut=
horize Only".   If the Result-Code AVP in the RAA has a<br>   value in the =
success category, then an Error-Cause Attribute with<br>   value "Request I=
nitiated" is included in the CoA-NAK.   If the<br>   Result-Code AVP in the=
 RAA has a value indicating a Protocol Error or<br>   a Transient or Perman=
ent Failure, then an alternate Error-Cause<br>   Attribute is returned as s=
uggested below."<br><br>To:<br><br>"  To simplify translation between RADIU=
S and Diameter, Dynamic<br>   Authorization Clients can include a Service-T=
ype Attribute with value<br>   "Authorize Only" within a CoA-Request, as de=
scribed in Section 3.2.<br>   A Diameter/RADIUS gateway receiving a CoA-Req=
uest containing a<br>   Service-Type with value "Authorize Only" translates=
 this to a RAR<br>   with Re-Auth-Request-Type AVP with value "AUTHORIZE ON=
LY".  The<br>   received RAA is then translated to a CoA-NAK with a Service=
-Type<br>   value of "Authorize Only".   If the Result-Code AVP in the RAA =
has a<br>   value in the success category, then an Error-Cause Attribute wi=
th<br>   value "Request Initiated" is included in the CoA-NAK.   If the<br>=
   Result-Code AVP in the RAA has a value indicating a Protocol Error or<br=
>   a Transient or Permanent Failure, then an alternate Error-Cause<br>   A=
ttribute is returned as suggested below."<br></pre><br>Change Section 3.2 f=
rom:<br><pre>"3.2.  Authorize Only<br><br>   Support for a CoA-Request incl=
uding a Service-Type Attribute with<br>   value "Authorize Only" is OPTIONA=
L on the NAS and RADIUS server.  A<br>   Service-Type Attribute MUST NOT be=
 included within a Disconnect-<br>   Request.<br><br>   A NAS MUST respond =
to a CoA-Request including a Service-Type<br>   Attribute with value "Autho=
rize Only" with a CoA-NAK; a CoA-ACK MUST<br>   NOT be sent.  If the NAS do=
es not support a Service-Type value of<br>   "Authorize Only" then it MUST =
respond with a CoA-NAK; an Error-Cause<br>   value of 405 (Unsupported Serv=
ice) SHOULD be included.<br><br>   A CoA-Request containing a Service-Type =
Attribute with value<br>   "Authorize Only" MUST in addition contain only N=
AS or session<br>   identification attributes, as well as a State Attribute=
.  If other<br>   attributes are included in such a CoA-Request, a CoA-NAK =
MUST be<br>   sent; an Error-Cause Attribute with value 401 (Unsupported At=
tribute)<br>   SHOULD be included.<br><br>   If a CoA-Request packet includ=
ing a Service-Type value of "Authorize<br>   Only" is successfully processe=
d, the NAS MUST respond with a CoA-NAK<br>   containing a Service-Type Attr=
ibute with value "Authorize Only", and<br>   an Error-Cause Attribute with =
value 507 (Request Initiated).  The NAS<br>   then MUST send an Access-Requ=
est to the RADIUS server including a<br>   Service-Type Attribute with valu=
e "Authorize Only".  This Access-<br>   Request SHOULD contain the NAS iden=
tification attributes from the<br>   CoA-Request, as well as the session id=
entification attributes from<br>   the CoA-Request legal for inclusion in a=
n Access-Request as specified<br>   in [RFC2865], [RFC2868], [RFC2869] and =
[RFC3162].  As noted in<br>   [RFC2869] Section 5.19, a Message-Authenticat=
or attribute SHOULD be<br>   included in an Access-Request that does not co=
ntain a User-Password,<br>   CHAP-Password, ARAP-Password or EAP-Message At=
tribute.  The RADIUS<br>   server then will respond to the Access-Request w=
ith an Access-Accept<br>   to (re-)authorize the session or an Access-Rejec=
t to refuse to<br>   (re-)authorize it."<br></pre><br>To:<br><pre><br>"3.2 =
Authorize Only<br><br>  &nbsp;Support for a CoA-Request including a Service=
-Type Attribute with<br>   value "Authorize Only" is OPTIONAL on the NAS an=
d Dynamic<br>   Authorization Client.  A Service-Type Attribute MUST NOT be=
 included<br>   within a Disconnect-Request.<br><br>   A NAS MUST respond t=
o a CoA-Request including a Service-Type<br>   Attribute with value "Author=
ize Only" with a CoA-NAK; a CoA-ACK MUST<br>   NOT be sent.  If the NAS doe=
s not support a Service-Type value of<br>   "Authorize Only" then it MUST r=
espond with a CoA-NAK; an Error-Cause<br>   value of 405 (Unsupported Servi=
ce) SHOULD be included.<br><br>   A CoA-Request containing a Service-Type A=
ttribute with value<br>   "Authorize Only" MUST in addition contain only NA=
S or session<br>   identification attributes, as well as a State Attribute.=
  If other<br>   attributes are included in such a CoA-Request, a CoA-NAK M=
UST be<br>   sent; an Error-Cause Attribute with value 401 (Unsupported Att=
ribute)<br>   SHOULD be included.<br><br>   If a CoA-Request packet includi=
ng a Service-Type value of "Authorize<br>   Only" is successfully processed=
, the NAS MUST respond with a CoA-NAK<br>   containing a Service-Type Attri=
bute with value "Authorize Only", and<br>   an Error-Cause Attribute with v=
alue 507 (Request Initiated).  The NAS<br>   then MUST send an Access-Reque=
st to the RADIUS server including a<br>   Service-Type Attribute with value=
 "Authorize Only", along with a<br>   State Attribute.  This Access-Request=
 SHOULD contain the NAS<br>   identification attributes from the CoA-Reques=
t, as well as the<br>   session identification attributes from the CoA-Requ=
est legal for<br>   inclusion in an Access-Request as specified in [RFC2865=
], [RFC2868],<br>   [RFC2869] and [RFC3162].  As noted in [RFC2869] Section=
 5.19, a<br>   Message-Authenticator attribute SHOULD be included in an Acc=
ess-<br>   Request that does not contain a User-Password, CHAP-Password, AR=
AP-<br>   Password or EAP-Message Attribute.  The RADIUS server<br>   then =
will respond to the Access-Request with an Access-Accept to<br>   (re-)auth=
orize the session or an Access-Reject to refuse to<br>   (re-)authorize it.=
"<br></pre><br><br></body>
</html>=

--_5e88a630-8c61-486b-8574-33631f4acbe7_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 13:45:28 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Issue: Acct-Session-Id clarification
Date: Sat, 26 May 2007 06:45:14 -0700

--_8aca63d3-9a22-42d9-9861-de27090414f3_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue:  Acct-Session-Id clarification
Submitter name: Bernard AbobaSubmitter email address: [email-masked]=
te first submitted: May 24, 2007Reference: Document: RFC3576bis-06Comment t=
ype: TechnicalPriority: SSection: 3Rationale/Explanation of issue:It has be=
en pointed out that the Acct-Session-Id attribute is not mandatory in Acces=
s-Requests and that a Dynamic Authorization Client will not necessarily hav=
e access to information sent in Accounting-Request packets.  This point see=
ms worth addressing explicitly.  The proposed resolution is to insert the f=
ollowing text in Section 3:  As noted in [RFC2866] Section 5.5:      An Acc=
ounting-Request packet MUST have an Acct-Session-Id.  An      Access-Reques=
t packet MAY have an Acct-Session-Id; if it does,      then the NAS MUST us=
e the same Acct-Session-Id in the Accounting-      Request packets for that=
 session.   Since the Acct-Session-Id is optional in Access-Requests, if th=
e   Dynamic Authorization Client only has access to attributes sent to or  =
 by the RADIUS authentication server, then it will not necessarily   know t=
he Acct-Session-Id of the session it is attempting to target.=

--_8aca63d3-9a22-42d9-9861-de27090414f3_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>

Issue:&nbsp; Acct-Session-Id clarification<br>
Submitter name: Bernard Aboba<br>Submitter email address: [email-masked]=
om<br>Date first submitted: May 24, 2007<br>Reference: <br>Document: RFC357=
6bis-06<br>Comment type: Technical<br>Priority: S<br>Section: 3<br>Rational=
e/Explanation of issue:<br><br>It has been pointed out that the Acct-Sessio=
n-Id attribute is not mandatory in Access-Requests and that a Dynamic Autho=
rization Client will not necessarily have access to information sent in Acc=
ounting-Request packets.&nbsp; This point seems worth addressing explicitly=
.&nbsp; <br><br>The proposed resolution is to insert the following text in =
Section 3:<br><pre>  As noted in [RFC2866] Section 5.5:<br><br>      An Acc=
ounting-Request packet MUST have an Acct-Session-Id.  An<br>      Access-Re=
quest packet MAY have an Acct-Session-Id; if it does,<br>      then the NAS=
 MUST use the same Acct-Session-Id in the Accounting-<br>      Request pack=
ets for that session.<br><br>   Since the Acct-Session-Id is optional in Ac=
cess-Requests, if the<br>   Dynamic Authorization Client only has access to=
 attributes sent to or<br>   by the RADIUS authentication server, then it w=
ill not necessarily<br>   know the Acct-Session-Id of the session it is att=
empting to target.<br></pre><br></body>
</html>=

--_8aca63d3-9a22-42d9-9861-de27090414f3_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 26 May 2007 13:27:32 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Issue: RPF Check
Date: Sat, 26 May 2007 06:26:31 -0700

--_57282573-2553-4b52-b6e7-3f2fc37bed35_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue:  RPF Check
Submitter name: Bernard AbobaSubmitter email address: [email-masked]=
te first submitted: May 24, 2007Reference: Document: RFC3576bis-06Comment t=
ype: TechnicalPriority: SSection: VariousRationale/Explanation of issue:It =
has been pointed out that the Dynamic Authorization Client (the entity orig=
inating the CoA or Disconnect-Request) need not be co-resident with a RADIU=
S authentication or accounting server.   However, Section 6.1 seems to assu=
me that this is the case.  In cases where the Dynamic Authorization Client =
is not co-resident with the RADIUS authentication or authorization server, =
the RPF check cannot be applied.  I would therefore question whether it is =
appropriate to recommend use of the RPF check by default. Note that this is=
 not the only place where the distinction between a RADIUS server and a Dyn=
amic Authorization Client needs to be made.   The proposed resolution is as=
 follows:1. Change the term "RADIUS server" to "Dynamic Authorization Clien=
t" everywhere the term is being used to refer to the originator of CoA or D=
isconnect-Request packets.  Use the term "NAS" consistently when referring =
to the recipient of a CoA or Disconnect-Request packet. 2. Add the followin=
g terms to the terminology section:Dynamic Authorization Client (DAC)     T=
he entity originating Change of Authorization (CoA) or Disconnect-     Requ=
ests.  While it is possible that the DAC is co-resident with a     RADIUS a=
uthentication or accounting server, this need not     necessarily be the ca=
se.Network Access Server (NAS)     The device providing access to the netwo=
rk.  Sometimes also known     as the Dynamic Authorization Server (DAS) or =
RADIUS client.3. Change Section 6.1 to the following, downgrading the RPF c=
heck to a MAY and clarifying that it is only applicable when the RADIUS ser=
ver and Dynamic Authorization Client are co-resident. 6.1.  Authorization I=
ssues   Where a NAS is shared by multiple providers, it is undesirable for =
  one provider to be able to send Disconnect-Request or CoA-Requests   affe=
cting the sessions of another provider.   A NAS or proxy MUST silently disc=
ard Disconnect-Request or CoA-   Request packets from untrusted sources.  I=
n situations where the   Dynamic Authorization Client is co-resident with a=
 RADIUS   authentication or accounting server, a proxy MAY perform a "rever=
se   path forwarding" (RPF) check to verify that a Disconnect-Request or   =
CoA-Request originates from an authorized Dynamic Authorization   Client.  =
In addition, it SHOULD be possible to explicitly authorize   additional sou=
rces of Disconnect-Request or CoA-Request packets   relating to certain cla=
sses of sessions.  For example, a particular   source can be explicitly aut=
horized to send CoA-Request packets   relating to users within a set of rea=
lms.   To perform the RPF check, the proxy uses the session identification =
  attributes included in Disconnect-Request or CoA-Request packets, in   or=
der to determine the RADIUS server(s) to which an equivalent   Access-Reque=
st could be routed.  If the source address of the   Disconnect-Request or C=
oA-Request is within this set, then the CoA or   Disconnect-Request is forw=
arded; otherwise it MUST be silently   discarded.   Typically the proxy wil=
l extract the realm from the Network Access   Identifier [RFC4282] included=
 within the User-Name Attribute, and   determine the corresponding RADIUS s=
ervers in the proxy routing   tables.  The RADIUS servers for that realm ar=
e then compared against   the source address of the packet.  Where no proxy=
 is present, the RPF   check will need to be performed by the NAS itself.  =
 Since authorization to send a Disconnect-Request or CoA-Request is   deter=
mined based on the source address and the corresponding shared   secret, th=
e NASes or proxies SHOULD configure a different shared   secret for each Dy=
namic Authorization Client.=

--_57282573-2553-4b52-b6e7-3f2fc37bed35_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>

Issue:&nbsp; RPF Check<br>
Submitter name: Bernard Aboba<br>Submitter email address: [email-masked]=
om<br>Date first submitted: May 24, 2007<br>Reference: <br>Document: RFC357=
6bis-06<br>Comment type: Technical<br>Priority: S<br>Section: Various<br>Ra=
tionale/Explanation of issue:<br><br>It has been pointed out that the Dynam=
ic Authorization Client (the entity originating the CoA or Disconnect-Reque=
st) need not be co-resident with a RADIUS authentication or accounting serv=
er.&nbsp;&nbsp; However, Section 6.1 seems to assume that this is the case.=
&nbsp; In cases where the Dynamic Authorization Client is not co-resident w=
ith the RADIUS authentication or authorization server, the RPF check cannot=
 be applied.&nbsp; I would therefore question whether it is appropriate to =
recommend use of the RPF check by default. <br><br>Note that this is not th=
e only place where the distinction between a RADIUS server and a Dynamic Au=
thorization Client needs to be made.&nbsp;&nbsp; <br><br>The proposed resol=
ution is as follows:<br><br>1. Change the term "RADIUS server" to "Dynamic =
Authorization Client" everywhere the term is being used to refer to the ori=
ginator of CoA or Disconnect-Request packets.&nbsp; Use the term "NAS" cons=
istently when referring to the recipient of a CoA or Disconnect-Request pac=
ket. <br><br>2. Add the following terms to the terminology section:<br><br>=
Dynamic Authorization Client (DAC)<br>&nbsp;&nbsp;&nbsp;&nbsp; The entity o=
riginating Change of Authorization (CoA) or Disconnect-<br>&nbsp;&nbsp;&nbs=
p;&nbsp; Requests.&nbsp; While it is possible that the DAC is co-resident w=
ith a<br>&nbsp;&nbsp;&nbsp;&nbsp; RADIUS authentication or accounting serve=
r, this need not<br>&nbsp;&nbsp;&nbsp;&nbsp; necessarily be the case.<br><b=
r>Network Access Server (NAS)<br>&nbsp;&nbsp;&nbsp;&nbsp; The device provid=
ing access to the network.&nbsp; Sometimes also known<br>&nbsp;&nbsp;&nbsp;=
&nbsp; as the Dynamic Authorization Server (DAS) or RADIUS client.<br><br>3=
. Change Section 6.1 to the following, downgrading the RPF check to a MAY a=
nd clarifying that it is only applicable when the RADIUS server and Dynamic=
 Authorization Client are co-resident. <br><pre>6.1.  Authorization Issues<=
br><br>   Where a NAS is shared by multiple providers, it is undesirable fo=
r<br>   one provider to be able to send Disconnect-Request or CoA-Requests<=
br>   affecting the sessions of another provider.<br><br>   A NAS or proxy =
MUST silently discard Disconnect-Request or CoA-<br>   Request packets from=
 untrusted sources.  In situations where the<br>   Dynamic Authorization Cl=
ient is co-resident with a RADIUS<br>   authentication or accounting server=
, a proxy MAY perform a "reverse<br>   path forwarding" (RPF) check to veri=
fy that a Disconnect-Request or<br>   CoA-Request originates from an author=
ized Dynamic Authorization<br>   Client.  In addition, it SHOULD be possibl=
e to explicitly authorize<br>   additional sources of Disconnect-Request or=
 CoA-Request packets<br>   relating to certain classes of sessions.  For ex=
ample, a particular<br>   source can be explicitly authorized to send CoA-R=
equest packets<br>   relating to users within a set of realms.<br><br>   To=
 perform the RPF check, the proxy uses the session identification<br>   att=
ributes included in Disconnect-Request or CoA-Request packets, in<br>   ord=
er to determine the RADIUS server(s) to which an equivalent<br>   Access-Re=
quest could be routed.  If the source address of the<br>   Disconnect-Reque=
st or CoA-Request is within this set, then the CoA or<br>   Disconnect-Requ=
est is forwarded; otherwise it MUST be silently<br>   discarded.<br><br>   =
Typically the proxy will extract the realm from the Network Access<br>   Id=
entifier [RFC4282] included within the User-Name Attribute, and<br>   deter=
mine the corresponding RADIUS servers in the proxy routing<br>   tables.  T=
he RADIUS servers for that realm are then compared against<br>   the source=
 address of the packet.  Where no proxy is present, the RPF<br>   check wil=
l need to be performed by the NAS itself.<br><br>   Since authorization to =
send a Disconnect-Request or CoA-Request is<br>   determined based on the s=
ource address and the corresponding shared<br>   secret, the NASes or proxi=
es SHOULD configure a different shared<br>   secret for each Dynamic Author=
ization Client.<br></pre><br></body>
</html>=

--_57282573-2553-4b52-b6e7-3f2fc37bed35_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 23:19:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Fri, 25 May 2007 16:19:16 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C79F23.1E6AA7A5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> Only if it supports RADIUS accounting, which I believe you stated is
not
> mandatory.

RFC 2866 allows Acct-Session-Id in Access-Request packets.  So a NAS can
still send this attibute even if it doesn't support RADIUS accounting. =20
Sure, but why?  =20
=20
> presumably by letting the RADIUS server grovel through thousands of
> accounting records (if they exist). Of course, knowing the location
and
> format of these records doesn't constitute an "undefined but
incestuous
> relationship".

Not sure why the RADIUS server would need to grovel through accounting
records if the Acct-Session-Id attribute is present in the
Access-Request (as RFC 2866 allows). =20
At some point isn't it want to get rid of that session state?  The
RADIUS server never is notified that the session has ended (accounting
stops (which themselves may be insufficient for tracking user sessions
as opposed to service sessions) only go to the accounting server.

------_=_NextPart_001_01C79F23.1E6AA7A5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3086" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&gt; Only if it supports RADIUS accounting, which I believe you =
stated is=20
not<BR>&gt; mandatory.<BR><BR>RFC 2866 allows Acct-Session-Id in =
Access-Request=20
packets.&nbsp; So a NAS can still send this attibute even if it doesn't =
support=20
RADIUS accounting.&nbsp;<SPAN class=3D983351323-25052007><FONT =
face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D983351323-25052007><FONT face=3DArial =
color=3D#0000ff>Sure, but=20
why?&nbsp;&nbsp;</FONT>&nbsp;</SPAN><BR>&nbsp;<BR>&gt; presumably by =
letting the=20
RADIUS server grovel through thousands of<BR>&gt; accounting records (if =
they=20
exist). Of course, knowing the location and<BR>&gt; format of these =
records=20
doesn't constitute an "undefined but incestuous<BR>&gt;=20
relationship".<BR><BR>Not sure why the RADIUS server would need to =
grovel=20
through accounting records if the Acct-Session-Id attribute is present =
in the=20
Access-Request (as RFC 2866 allows).&nbsp;<SPAN =
class=3D983351323-25052007><FONT=20
face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D983351323-25052007><FONT face=3DArial =
color=3D#0000ff>At some=20
point&nbsp;isn't it want to get rid of that session state?&nbsp; =
The&nbsp;RADIUS=20
server never is notified that the session has ended (accounting=20
stops&nbsp;(which themselves may be insufficient for tracking user =
sessions as=20
opposed to service sessions) only go to the accounting=20
server.</FONT></SPAN><BR></DIV></BODY></HTML>

------_=_NextPart_001_01C79F23.1E6AA7A5--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 22:58:51 +0000
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>, Alan DeKok <[email-masked]>
CC: <[email-masked]>
Subject: RE: Issue 223: Event-Timestamp and Duplicate Detection
Date: Fri, 25 May 2007 15:58:39 -0700

--_0676054e-79f8-4410-a012-a669e6c99223_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> No. If it was prohibited in an Access-Request, Accept, Reject etc... It> =
would have specifically stated that.=20
Here's what RFC 2869 Section 5.19 says:
=20
   The following table provides a guide to which attributes may be found   =
in which kind of packets.  Acct-Input-Gigawords, Acct-Output-   Gigawords, =
Event-Timestamp, and NAS-Port-Id may have 0-1 instances in   an Accounting-=
Request packet.  Connect-Info may have 0+ instances in   an Accounting-Requ=
est packet.  The other attributes added in this   document must not be pres=
ent in an Accounting-Request.Request  Accept  Reject  Challenge   #    Attr=
ibute0-1      0       0       0           70   ARAP-Password [Note 1]0     =
   0-1     0       0-1         71   ARAP-Features0        0-1     0       0=
           72   ARAP-Zone-Access0-1      0       0       0-1         73   A=
RAP-Security0+       0       0       0+          74   ARAP-Security-Data0  =
      0       0-1     0           75   Password-Retry0        0       0    =
   0-1         76   Prompt0-1      0       0       0           77   Connect=
-Info0        0+      0       0           78   Configuration-Token0+       =
0+      0+      0+          79   EAP-Message [Note 1]0-1      0-1     0-1  =
   0-1         80   Message-Authenticator [Note 1]0        0-1     0       =
0-1         84   ARAP-Challenge-Response0        0-1     0       0         =
  85   Acct-Interim-Interval0-1      0       0       0           87   NAS-P=
ort-Id0        0-1     0       0           88   Framed-PoolRequest  Accept =
 Reject  Challenge   #    Attribute
=20
The first paragraph's first three sentences seem to imply that the attribut=
es named can *only* be present in an Acccounting-Request.  Otherwise why wo=
uldn't that paragraph have listed all the packets that these attributes cou=
ld be included in?=

--_0676054e-79f8-4410-a012-a669e6c99223_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&gt; No. If it was prohibited in an Access-Request, Accept, Reject etc... I=
t<BR>&gt; would have specifically stated that. <BR><BR>
Here's what RFC 2869 Section 5.19 says:<BR>
&nbsp;<BR>
&nbsp;&nbsp; The following table provides a guide to which attributes may b=
e found<BR>&nbsp;&nbsp; in which kind of packets.&nbsp; Acct-Input-Gigaword=
s, Acct-Output-<BR>&nbsp;&nbsp; Gigawords, Event-Timestamp, and NAS-Port-Id=
 may have 0-1 instances in<BR>&nbsp;&nbsp; an Accounting-Request packet.&nb=
sp; Connect-Info may have 0+ instances in<BR>&nbsp;&nbsp; an Accounting-Req=
uest packet.&nbsp; The other attributes added in this<BR>&nbsp;&nbsp; docum=
ent must not be present in an Accounting-Request.<BR><BR>Request&nbsp; Acce=
pt&nbsp; Reject&nbsp; Challenge&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; Attribute<B=
R>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 70&nbsp;&nbsp; ARAP-Password [Note 1]<BR>0&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 71&nbsp;&nbsp; ARAP-Features<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 72&nbsp;&nbsp; ARAP=
-Zone-Access<BR>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; 73&nbsp;&nbsp; ARAP-Security<BR>0+&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; 74&nbsp;&nbsp; ARAP-Security-Data<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nb=
sp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 75&nbsp;&=
nbsp; Password-Retry<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 76&nbsp;&nbsp; Prompt<BR>0-1&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 77&nbsp;&nbsp; Connect-Info<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 78&nbsp;&nbsp; Configuration-Token<BR>0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 79&nbsp;&nbsp; EAP-Messa=
ge [Note 1]<BR>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp=
; 0-1&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; 80&nbsp;&nbsp; Message-Authenticator [Note 1]<BR>0&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 84&nbsp=
;&nbsp; ARAP-Challenge-Response<BR>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 85&nbsp;&nbsp; Acc=
t-Interim-Interval<BR>0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 87&nbsp;&nbsp; NAS-Port-Id<BR>0=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp; 0&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 88&nbsp;&nbsp; Framed-Pool<BR>Request&nbsp; Accept&nbs=
p; Reject&nbsp; Challenge&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; Attribute<BR>
&nbsp;<BR>
The first paragraph's first three sentences&nbsp;seem to imply that the att=
ributes named can *only* be present in an Acccounting-Request.&nbsp; Otherw=
ise why wouldn't that paragraph have listed all the packets that these attr=
ibutes could be included in?<BR><BR></body>
</html>=

--_0676054e-79f8-4410-a012-a669e6c99223_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 22:50:42 +0000
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, Alan DeKok <[email-masked]>
CC: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Fri, 25 May 2007 15:50:36 -0700

--_cac1fce4-725a-48d0-80d7-db45e25e26bc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Only if it supports RADIUS accounting, which I believe you stated is not>=
 mandatory.
RFC 2866 allows Acct-Session-Id in Access-Request packets.  So a NAS can st=
ill send this attibute even if it doesn't support RADIUS accounting.=20
=20
> presumably by letting the RADIUS server grovel through thousands of> acco=
unting records (if they exist). Of course, knowing the location and> format=
 of these records doesn't constitute an "undefined but incestuous> relation=
ship".
Not sure why the RADIUS server would need to grovel through accounting reco=
rds if the Acct-Session-Id attribute is present in the Access-Request (as R=
FC 2866 allows). =

--_cac1fce4-725a-48d0-80d7-db45e25e26bc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<BR>&gt; Only if it supports RADIUS accounting, which I believe you stated =
is not<BR>&gt; mandatory.<BR><BR>
RFC 2866 allows Acct-Session-Id in Access-Request packets.&nbsp; So a NAS c=
an still send this attibute even if it doesn't support RADIUS accounting. <=
BR>
&nbsp;<BR>
&gt; presumably by letting the RADIUS server grovel through thousands of<BR=
>&gt; accounting records (if they exist). Of course, knowing the location a=
nd<BR>&gt; format of these records doesn't constitute an "undefined but inc=
estuous<BR>&gt; relationship".<BR><BR>
Not sure why the RADIUS server would need to grovel through accounting reco=
rds if the Acct-Session-Id attribute is present in the Access-Request (as R=
FC 2866 allows). <BR></body>
</html>=

--_cac1fce4-725a-48d0-80d7-db45e25e26bc_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 22:47:10 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>
CC: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Fri, 25 May 2007 15:46:28 -0700

--_acfcda97-eee1-47fb-96b1-3624124bbc8e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> What I'm saying is that the NAS knows what a session is: the user is> con=
nected to it. The NAS has the information that ties authentication> packets=
 to accounting packets: the Acct-Session-Id. The NAS does not> currently sh=
are this information with the authentication server. It> SHOULD make this i=
nformation available to the authentication server.> > Once the Acct-Session=
-Id is available to the authentication server, it> can be used to tie authe=
ntication sessions to accounting sessions in a> better way than what is don=
e right now. It can also be used as a key to> control parameters related to=
 the session... like CoA.
RFC 2866 Section 5.5 already enables Acct-Session-Id to be put in an Access=
-Request:
      An Access-Request packet MAY have an Acct-Session-Id; if it does,    =
  then the NAS MUST use the same Acct-Session-Id in the Accounting-      Re=
quest packets for that session.
=20
If a NAS supports RFC 3576, it would probably be a good idea for it to incl=
ude the Acct-Session-Id in Access-Requests, since that would make it easier=
 for the Dynamic Authorization Client to obtain the Acct-Session-Id in a va=
riety of situations.  As Glen mentioned, Accounting-Server log files may no=
t necessarily be available.=20
=20
However, even if we add text to make this a SHOULD we can't guarantee that =
it will always be available to the Dynamic Authorization Client.  =

--_acfcda97-eee1-47fb-96b1-3624124bbc8e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&gt; What I'm saying is that the NAS knows what a session is: the user is<B=
R>&gt; connected to it. The NAS has the information that ties authenticatio=
n<BR>&gt; packets to accounting packets: the Acct-Session-Id. The NAS does =
not<BR>&gt; currently share this information with the authentication server=
. It<BR>&gt; SHOULD make this information available to the authentication s=
erver.<BR>&gt; <BR>&gt; Once the Acct-Session-Id is available to the authen=
tication server, it<BR>&gt; can be used to tie authentication sessions to a=
ccounting sessions in a<BR>&gt; better way than what is done right now. It =
can also be used as a key to<BR>&gt; control parameters related to the sess=
ion... like CoA.<BR><BR>
RFC 2866 Section 5.5 already enables Acct-Session-Id to be put in an Access=
-Request:<BR>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An Access-Request packet MAY have an Acc=
t-Session-Id; if it does,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; then the NAS MU=
ST use the same Acct-Session-Id in the Accounting-<BR>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Request packets for that session.<BR>
&nbsp;<BR>
If a NAS supports RFC 3576, it would probably be a good idea for it to incl=
ude the Acct-Session-Id in Access-Requests, since that would make it easier=
 for the Dynamic Authorization Client to obtain the Acct-Session-Id in a va=
riety of situations.&nbsp; As Glen mentioned, Accounting-Server log files m=
ay not necessarily be available. <BR>
&nbsp;<BR>
However, even if we add text to make this a SHOULD we can't guarantee that =
it will always be available to the Dynamic Authorization Client.&nbsp; <BR>=
<BR></body>
</html>=

--_acfcda97-eee1-47fb-96b1-3624124bbc8e_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 17:17:03 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC 3576bis and Session State
Date: Fri, 25 May 2007 10:14:37 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Friday, May 25, 2007 8:25 AM:

...

>=20
> So the problem that you see is the need for RADIUS authentication and
> authorization servers that implement RFC 3576 to maintain NAS session
> state? =20
> Is that right?

3578 just brought the situation to a boil: RADIUS was being used
(arguably inappropriately) for lots of other thing that really required
the knowledge of a session; limiting the number of simultaneous sessions
by a single user leaps to mind...

>=20
> What would be wrong with requiring Dynamic RADIUS servers to be
> co-resident with RADIUS Accounting servers?  They're already a
> different beast, as you've explained. =20

The major problems are that a) RADIUS accounting isn't designed for
dynamic session management either, b) you are requiring the
implementation & deployment of accounting even if all it's used for is
session management and last but certainly not least, c) this kind of
stuff belongs in RADIUS, not a kluge.

>=20
> BTW, I've taken the novel action of changing the subject line to more
> accurately reflect where this discussion is going.=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 15:59:22 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>
Subject: RE:  RFC 3576bis and Session State
Date: Fri, 25 May 2007 11:57:08 -0400
Organization: Elbrys Networks, Inc.

Avi Lior writes...

> Accounting Session Id maybe useful in some scenarios and totally useless
> in other scenarios.  This is because it can change frequently.

So, one could use Acct-Session-Id for "single session" sessions, but would
need to use Acct-Multi-Session-Id for "multi-session" sessions?  Is that
right?  BTW, you're right about the confusing and overloaded use of the term
session.  :-)

BTW, changing the subject line, once again.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 15:55:51 +0000
Subject: RE: Issue 223: Event-Timestamp and Duplicate Detection
Date: Fri, 25 May 2007 11:55:16 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

> RFC 2869 Section 5.3, appears to prohibit inclusion of Event-Timestamp

> except in an Accounting-Request:
...
> RFC 2869 Section 5.19 does not include a table row for the=20
> Event-Timestamp attribute, suggesting that Event-Timestamp is=20
> prohibited in Access-Request, Accept, Reject and Challenge packets.

  That sounds good.

No. If it was prohibited in an Access-Request, Accept, Reject etc... It
would have specifically stated that.=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 15:52:37 +0000
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Fri, 25 May 2007 11:51:55 -0400
From: "Avi Lior" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>

David,=20

"OTOH, I don't think we need to get too hung up about the nomenclature
of the attribute.  The fact at the prefix is Acct should not be
sufficient to disqualify its usage as a session identifier for the
authentication server as well as the accounting server.  A session ID is
a session ID."

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.

The problem we are having is that the term Session is really overloaded.
Here is an example taken from WiMAX (similar to PP2 as well)

A user has:

A) - WiMAX session.  Obtained when it performed Network Access
Authentication and Authorization.

B) - One or more IP sessions.  Optionally btained during A.  But also
via MIP etc....

C) - Each IP session may have one or more flows (which are also
sessions).

There maybe accounting generated for A, for each session under B and for
each flow under C.

Accounting-Multi-Session-ID is used to correlate all of these together.
Inclusion of Framed-IP in the accouting records correlate all the IP
sessions.  Inclusion of other attributes help correlate the flows under
C.

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.

Etc......

Accounting Session Id maybe useful in some scenarios and totally useless
in other scenarios.  This is because it can change frequently.

--

to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 15:38:41 +0000
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Fri, 25 May 2007 11:37:56 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Alan,

>  What I'm saying is that the NAS knows what a session is: the user is
connected to it.  The NAS . >  has the information that ties
authentication packets to accounting packets:  the Acct-Session-Id.=20

No.  Class Attribute perhaps but not Acct-Session-Id.  Accounting
Session Id changes all the time. While the Authetnication Session
remains constant.

> The NAS does not currently share this information with the
authentication server.  It SHOULD make > this information available to
the authentication server.

No.  It is useless in cases where you have multiple Starts/Stops and
multiple Accounting sessions.

>  Once the Acct-Session-Id is available to the authentication server,
it can be used to tie=20
>authentication sessions to accounting sessions in a better way than
what is done right now.  It can >also be used as a key to control
parameters related to the session... like CoA.

No. For the reason above. And we have Class attribute to do just that.

Avi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 15:27:22 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RFC 3576bis and Session State
Date: Fri, 25 May 2007 11:24:59 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes..

> I really think it's been painfully obvious for some time (at least 
> since the publication of RFC 3576) that RADIUS servers are no longer
> the nice, stateless things they were presumed to be by RFC 2865...

I certainly agree that RFC 3576 radically changed the RADIUS architecture.

> ...and that RADIUS servers need a way to keep track of user sessions
> _outside_ of accounting.

One can certainly make the argument that implementations of RFC 3576 would
benefit from this feature.

> Since both the RADIUS server and client have to change to
> support your suggestion, it would be really cool if we could actually
> _solve_ that problem here instead of just applying YABA, don't you
> think?

So the problem that you see is the need for RADIUS authentication and
authorization servers that implement RFC 3576 to maintain NAS session state?
Is that right?

What would be wrong with requiring Dynamic RADIUS servers to be co-resident
with RADIUS Accounting servers?  They're already a different beast, as
you've explained.

BTW, I've taken the novel action of changing the subject line to more
accurately reflect where this discussion is going.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 15:27:14 +0000
Subject: RE: new Service-Type
Date: Fri, 25 May 2007 11:26:37 -0400
From: "Avi Lior" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>

=20
David wrote....

"It might be helpful to have a more detailed use case description in the
ID that specified these proposed values of Service-Type."

I agree with that.  A realistic use case is the one where a Streaming
Video server, is authenticating and seeking authorization for a request
made by a user for a Streaming video service.  The user may have already
gotten an IP service.

The Authentication is not (necessarily) coming from the NAS which was
used to authenticate the access (provide the IP service).

Service-Type =3D Video Service  would certainly work here.

But so would NAS-Port-Type =3D Streaming-Video.

This is by no means a corner-case.  I have seen similar cases when
working on Broadcast Multicast services, however, we "solved" the
problem by other means.  BTW the problem that had to be solved is 'how
does the AAA Server know which service the user wants?'.  As I said in
the earlier email there are several ways to solve this problem -- none
of which require a specific Service-Type.

--

to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 14:59:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Fri, 25 May 2007 07:58:20 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Alan DeKok <mailto:[email-masked]> allegedly scribbled on Friday, May
25, 2007 2:03 AM:

> Glen Zorn (gwz) wrote:
>> Making Acct-Session-Id a MUST would ensure Diameter compatibility.
>> User-Name probably needs to be at least a MAY for the same reason.
>>=20
>> There are just a few problems with this idea (in the absence of
>> RADIUS accounting).
>=20
>   The suggestion was to require Acct-Session-Id in Access-Request,
> which would make it useful independent of accounting.=20
>=20
>> So, basically, what you are saying seems to be that
>>=20
>> 1.
>> 	deploying RADIUS accounting is mandatory AND
>=20
>   No.
>=20
>> 2.
>> 	an undefined but incestuous relationship between separate RADIUS
and
>> RADIUS Accounting servers is also mandatory OR
>=20
>   No.
>=20
>> 3.
>> 	the RADIUS and RADIUS Accounting servers must be one and the
same
>=20
>   No.
>=20
>   What I'm saying is that the NAS knows what a session is: the user
> is connected to it.  The NAS has the information that ties
> authentication packets to accounting packets:  the Acct-Session-Id.=20

Only if it supports RADIUS accounting, which I believe you stated is not
mandatory.

> The NAS does not currently share this information with the
> authentication server.  It SHOULD make this information available to
> the authentication server.    =20
>=20
>   Once the Acct-Session-Id is available to the authentication server,
> it can be used to tie authentication sessions=20

which don't exist

> to accounting sessions

which may or may not exist, since accounting support isn't mandatory

> in a better way than what is done right now. =20

presumably by letting the RADIUS server grovel through thousands of
accounting records (if they exist).  Of course, knowing the location and
format of these records doesn't constitute an "undefined but incestuous
relationship".

> It can also be used as
> a key to control parameters related to the session... like CoA.  =20

OK, one simple question: when and how does the RADIUS server (since it's
not necessarily the same as the accounting server & therefore will not
necessarily receive Accounting Stop records) know that the session has
ended and that it can therefore discard that data?=20
=20
>=20
>   Alan DeKok.

I really think it's been painfully obvious for some time (at least since
the publication of RFC 3576) that RADIUS servers are no longer the nice,
stateless things they were presumed to be by RFC 2865 and that RADIUS
servers need a way to keep track of user sessions _outside_ of
accounting.  Since both the RADIUS server and client have to change to
support your suggestion, it would be really cool if we could actually
_solve_ that problem here instead of just applying YABA, don't you
think?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 14:20:41 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Fri, 25 May 2007 10:18:32 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   What I'm saying is that the NAS knows what a session is: the user is
> connected to it.  The NAS has the information that ties authentication
> packets to accounting packets:  the Acct-Session-Id.  The NAS does not
> currently share this information with the authentication server.  It
> SHOULD make this information available to the authentication server.

It is entirely possible that RADIUS client implementations that do not
include RADIUS Accounting may not have implemented the Acct-Session-Id
attribute. They would have no need to.

OTOH, I don't think we need to get too hung up about the nomenclature of the
attribute.  The fact at the prefix is Acct should not be sufficient to
disqualify its usage as a session identifier for the authentication server
as well as the accounting server.  A session ID is a session ID.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 14:15:59 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: new Service-Type
Date: Fri, 25 May 2007 10:13:08 -0400
Organization: Elbrys Networks, Inc.

Avi Lior writes...

> In my opinion Service-Type is really broken when it comes to requesting
> and authorizing services.

Perhaps "broken" is too strong a word.

> First and foremost only one instance of Service-Type is allowed in a
> radius packet.  Therefore a client that is requesting multiple services,
> for example IP service, Voice Service, Video Streaming etc., would have
> to issue multiple requests...

It is true that the design of RADIUS was targeted at provisioning exactly
one service at a time.  It is possible to provision different services, on
different "ports" using multiple access requests, or to change or add
services using CoA requests.  It's also true that there is no generally
accepted notion of sub-sessions (multiple services on a main access
session).  But then RADIUS was originally designed for Terminal Servers.

> I am not objecting to the allocation of Service-Type but I am wondering
> what the utility of using it for the purpose that you state.

It might be helpful to have a more detailed use case description in the ID
that specified these proposed values of Service-Type.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 13:30:49 +0000
Subject: RE: new Service-Type
Date: Fri, 25 May 2007 09:30:06 -0400
From: "Avi Lior" <[email-masked]>
To: "Victor Gamov" <[email-masked]>
Cc: <[email-masked]>

Victor,

I am wondering about whether or not this is the way you would want to do
this.

In my opinion Service-Type is really broken when it comes to requesting
and authorizing services.

First and foremost only one instance of Service-Type is allowed in a
radius packet.  Therefore a client that is requesting multiple services,
for example IP service, Voice Service, Video Streaming etc., would have
to issue multiple requests....clearly not what you want to do.

However, if this was an authentication that comes from the Video
Streaming subsystem, in which case that is the only thing that it would
be requesting authentication for, then a Service-Type of Video etc would
work.  It would not be the only way to achieve that goal. Usually the
Server would have other attributes to key on, or one could use NAS-IP
and NAS-ID or even NAS-Port-Type.

I am not objecting to the allocation of Service-Type but I am wondering
what the utility of using it for the purpose that you state.

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Victor Gamov
Sent: Tuesday, April 10, 2007 4:24 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: new Service-Type

Hi Bernard!

Some times ago I ask about propose new Service-Type values to carry
information about video services.  Now I have I-D which propose such
values. This document placed at
http://so.comsat.ru/IST/draft-vit-radext-videoservicetype-00.txt

Please tell me what else must I do to approve this values by IANA?

Thanks!

--

CU,
Victor Gamov

--

to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 25 May 2007 09:03:37 +0000
Date: Fri, 25 May 2007 11:02:56 +0200
From: Alan DeKok <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Issue 226:  RFC 3576bis and Renumbering

Glen Zorn (gwz) wrote:
> Making Acct-Session-Id a MUST would ensure Diameter compatibility. 
> User-Name probably needs to be at least a MAY for the same reason.  
>  
> There are just a few problems with this idea (in the absence of RADIUS
> accounting).

  The suggestion was to require Acct-Session-Id in Access-Request, which
would make it useful independent of accounting.

> So, basically, what you are saying seems to be that 
> 
> 1.	
> 	deploying RADIUS accounting is mandatory AND

  No.

> 2.	
> 	an undefined but incestuous relationship between separate RADIUS
> and RADIUS Accounting servers is also mandatory OR

  No.

> 3.	
> 	the RADIUS and RADIUS Accounting servers must be one and the
> same

  No.

  What I'm saying is that the NAS knows what a session is: the user is
connected to it.  The NAS has the information that ties authentication
packets to accounting packets:  the Acct-Session-Id.  The NAS does not
currently share this information with the authentication server.  It
SHOULD make this information available to the authentication server.

  Once the Acct-Session-Id is available to the authentication server, it
can be used to tie authentication sessions to accounting sessions in a
better way than what is done right now.  It can also be used as a key to
control parameters related to the session... like CoA.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 24 May 2007 21:04:51 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-radext-rfc3576bis-06.txt 
Date: Thu, 24 May 2007 17:02:34 -0400
Organization: Elbrys Networks, Inc.

In Section 3.5, I find the following inconsistency:

       #     Value
      ---    -----
      
      407    Invalid Attribute Value

vs.

      "Unsupported Attribute Value" is a fatal error sent if a Request
      contains an attribute with an unsupported value.

s/"Unsupported Attribute Value"/"Invalid Attribute Value"/

in the sentence above.  "Invalid Attribute Value" is used in several other
places.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 24 May 2007 19:51:02 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-06.txt 
Date: Thu, 24 May 2007 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: M. Chiba, et al.
	Filename	: draft-ietf-radext-rfc3576bis-06.txt
	Pages		: 34
	Date		: 2007-5-24
	
This document describes a currently deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, allowing
   dynamic changes to a user session, as implemented by network access
   server products.  This includes support for disconnecting users and
   changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-rfc3576bis-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 24 May 2007 00:33:16 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Issue:  Cleanup of Section 3
Date: Wed, 23 May 2007 17:32:59 -0700

--_36f8c6cf-d339-4319-8ee2-29f43acd6f7f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Issue:  Cleanup of Section 2.3, 3
Submitter name: Bernard AbobaSubmitter email address: [email-masked]=
te first submitted: May 23, 2007Reference: Document: RFC3576bis-05Comment t=
ype: TechnicalPriority: SSection: 2Rationale/Explanation of issue:
=20
In looking over Section 2.3 and 3, there is a lot of text in Section 2.3 At=
tributes heading relating to Proxy-State which probably belongs in Section =
3.  There is also a lot of text in a variety of sections that is very simil=
ar to what is in Section 2.3, but is worded slightly differently.=20
=20
The proposed fix is to change the text of Section 2.3 Attributes heading fr=
om:
=20
"Attributes      In Disconnect and CoA-Request packets, all Attributes are =
treated      as mandatory.  A NAS MUST respond to a CoA-Request containing =
one      or more unsupported Attributes or Attribute values with a CoA-NAK;=
      a Disconnect-Request containing one or more unsupported Attributes   =
   or Attribute values MUST be answered with a Disconnect-NAK.  State      =
changes resulting from a CoA-Request MUST be atomic: if the      Request is=
 successful, a CoA-ACK is sent, and all requested      authorization change=
s MUST be made.  If the CoA-Request is      unsuccessful, a CoA-NAK MUST be=
 sent, and the requested      authorization changes MUST NOT be made.  Simi=
larly, a state change      MUST NOT occur as a result of an unsuccessful Di=
sconnect-Request;      here a Disconnect-NAK MUST be sent.      Within this=
 specification attributes may be used for      identification, authorizatio=
n or other purposes.  RADIUS Attribue      specifications created after pub=
lication of this document SHOULD      state whether an Attribute can be inc=
luded in CoA or Disconnect      messages and if so, which messages it may b=
e included in and      whether it serves as an identification or authorizat=
ion attribute.      Even if a NAS implements an attribute for use with RADI=
US      authentication and accounting, it is possible that it will not     =
 support inclusion of that attribute within Disconnect-Request or      CoA-=
Request packets, given the difference in attribute semantics.      This is =
true even for attributes specified as allowable within      Access-Accept p=
ackets (such as those defined within [RFC2865],      [RFC2868], [RFC2869], =
[RFC3162], [RFC3579], [RFC4372], [RFC4675],      [RFC4818] and [RFCFilter])=
.  If unsupported attributes are      included within a Disconnect/CoA-Requ=
est packet, the RADIUS client      will send a Disconnect-NAK/CoA-NAK in re=
sponse, possibly      containing an Error-Cause attribute with value Unsupp=
orted      Attribute (401).      If there are any Proxy-State Attributes in=
 a Disconnect-Request or      CoA-Request received from the server, the for=
warding proxy or NAS      MUST include those Proxy-State Attributes in its =
response to the      server.      A forwarding proxy or NAS MUST NOT modify=
 existing Proxy-State,      State, or Class Attributes present in the packe=
t.  The forwarding      proxy or NAS MUST treat any Proxy-State attributes =
already in the      packet as opaque data.  Its operation MUST NOT depend o=
n the      content of Proxy-State attributes added by previous proxies.  Th=
e      forwarding proxy MUST NOT modify any other Proxy-State Attributes   =
   that were in the packet; it may choose not to forward them, but it      =
MUST NOT change their contents.  If the forwarding proxy omits the      Pro=
xy-State Attributes in the request, it MUST attach them to the      respons=
e before sending it.      When the proxy forwards a Disconnect or CoA-Reque=
st, it MAY add a      Proxy-State Attribute, but it MUST NOT add more than =
one.  If a      Proxy-State Attribute is added to a packet when forwarding =
the      packet, the Proxy-State Attribute MUST be added after any existing=
      Proxy-State attributes.  The forwarding proxy MUST NOT change the    =
  order of any attributes of the same type, including Proxy-State.      Oth=
er Attributes can be placed before, after or even between the      Proxy-St=
ate Attributes.      When the proxy receives a response to a CoA-Request or=
 Disconnect-      Request, it MUST remove its own Proxy-State (the last Pro=
xy- State      in the packet) before forwarding the response.  Since Discon=
nect      and CoA responses are authenticated on the entire packet contents=
,      the stripping of the Proxy-State Attribute invalidates the      inte=
grity check - so the proxy needs to recompute it."
=20
To:
=20
"Attributes      In Disconnect and CoA-Request packets, all Attributes are =
treated      as mandatory.  If one or more authorization changes specified =
in a      CoA-Request cannot be carried out, the NAS MUST send a CoA-NAK.  =
A      NAS MUST respond to a CoA-Request containing one or more      unsupp=
orted Attributes or Attribute values with a CoA-NAK; an      Error-Cause At=
tribute with value 401 (Unsupported Attribute) or      407 (Invalid Attribu=
te Value) MAY be included.  A NAS MUST respond      to a Disconnect-Request=
 containing one or more unsupported      Attributes or Attribute values wit=
h a Disconnect-NAK; an Error-      Cause Attribute with value 401 (Unsuppor=
ted Attribute) or 407      (Invalid Attribute Value) MAY be included.      =
State changes resulting from a CoA-Request MUST be atomic: if the      Requ=
est is successful, a CoA-ACK MUST be sent in reply, and all      requested =
authorization changes MUST be made.  If the CoA-Request      is unsuccessfu=
l, a CoA-NAK MUST be sent in reply, and the      requested authorization ch=
anges MUST NOT be made.  Similarly, a      state change MUST NOT occur as a=
 result of an unsuccessful      Disconnect-Request; a Disconnect-NAK MUST b=
e sent in reply.      Within this specification attributes can be used for =
     identification, authorization or other purposes.  RADIUS Attribute    =
  specifications created after publication of this document SHOULD      sta=
te whether an attribute can be included in CoA or Disconnect      messages =
and if so, which messages it can be included in and      whether it serves =
as an identification or authorization attribute.      Even if a NAS impleme=
nts an attribute for use with RADIUS      authentication and accounting, it=
 is possible that it will not      support inclusion of that attribute with=
in Disconnect-Request or      CoA-Request packets, given the difference in =
attribute semantics.      This is true even for attributes specified as all=
owable within      Access-Accept packets (such as those defined within [RFC=
2865],      [RFC2868], [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675=
],      [RFC4818] and [RFC4849])."
=20
Section 3, 3.1 and 3.2 are changed from:
=20
"3.  Attributes   In Disconnect-Request and CoA-Request packets, certain at=
tributes are   used to uniquely identify the NAS as well as a user session =
on the   NAS.  All NAS identification attributes included in a Request pack=
et   MUST match in order for a Disconnect-Request or CoA-Request to be   su=
ccessful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.   For sessi=
on identification attributes, the User-Name and Acct-   Session-Id Attribut=
es, if included, MUST match in order for a   Disconnect-Request or CoA-Requ=
est to be successful; other session   identification attributes SHOULD matc=
h.  Where a mismatch of session   identification attributes is detected, a =
Disconnect-NAK or CoA-NAK   SHOULD  be sent.   The ability to use NAS or se=
ssion identification attributes to map to   unique/multiple sessions is bey=
ond the scope of this document.   Identification attributes include NAS and=
 session identification   attributes, as described below.     NAS identific=
ation attributes     Attribute             #    Reference  Description     =
---------            ---   ---------  -----------     NAS-IP-Address       =
 4    [RFC2865]  The IPv4 address of the NAS.     NAS-Identifier       32  =
  [RFC2865]  String identifying the NAS.     NAS-IPv6-Address     95    [RF=
C3162]  The IPv6 address of the NAS.     Session identification attributes =
    Attribute              #   Reference  Description     ---------        =
     ---  ---------  -----------     User-Name              1   [RFC2865]  =
The name of the user                                           associated w=
ith the session.     NAS-Port               5   [RFC2865]  The port on whic=
h the                                           session is terminated.     =
Attribute              #   Reference  Description     ---------            =
 ---  ---------  -----------     Called-Station-Id     30   [RFC2865]  The =
link address to which                                           the session=
 is connected.     Calling-Station-Id    31   [RFC2865]  The link address f=
rom which                                           the session is connecte=
d.     Acct-Session-Id       44   [RFC2866]  The identifier uniquely       =
                                    identifying the session                =
                           on the NAS.     Acct-Multi-Session-Id 50   [RFC2=
866]  The identifier uniquely                                           ide=
ntifying related sessions.     NAS-Port-Id           87   [RFC2869]  String=
 identifying the port                                           where the s=
ession is.     Chargeable-User-      89   [RFC4372]  The CUI associated wit=
h the     Identity                              session.  Needed where a   =
                                        privacy NAI is used, because       =
                                    the User-Name may not be               =
                            unique (e.g. "anonymous").   To address securit=
y concerns described in Section 6.1, either the   User-Name or Chargeable-U=
ser-Identity attribute SHOULD be present in   Disconnect-Request and CoA-Re=
quest packets.   Where a Diameter client utilizes the same Session-Id for b=
oth   authorization and accounting, inclusion of an Acct-Session-Id   Attri=
bute in a Disconnect-Request or CoA-Request can assist with   Diameter/RADI=
US translation, since Diameter RAR and ASR commands   include a Session-Id =
AVP.  An Acct-Session-Id attribute SHOULD be   included in Disconnect-Reque=
st and CoA-Request packets.   Where the Acct-Session-Id or Acct-Multi-Sessi=
on-Id attributes are not   present in a CoA-Request or Disconnect-Request, =
it is possible that   the User-Name or Chargeable-User-Identity attributes =
will not be   sufficient to uniquely identify the session (e.g. if the same=
 user   has multiple sessions on the NAS, or the privacy NAI is used).  As =
a   result, the Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-   =
Port-Id attributes MAY be used as additional session identification.   To a=
ddress security concerns described in Section 6.2, one or more of   the NAS=
-IP-Address or NAS-IPv6-Address Attributes SHOULD be present   in Disconnec=
t-Request and CoA-Request packets; the NAS-Identifier   Attribute MAY be pr=
esent.   If one or more authorization changes specified in a CoA-Request   =
cannot be carried out, or if one or more attributes or attribute-   values =
is unsupported, a CoA-NAK MUST be sent.  Similarly, if there   are one or m=
ore unsupported attributes or attribute values in a   Disconnect-Request, a=
 Disconnect-NAK MUST be sent.   A Disconnect-Request MUST contain only NAS =
and session identification   attributes (see Section 3).  If other attribut=
es are included in a   Disconnect-Request, implementations MUST send a Disc=
onnect-NAK; an   Error-Cause Attribute with value "Unsupported Attribute" M=
AY be   included.3.1.  Authorize Only   Support for a CoA-Request including=
 a Service-Type Attribute with   value "Authorize Only" is OPTIONAL on the =
NAS and RADIUS server.  A   Service-Type Attribute MUST NOT be included wit=
hin a Disconnect-   Request.   A NAS MUST respond to a CoA-Request includin=
g a Service-Type   Attribute with value "Authorize Only" with a CoA-NAK; a =
CoA-ACK MUST   NOT be sent.  If the NAS does not support a Service-Type val=
ue of   "Authorize Only" then it MUST respond with a CoA-NAK; an Error-Caus=
e   value of 405 (Unsupported Service) SHOULD be included.   A CoA-Request =
containing a Service-Type Attribute with value   "Authorize Only" MUST in a=
ddition contain only NAS or session   identification attributes, as well as=
 a State Attribute.  If other   attributes are included in such a CoA-Reque=
st, a CoA-NAK MUST be   sent; an Error-Cause Attribute with value 401 (Unsu=
pported Attribute)   SHOULD be included.   If a CoA-Request packet includin=
g a Service-Type value of "Authorize   Only" is successfully processed, the=
 NAS MUST respond with a CoA-NAK   containing a Service-Type Attribute with=
 value "Authorize Only", and   an Error-Cause Attribute with value 507 (Req=
uest Initiated).  The NAS   then MUST send an Access-Request to the RADIUS =
server including a   Service-Type Attribute with value "Authorize Only".  T=
his Access-   Request SHOULD contain the NAS identification attributes from=
 the   CoA-Request, as well as the session identification attributes from  =
 the CoA-Request legal for inclusion in an Access-Request as specified   in=
 [RFC2865], [RFC2868], [RFC2869] and [RFC3162].  As noted in   [RFC2869] Se=
ction 5.19, a Message-Authenticator attribute SHOULD be   included in an Ac=
cess-Request that does not contain a User-Password,   CHAP-Password, ARAP-P=
assword or EAP-Message Attribute.  The RADIUS   server then will respond to=
 the Access-Request with an Access-Accept   to (re-)authorize the session o=
r an Access-Reject to refuse to   (re-)authorize it.3.2.  State   The State=
 Attribute is available to be sent by the RADIUS server to   the NAS in a C=
oA-Request packet and MUST be sent unmodified from the   NAS to the RADIUS =
server in a subsequent ACK or NAK packet.   [RFC2865] Section 5.44 states: =
     An Access-Request MUST contain either a User-Password or a CHAP-      =
Password or State.  An Access-Request MUST NOT contain both a      User-Pas=
sword and a CHAP-Password.  If future extensions allow      other kinds of =
authentication information to be conveyed, the      attribute for that can =
be used in an Access-Request instead of      User-Password or CHAP-Password=
.   In order to satisfy the requirements of [RFC2865] Section 5.44, an   Ac=
cess-Request with Service-Type=3D"Authorize-Only" MUST contain a   State at=
tribute.   In order to provide a State attribute to the NAS, a server sendi=
ng a   CoA-Request with a Service-Type value of "Authorize-Only" MUST   inc=
lude a State Attribute, and the NAS MUST send the State Attribute   unmodif=
ied to the RADIUS server in the resulting Access-Request, if   any.  A NAS =
receiving a CoA-Request containing a Service-Type value   of "Authorize-Onl=
y" but lacking a State attribute MUST send a CoA-NAK   and SHOULD include a=
n Error-Cause attribute with value 402 (Missing   Attribute).   The State A=
ttribute is also available to be sent by the RADIUS server   to the NAS in =
a CoA-Request that also includes a Termination-Action   Attribute with the =
value of RADIUS-Request.  If the client performs   the Termination-Action b=
y sending a new Access-Request upon   termination of the current session, i=
t MUST include the State   Attribute unchanged in that Access-Request.  In =
either usage, the   client MUST NOT interpret the Attribute locally.  A CoA=
-Request   packet must have only zero or one State Attribute.  Usage of the=
   State Attribute is implementation dependent."
=20
=20
To:
=20
"3.  Attributes   In Disconnect-Request and CoA-Request packets, certain at=
tributes are   used to uniquely identify the NAS as well as a user session =
on the   NAS.  All NAS identification attributes included in a Request pack=
et   MUST match in order for a Disconnect-Request or CoA-Request to be   su=
ccessful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.   For sessi=
on identification attributes, the User-Name and Acct-   Session-Id Attribut=
es, if included, MUST match in order for a   Disconnect-Request or CoA-Requ=
est to be successful; other session   identification attributes SHOULD matc=
h.  Where a mismatch of session   identification attributes is detected, a =
Disconnect-NAK or CoA-NAK   SHOULD  be sent.   The ability to use NAS or se=
ssion identification attributes to map to   unique/multiple sessions is bey=
ond the scope of this document.   Identification attributes include NAS and=
 session identification   attributes, as described below.     NAS identific=
ation attributes     Attribute             #    Reference  Description     =
---------            ---   ---------  -----------     NAS-IP-Address       =
 4    [RFC2865]  The IPv4 address of the NAS.     NAS-Identifier       32  =
  [RFC2865]  String identifying the NAS.     NAS-IPv6-Address     95    [RF=
C3162]  The IPv6 address of the NAS.     Session identification attributes =
    Attribute              #   Reference  Description     ---------        =
     ---  ---------  -----------     User-Name              1   [RFC2865]  =
The name of the user                                           associated w=
ith the session.     NAS-Port               5   [RFC2865]  The port on whic=
h the                                           session is terminated.     =
Called-Station-Id     30   [RFC2865]  The link address to which            =
                               the session is connected.     Calling-Statio=
n-Id    31   [RFC2865]  The link address from which                        =
                   the session is connected.     Acct-Session-Id       44  =
 [RFC2866]  The identifier uniquely                                        =
   identifying the session                                           on the=
 NAS.     Acct-Multi-Session-Id 50   [RFC2866]  The identifier uniquely    =
                                       identifying related sessions.     NA=
S-Port-Id           87   [RFC2869]  String identifying the port            =
                               where the session is.     Chargeable-User-  =
    89   [RFC4372]  The CUI associated with the     Identity               =
               session.  Needed where a                                    =
       privacy NAI is used, because                                        =
   the User-Name may not be                                           uniqu=
e (e.g. "anonymous").   To address security concerns described in Section 6=
.1, either the   User-Name or Chargeable-User-Identity attribute SHOULD be =
present in   Disconnect-Request and CoA-Request packets.   Where a Diameter=
 client utilizes the same Session-Id for both   authorization and accountin=
g, inclusion of an Acct-Session-Id   Attribute in a Disconnect-Request or C=
oA-Request can assist with   Diameter/RADIUS translation, since Diameter RA=
R and ASR commands   include a Session-Id AVP.  An Acct-Session-Id attribut=
e SHOULD be   included in Disconnect-Request and CoA-Request packets.   Whe=
re the Acct-Session-Id Attribute is not present in a CoA-Request   or Disco=
nnect-Request, it is possible that the User-Name or   Chargeable-User-Ident=
ity attributes will not be sufficient to   uniquely identify the session (e=
.g. if the same user has multiple   sessions on the NAS, or the privacy NAI=
 is used).  As a result, one   or more of the Acct-Multi-Session-Id, Called=
-Station-Id, Calling-   Station-Id, NAS-Port and NAS-Port-Id attributes MAY=
 be used as   additional session identification.   To address security conc=
erns described in Section 6.2, one or more of   the NAS-IP-Address or NAS-I=
Pv6-Address Attributes SHOULD be present   in Disconnect-Request and CoA-Re=
quest packets; the NAS-Identifier   Attribute MAY be present.   A Disconnec=
t-Request MUST contain only NAS and session identification   attributes.  I=
f other attributes are included in a Disconnect-   Request, implementations=
 MUST send a Disconnect-NAK; an Error-Cause   Attribute with value "Unsuppo=
rted Attribute" MAY be included."
=20
3.1.  Proxy State   If there are any Proxy-State attributes in a Disconnect=
-Request or   CoA-Request received from the server, the forwarding proxy or=
 NAS   MUST include those Proxy-State attributes in its response to the   s=
erver.   A forwarding proxy or NAS MUST NOT modify existing Proxy-State,   =
State, or Class attributes present in the packet.  The forwarding   proxy o=
r NAS MUST treat any Proxy-State attributes already in the   packet as opaq=
ue data.  Its operation MUST NOT depend on the content   of Proxy-State att=
ributes added by previous proxies.  The forwarding   proxy MUST NOT modify =
any other Proxy-State attributes that were in   the packet; it may choose n=
ot to forward them, but it MUST NOT change   their contents.  If the forwar=
ding proxy omits the Proxy-State   attributes in the request, it MUST attac=
h them to the response before   sending it.   When the proxy forwards a Dis=
connect or CoA-Request, it MAY add a   Proxy-State Attribute, but it MUST N=
OT add more than one.  If a   Proxy-State Attribute is added to a packet wh=
en forwarding the   packet, the Proxy-State Attribute MUST be added after a=
ny existing   Proxy-State attributes.  The forwarding proxy MUST NOT change=
 the   order of any attributes of the same type, including Proxy-State.   O=
ther attributes can be placed before, after or even between the   Proxy-Sta=
te attributes.   When the proxy receives a response to a CoA-Request or Dis=
connect-   Request, it MUST remove its own Proxy-State (the last Proxy- Sta=
te in   the packet) Attribute before forwarding the response.  Since   Disc=
onnect and CoA responses are authenticated on the entire packet   contents,=
 the stripping of the Proxy-State Attribute invalidates the   integrity che=
ck - so the proxy needs to recompute it.
=20
3.2.  Authorize Only   Support for a CoA-Request including a Service-Type A=
ttribute with   value "Authorize Only" is OPTIONAL on the NAS and RADIUS se=
rver.  A   Service-Type Attribute MUST NOT be included within a Disconnect-=
   Request.   A NAS MUST respond to a CoA-Request including a Service-Type =
  Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST   NO=
T be sent.  If the NAS does not support a Service-Type value of   "Authoriz=
e Only" then it MUST respond with a CoA-NAK; an Error-Cause   value of 405 =
(Unsupported Service) SHOULD be included.   A CoA-Request containing a Serv=
ice-Type Attribute with value   "Authorize Only" MUST in addition contain o=
nly NAS or session   identification attributes, as well as a State Attribut=
e.  If other   attributes are included in such a CoA-Request, a CoA-NAK MUS=
T be   sent; an Error-Cause Attribute with value 401 (Unsupported Attribute=
)   SHOULD be included.   If a CoA-Request packet including a Service-Type =
value of "Authorize   Only" is successfully processed, the NAS MUST respond=
 with a CoA-NAK   containing a Service-Type Attribute with value "Authorize=
 Only", and   an Error-Cause Attribute with value 507 (Request Initiated). =
 The NAS   then MUST send an Access-Request to the RADIUS server including =
a   Service-Type Attribute with value "Authorize Only".  This Access-   Req=
uest SHOULD contain the NAS identification attributes from the   CoA-Reques=
t, as well as the session identification attributes from   the CoA-Request =
legal for inclusion in an Access-Request as specified   in [RFC2865], [RFC2=
868], [RFC2869] and [RFC3162].  As noted in   [RFC2869] Section 5.19, a Mes=
sage-Authenticator attribute SHOULD be   included in an Access-Request that=
 does not contain a User-Password,   CHAP-Password, ARAP-Password or EAP-Me=
ssage Attribute.  The RADIUS   server then will respond to the Access-Reque=
st with an Access-Accept   to (re-)authorize the session or an Access-Rejec=
t to refuse to   (re-)authorize it.3.3.  State   The State Attribute is ava=
ilable to be sent by the RADIUS server to   the NAS in a CoA-Request packet=
 and MUST be sent unmodified from the   NAS to the RADIUS server in a subse=
quent ACK or NAK packet.   [RFC2865] Section 5.44 states:      An Access-Re=
quest MUST contain either a User-Password or a CHAP-      Password or State=
.  An Access-Request MUST NOT contain both a      User-Password and a CHAP-=
Password.  If future extensions allow     other kinds of authentication inf=
ormation to be conveyed, the      attribute for that can be used in an Acce=
ss-Request instead of      User-Password or CHAP-Password.   In order to sa=
tisfy the requirements of [RFC2865] Section 5.44, an   Access-Request with =
Service-Type=3D"Authorize-Only" MUST contain a   State attribute.   In orde=
r to provide a State attribute to the NAS, a server sending a   CoA-Request=
 with a Service-Type value of "Authorize-Only" MUST   include a State Attri=
bute, and the NAS MUST send the State Attribute   unmodified to the RADIUS =
server in the resulting Access-Request, if   any.  A NAS receiving a CoA-Re=
quest containing a Service-Type value   of "Authorize-Only" but lacking a S=
tate attribute MUST send a CoA-NAK   and SHOULD include an Error-Cause attr=
ibute with value 402 (Missing   Attribute).   The State Attribute is also a=
vailable to be sent by the RADIUS server   to the NAS in a CoA-Request that=
 also includes a Termination-Action   Attribute with the value of RADIUS-Re=
quest.  If the client performs   the Termination-Action by sending a new Ac=
cess-Request upon   termination of the current session, it MUST include the=
 State   Attribute unchanged in that Access-Request.  In either usage, the =
  client MUST NOT interpret the Attribute locally.  A CoA-Request   packet =
must have only zero or one State Attribute.  Usage of the   State Attribute=
 is implementation dependent."=

--_36f8c6cf-d339-4319-8ee2-29f43acd6f7f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Issue:&nbsp; Cleanup of Section 2.3, 3<BR>
Submitter name: Bernard Aboba<BR>Submitter email address: [email-masked]=
om<BR>Date first submitted: May 23, 2007<BR>Reference: <BR>Document: RFC357=
6bis-05<BR>Comment type: Technical<BR>Priority: S<BR>Section: 2<BR>Rational=
e/Explanation of issue:<BR>
&nbsp;<BR>
In looking over Section 2.3 and 3, there is a lot of text&nbsp;in Section 2=
.3&nbsp;Attributes heading&nbsp;relating to Proxy-State which probably belo=
ngs in Section 3.&nbsp; There is also a lot of text in a variety of section=
s that is very similar to what is in Section 2.3, but is worded slightly di=
fferently. <BR>
&nbsp;<BR>
The proposed fix is to change the text of Section 2.3 Attributes heading&nb=
sp;from:<BR>
&nbsp;<BR>
"Attributes<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In Disconnect and CoA-Req=
uest packets, all Attributes are treated<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
as mandatory.&nbsp; A NAS MUST respond to a CoA-Request containing one<BR>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or more unsupported Attributes or Attribute v=
alues with a CoA-NAK;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a Disconnect-Reques=
t containing one or more unsupported Attributes<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; or Attribute values MUST be answered with a Disconnect-NAK.&nbsp; St=
ate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; changes resulting from a CoA-Request =
MUST be atomic: if the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request is success=
ful, a CoA-ACK is sent, and all requested<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 authorization changes MUST be made.&nbsp; If the CoA-Request is<BR>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; unsuccessful, a CoA-NAK MUST be sent, and the reque=
sted<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authorization changes MUST NOT be ma=
de.&nbsp; Similarly, a state change<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST =
NOT occur as a result of an unsuccessful Disconnect-Request;<BR>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; here a Disconnect-NAK MUST be sent.<BR><BR>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; Within this specification attributes may be used for<BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identification, authorization or other purpo=
ses.&nbsp; RADIUS Attribue<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specifications=
 created after publication of this document SHOULD<BR>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; state whether an Attribute can be included in CoA or Disconnect<B=
R>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; messages and if so, which messages it may =
be included in and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; whether it serves as a=
n identification or authorization attribute.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; Even if a NAS implements an attribute for use with RADIUS<BR>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; authentication and accounting, it is possible that=
 it will not<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support inclusion of that at=
tribute within Disconnect-Request or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CoA-=
Request packets, given the difference in attribute semantics.<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; This is true even for attributes specified as allowabl=
e within<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Access-Accept packets (such as t=
hose defined within [RFC2865],<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [RFC2868],=
 [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675],<BR>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; [RFC4818] and [RFCFilter]).&nbsp; If unsupported attributes =
are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; included within a Disconnect/CoA-Requ=
est packet, the RADIUS client<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will send a=
 Disconnect-NAK/CoA-NAK in response, possibly<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; containing an Error-Cause attribute with value Unsupported<BR>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; Attribute (401).<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; If there are any Proxy-State Attributes in a Disconnect-Request or<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; CoA-Request received from the server, the forw=
arding proxy or NAS<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST include those Pr=
oxy-State Attributes in its response to the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; server.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A forwarding proxy or NAS =
MUST NOT modify existing Proxy-State,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sta=
te, or Class Attributes present in the packet.&nbsp; The forwarding<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; proxy or NAS MUST treat any Proxy-State attribut=
es already in the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet as opaque data.&=
nbsp; Its operation MUST NOT depend on the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; content of Proxy-State attributes added by previous proxies.&nbsp; The<BR=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; forwarding proxy MUST NOT modify any other =
Proxy-State Attributes<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that were in the p=
acket; it may choose not to forward them, but it<BR>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; MUST NOT change their contents.&nbsp; If the forwarding proxy omits=
 the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proxy-State Attributes in the reques=
t, it MUST attach them to the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; response be=
fore sending it.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When the proxy forwa=
rds a Disconnect or CoA-Request, it MAY add a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; Proxy-State Attribute, but it MUST NOT add more than one.&nbsp; If a<B=
R>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proxy-State Attribute is added to a packet=
 when forwarding the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet, the Proxy-St=
ate Attribute MUST be added after any existing<BR>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; Proxy-State attributes.&nbsp; The forwarding proxy MUST NOT change th=
e<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; order of any attributes of the same typ=
e, including Proxy-State.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Other Attribute=
s can be placed before, after or even between the<BR>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Proxy-State Attributes.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When=
 the proxy receives a response to a CoA-Request or Disconnect-<BR>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; Request, it MUST remove its own Proxy-State (the last=
 Proxy- State<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the packet) before forwa=
rding the response.&nbsp; Since Disconnect<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; and CoA responses are authenticated on the entire packet contents,<BR>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; the stripping of the Proxy-State Attribute inva=
lidates the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; integrity check - so the prox=
y needs to recompute it."<BR>
&nbsp;<BR>
To:<BR>
&nbsp;<BR>
"Attributes<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In Disconnect and CoA-Req=
uest packets, all Attributes are treated<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
as mandatory.&nbsp; If one or more authorization changes specified in a<BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CoA-Request cannot be carried out, the NAS M=
UST send a CoA-NAK.&nbsp; A<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAS MUST resp=
ond to a CoA-Request containing one or more<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; unsupported Attributes or Attribute values with a CoA-NAK; an<BR>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; Error-Cause Attribute with value 401 (Unsupported A=
ttribute) or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 407 (Invalid Attribute Value=
) MAY be included.&nbsp; A NAS MUST respond<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; to a Disconnect-Request containing one or more unsupported<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; Attributes or Attribute values with a Disconnect-NAK; =
an Error-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cause Attribute with value 401 =
(Unsupported Attribute) or 407<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Invalid A=
ttribute Value) MAY be included.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stat=
e changes resulting from a CoA-Request MUST be atomic: if the<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; Request is successful, a CoA-ACK MUST be sent in reply=
, and all<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requested authorization changes=
 MUST be made.&nbsp; If the CoA-Request<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i=
s unsuccessful, a CoA-NAK MUST be sent in reply, and the<BR>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; requested authorization changes MUST NOT be made.&nbsp; Sim=
ilarly, a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; state change MUST NOT occur as =
a result of an unsuccessful<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Disconnect-Re=
quest; a Disconnect-NAK MUST be sent in reply.<BR><BR>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Within this specification attributes can be used for<BR>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; identification, authorization or other purposes.&nbsp=
; RADIUS Attribute<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specifications created=
 after publication of this document SHOULD<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; state whether an attribute can be included in CoA or Disconnect<BR>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; messages and if so, which messages it can be inclu=
ded in and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; whether it serves as an identi=
fication or authorization attribute.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Even if a NAS implements an attribute for use with RADIUS<BR>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; authentication and accounting, it is possible that it will=
 not<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support inclusion of that attribute =
within Disconnect-Request or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CoA-Request =
packets, given the difference in attribute semantics.<BR>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; This is true even for attributes specified as allowable within=
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Access-Accept packets (such as those def=
ined within [RFC2865],<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [RFC2868], [RFC286=
9], [RFC3162], [RFC3579], [RFC4372], [RFC4675],<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; [RFC4818] and [RFC4849])."<BR>
&nbsp;<BR>
Section 3, 3.1 and 3.2 are changed from:<BR>
&nbsp;<BR>
"3.&nbsp; Attributes<BR><BR>&nbsp;&nbsp; In Disconnect-Request and CoA-Requ=
est packets, certain attributes are<BR>&nbsp;&nbsp; used to uniquely identi=
fy the NAS as well as a user session on the<BR>&nbsp;&nbsp; NAS.&nbsp; All =
NAS identification attributes included in a Request packet<BR>&nbsp;&nbsp; =
MUST match in order for a Disconnect-Request or CoA-Request to be<BR>&nbsp;=
&nbsp; successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.<BR=
>&nbsp;&nbsp; For session identification attributes, the User-Name and Acct=
-<BR>&nbsp;&nbsp; Session-Id Attributes, if included, MUST match in order f=
or a<BR>&nbsp;&nbsp; Disconnect-Request or CoA-Request to be successful; ot=
her session<BR>&nbsp;&nbsp; identification attributes SHOULD match.&nbsp; W=
here a mismatch of session<BR>&nbsp;&nbsp; identification attributes is det=
ected, a Disconnect-NAK or CoA-NAK<BR>&nbsp;&nbsp; SHOULD&nbsp; be sent.<BR=
><BR>&nbsp;&nbsp; The ability to use NAS or session identification attribut=
es to map to<BR>&nbsp;&nbsp; unique/multiple sessions is beyond the scope o=
f this document.<BR>&nbsp;&nbsp; Identification attributes include NAS and =
session identification<BR>&nbsp;&nbsp; attributes, as described below.<BR><=
BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS identification attributes<BR><BR>&nbsp;&nbs=
p;&nbsp;&nbsp; Attribute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; Reference&nbsp; Description<BR>&n=
bsp;&nbsp;&nbsp;&nbsp; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; ---&nbsp;&nbsp; ---------&nbsp; -----------<BR>&nbs=
p;&nbsp;&nbsp;&nbsp; NAS-IP-Address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 4&nbsp;&nbsp;&nbsp; [RFC2865]&nbsp; The IPv4 address of the NAS.<BR>&nbs=
p;&nbsp;&nbsp;&nbsp; NAS-Identifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32&=
nbsp;&nbsp;&nbsp; [RFC2865]&nbsp; String identifying the NAS.<BR>&nbsp;&nbs=
p;&nbsp;&nbsp; NAS-IPv6-Address&nbsp;&nbsp;&nbsp;&nbsp; 95&nbsp;&nbsp;&nbsp=
; [RFC3162]&nbsp; The IPv6 address of the NAS.<BR><BR>&nbsp;&nbsp;&nbsp;&nb=
sp; Session identification attributes<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; Attri=
bute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; #&nbsp;&nbsp; Reference&nbsp; Description<BR>&nbsp;&nbsp;&nbsp;&nbs=
p; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; ---&nbsp; ---------&nbsp; -----------<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
 User-Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 1&nbsp;&nbsp; [RFC2865]&nbsp; The name of the user<BR>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; associated with the session.<BR>&nbsp;&nbsp;&nbsp;&nbs=
p; NAS-Port&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp; [RFC2865]&nbsp; The port on which the<BR=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; session is terminated.<BR><BR>&nbsp;&nbsp;&nbs=
p;&nbsp; Attribute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp; Reference&nbsp; Description<BR>&nbsp;&n=
bsp;&nbsp;&nbsp; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; ---&nbsp; ---------&nbsp; -----------<BR>&nbsp;&nbs=
p;&nbsp;&nbsp; Called-Station-Id&nbsp;&nbsp;&nbsp;&nbsp; 30&nbsp;&nbsp; [RF=
C2865]&nbsp; The link address to which<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the s=
ession is connected.<BR>&nbsp;&nbsp;&nbsp;&nbsp; Calling-Station-Id&nbsp;&n=
bsp;&nbsp; 31&nbsp;&nbsp; [RFC2865]&nbsp; The link address from which<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; the session is connected.<BR>&nbsp;&nbsp;&nbsp;&n=
bsp; Acct-Session-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44&nbsp;&nbsp; [RF=
C2866]&nbsp; The identifier uniquely<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identif=
ying the session<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on the NAS.<BR>&nbsp;&nbsp;=
&nbsp;&nbsp; Acct-Multi-Session-Id 50&nbsp;&nbsp; [RFC2866]&nbsp; The ident=
ifier uniquely<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifying related sessions.=
<BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS-Port-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; 87&nbsp;&nbsp; [RFC2869]&nbsp; String identifying=
 the port<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where the session is.<BR>&nbsp;&nb=
sp;&nbsp;&nbsp; Chargeable-User-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 89&nbsp;&nbs=
p; [RFC4372]&nbsp; The CUI associated with the<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
Identity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session.&nbsp; Needed where a<BR>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; privacy NAI is used, because<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; the User-Name may not be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unique (e.g. "a=
nonymous").<BR><BR>&nbsp;&nbsp; To address security concerns described in S=
ection 6.1, either the<BR>&nbsp;&nbsp; User-Name or Chargeable-User-Identit=
y attribute SHOULD be present in<BR>&nbsp;&nbsp; Disconnect-Request and CoA=
-Request packets.<BR><BR>&nbsp;&nbsp; Where a Diameter client utilizes the =
same Session-Id for both<BR>&nbsp;&nbsp; authorization and accounting, incl=
usion of an Acct-Session-Id<BR>&nbsp;&nbsp; Attribute in a Disconnect-Reque=
st or CoA-Request can assist with<BR>&nbsp;&nbsp; Diameter/RADIUS translati=
on, since Diameter RAR and ASR commands<BR>&nbsp;&nbsp; include a Session-I=
d AVP.&nbsp; An Acct-Session-Id attribute SHOULD be<BR>&nbsp;&nbsp; include=
d in Disconnect-Request and CoA-Request packets.<BR><BR>&nbsp;&nbsp; Where =
the Acct-Session-Id or Acct-Multi-Session-Id attributes are not<BR>&nbsp;&n=
bsp; present in a CoA-Request or Disconnect-Request, it is possible that<BR=
>&nbsp;&nbsp; the User-Name or Chargeable-User-Identity attributes will not=
 be<BR>&nbsp;&nbsp; sufficient to uniquely identify the session (e.g. if th=
e same user<BR>&nbsp;&nbsp; has multiple sessions on the NAS, or the privac=
y NAI is used).&nbsp; As a<BR>&nbsp;&nbsp; result, the Called-Station-Id, C=
alling-Station-Id, NAS-Port and NAS-<BR>&nbsp;&nbsp; Port-Id attributes MAY=
 be used as additional session identification.<BR><BR>&nbsp;&nbsp; To addre=
ss security concerns described in Section 6.2, one or more of<BR>&nbsp;&nbs=
p; the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present<BR>&=
nbsp;&nbsp; in Disconnect-Request and CoA-Request packets; the NAS-Identifi=
er<BR>&nbsp;&nbsp; Attribute MAY be present.<BR><BR>&nbsp;&nbsp; If one or =
more authorization changes specified in a CoA-Request<BR>&nbsp;&nbsp; canno=
t be carried out, or if one or more attributes or attribute-<BR>&nbsp;&nbsp=
; values is unsupported, a CoA-NAK MUST be sent.&nbsp; Similarly, if there<=
BR>&nbsp;&nbsp; are one or more unsupported attributes or attribute values =
in a<BR>&nbsp;&nbsp; Disconnect-Request, a Disconnect-NAK MUST be sent.<BR>=
&nbsp;&nbsp; A Disconnect-Request MUST contain only NAS and session identif=
ication<BR>&nbsp;&nbsp; attributes (see Section 3).&nbsp; If other attribut=
es are included in a<BR>&nbsp;&nbsp; Disconnect-Request, implementations MU=
ST send a Disconnect-NAK; an<BR>&nbsp;&nbsp; Error-Cause Attribute with val=
ue "Unsupported Attribute" MAY be<BR>&nbsp;&nbsp; included.<BR><BR>3.1.&nbs=
p; Authorize Only<BR><BR>&nbsp;&nbsp; Support for a CoA-Request including a=
 Service-Type Attribute with<BR>&nbsp;&nbsp; value "Authorize Only" is OPTI=
ONAL on the NAS and RADIUS server.&nbsp; A<BR>&nbsp;&nbsp; Service-Type Att=
ribute MUST NOT be included within a Disconnect-<BR>&nbsp;&nbsp; Request.<B=
R><BR>&nbsp;&nbsp; A NAS MUST respond to a CoA-Request including a Service-=
Type<BR>&nbsp;&nbsp; Attribute with value "Authorize Only" with a CoA-NAK; =
a CoA-ACK MUST<BR>&nbsp;&nbsp; NOT be sent.&nbsp; If the NAS does not suppo=
rt a Service-Type value of<BR>&nbsp;&nbsp; "Authorize Only" then it MUST re=
spond with a CoA-NAK; an Error-Cause<BR>&nbsp;&nbsp; value of 405 (Unsuppor=
ted Service) SHOULD be included.<BR><BR>&nbsp;&nbsp; A CoA-Request containi=
ng a Service-Type Attribute with value<BR>&nbsp;&nbsp; "Authorize Only" MUS=
T in addition contain only NAS or session<BR>&nbsp;&nbsp; identification at=
tributes, as well as a State Attribute.&nbsp; If other<BR>&nbsp;&nbsp; attr=
ibutes are included in such a CoA-Request, a CoA-NAK MUST be<BR>&nbsp;&nbsp=
; sent; an Error-Cause Attribute with value 401 (Unsupported Attribute)<BR>=
&nbsp;&nbsp; SHOULD be included.<BR><BR>&nbsp;&nbsp; If a CoA-Request packe=
t including a Service-Type value of "Authorize<BR>&nbsp;&nbsp; Only" is suc=
cessfully processed, the NAS MUST respond with a CoA-NAK<BR>&nbsp;&nbsp; co=
ntaining a Service-Type Attribute with value "Authorize Only", and<BR>&nbsp=
;&nbsp; an Error-Cause Attribute with value 507 (Request Initiated).&nbsp; =
The NAS<BR>&nbsp;&nbsp; then MUST send an Access-Request to the RADIUS serv=
er including a<BR>&nbsp;&nbsp; Service-Type Attribute with value "Authorize=
 Only".&nbsp; This Access-<BR>&nbsp;&nbsp; Request SHOULD contain the NAS i=
dentification attributes from the<BR>&nbsp;&nbsp; CoA-Request, as well as t=
he session identification attributes from<BR>&nbsp;&nbsp; the CoA-Request l=
egal for inclusion in an Access-Request as specified<BR>&nbsp;&nbsp; in [RF=
C2865], [RFC2868], [RFC2869] and [RFC3162].&nbsp; As noted in<BR>&nbsp;&nbs=
p; [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be<BR>&=
nbsp;&nbsp; included in an Access-Request that does not contain a User-Pass=
word,<BR>&nbsp;&nbsp; CHAP-Password, ARAP-Password or EAP-Message Attribute=
.&nbsp; The RADIUS<BR>&nbsp;&nbsp; server then will respond to the Access-R=
equest with an Access-Accept<BR>&nbsp;&nbsp; to (re-)authorize the session =
or an Access-Reject to refuse to<BR>&nbsp;&nbsp; (re-)authorize it.<BR><BR>=
3.2.&nbsp; State<BR><BR>&nbsp;&nbsp; The State Attribute is available to be=
 sent by the RADIUS server to<BR>&nbsp;&nbsp; the NAS in a CoA-Request pack=
et and MUST be sent unmodified from the<BR>&nbsp;&nbsp; NAS to the RADIUS s=
erver in a subsequent ACK or NAK packet.<BR>&nbsp;&nbsp; [RFC2865] Section =
5.44 states:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An Access-Request MUST c=
ontain either a User-Password or a CHAP-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Password or State.&nbsp; An Access-Request MUST NOT contain both a<BR>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; User-Password and a CHAP-Password.&nbsp; If futur=
e extensions allow<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other kinds of authent=
ication information to be conveyed, the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a=
ttribute for that can be used in an Access-Request instead of<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; User-Password or CHAP-Password.<BR><BR>&nbsp;&nbsp; In=
 order to satisfy the requirements of [RFC2865] Section 5.44, an<BR>&nbsp;&=
nbsp; Access-Request with Service-Type=3D"Authorize-Only" MUST contain a<BR=
>&nbsp;&nbsp; State attribute.<BR><BR>&nbsp;&nbsp; In order to provide a St=
ate attribute to the NAS, a server sending a<BR>&nbsp;&nbsp; CoA-Request wi=
th a Service-Type value of "Authorize-Only" MUST<BR>&nbsp;&nbsp; include a =
State Attribute, and the NAS MUST send the State Attribute<BR>&nbsp;&nbsp; =
unmodified to the RADIUS server in the resulting Access-Request, if<BR>&nbs=
p;&nbsp; any.&nbsp; A NAS receiving a CoA-Request containing a Service-Type=
 value<BR>&nbsp;&nbsp; of "Authorize-Only" but lacking a State attribute MU=
ST send a CoA-NAK<BR>&nbsp;&nbsp; and SHOULD include an Error-Cause attribu=
te with value 402 (Missing<BR>&nbsp;&nbsp; Attribute).<BR><BR>&nbsp;&nbsp; =
The State Attribute is also available to be sent by the RADIUS server<BR>&n=
bsp;&nbsp; to the NAS in a CoA-Request that also includes a Termination-Act=
ion<BR>&nbsp;&nbsp; Attribute with the value of RADIUS-Request.&nbsp; If th=
e client performs<BR>&nbsp;&nbsp; the Termination-Action by sending a new A=
ccess-Request upon<BR>&nbsp;&nbsp; termination of the current session, it M=
UST include the State<BR>&nbsp;&nbsp; Attribute unchanged in that Access-Re=
quest.&nbsp; In either usage, the<BR>&nbsp;&nbsp; client MUST NOT interpret=
 the Attribute locally.&nbsp; A CoA-Request<BR>&nbsp;&nbsp; packet must hav=
e only zero or one State Attribute.&nbsp; Usage of the<BR>&nbsp;&nbsp; Stat=
e Attribute is implementation dependent."<BR>
&nbsp;<BR>
&nbsp;<BR>
To:<BR>
&nbsp;<BR>
"3.&nbsp; Attributes<BR><BR>&nbsp;&nbsp; In Disconnect-Request and CoA-Requ=
est packets, certain attributes are<BR>&nbsp;&nbsp; used to uniquely identi=
fy the NAS as well as a user session on the<BR>&nbsp;&nbsp; NAS.&nbsp; All =
NAS identification attributes included in a Request packet<BR>&nbsp;&nbsp; =
MUST match in order for a Disconnect-Request or CoA-Request to be<BR>&nbsp;=
&nbsp; successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.<BR=
>&nbsp;&nbsp; For session identification attributes, the User-Name and Acct=
-<BR>&nbsp;&nbsp; Session-Id Attributes, if included, MUST match in order f=
or a<BR>&nbsp;&nbsp; Disconnect-Request or CoA-Request to be successful; ot=
her session<BR>&nbsp;&nbsp; identification attributes SHOULD match.&nbsp; W=
here a mismatch of session<BR>&nbsp;&nbsp; identification attributes is det=
ected, a Disconnect-NAK or CoA-NAK<BR>&nbsp;&nbsp; SHOULD&nbsp; be sent.<BR=
><BR>&nbsp;&nbsp; The ability to use NAS or session identification attribut=
es to map to<BR>&nbsp;&nbsp; unique/multiple sessions is beyond the scope o=
f this document.<BR>&nbsp;&nbsp; Identification attributes include NAS and =
session identification<BR>&nbsp;&nbsp; attributes, as described below.<BR><=
BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS identification attributes<BR><BR>&nbsp;&nbs=
p;&nbsp;&nbsp; Attribute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; Reference&nbsp; Description<BR>&n=
bsp;&nbsp;&nbsp;&nbsp; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; ---&nbsp;&nbsp; ---------&nbsp; -----------<BR>&nbs=
p;&nbsp;&nbsp;&nbsp; NAS-IP-Address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 4&nbsp;&nbsp;&nbsp; [RFC2865]&nbsp; The IPv4 address of the NAS.<BR>&nbs=
p;&nbsp;&nbsp;&nbsp; NAS-Identifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32&=
nbsp;&nbsp;&nbsp; [RFC2865]&nbsp; String identifying the NAS.<BR>&nbsp;&nbs=
p;&nbsp;&nbsp; NAS-IPv6-Address&nbsp;&nbsp;&nbsp;&nbsp; 95&nbsp;&nbsp;&nbsp=
; [RFC3162]&nbsp; The IPv6 address of the NAS.<BR><BR>&nbsp;&nbsp;&nbsp;&nb=
sp; Session identification attributes<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; Attri=
bute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; #&nbsp;&nbsp; Reference&nbsp; Description<BR>&nbsp;&nbsp;&nbsp;&nbs=
p; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; ---&nbsp; ---------&nbsp; -----------<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
 User-Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 1&nbsp;&nbsp; [RFC2865]&nbsp; The name of the user<BR>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; associated with the session.<BR>&nbsp;&nbsp;&nbsp;&nbs=
p; NAS-Port&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp; [RFC2865]&nbsp; The port on which the<BR=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; session is terminated.<BR>&nbsp;&nbsp;&nbsp;&n=
bsp; Called-Station-Id&nbsp;&nbsp;&nbsp;&nbsp; 30&nbsp;&nbsp; [RFC2865]&nbs=
p; The link address to which<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the session is =
connected.<BR>&nbsp;&nbsp;&nbsp;&nbsp; Calling-Station-Id&nbsp;&nbsp;&nbsp;=
 31&nbsp;&nbsp; [RFC2865]&nbsp; The link address from which<BR>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; the session is connected.<BR>&nbsp;&nbsp;&nbsp;&nbsp; Acct-=
Session-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44&nbsp;&nbsp; [RFC2866]&nbs=
p; The identifier uniquely<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifying the s=
ession<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on the NAS.<BR>&nbsp;&nbsp;&nbsp;&nbs=
p; Acct-Multi-Session-Id 50&nbsp;&nbsp; [RFC2866]&nbsp; The identifier uniq=
uely<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifying related sessions.<BR>&nbsp;=
&nbsp;&nbsp;&nbsp; NAS-Port-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; 87&nbsp;&nbsp; [RFC2869]&nbsp; String identifying the port<=
BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where the session is.<BR>&nbsp;&nbsp;&nbsp;&=
nbsp; Chargeable-User-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 89&nbsp;&nbsp; [RFC437=
2]&nbsp; The CUI associated with the<BR>&nbsp;&nbsp;&nbsp;&nbsp; Identity&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; session.&nbsp; Needed where a<BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; privacy NAI is used, because<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Us=
er-Name may not be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unique (e.g. "anonymous")=
.<BR><BR>&nbsp;&nbsp; To address security concerns described in Section 6.1=
, either the<BR>&nbsp;&nbsp; User-Name or Chargeable-User-Identity attribut=
e SHOULD be present in<BR>&nbsp;&nbsp; Disconnect-Request and CoA-Request p=
ackets.<BR><BR>&nbsp;&nbsp; Where a Diameter client utilizes the same Sessi=
on-Id for both<BR>&nbsp;&nbsp; authorization and accounting, inclusion of a=
n Acct-Session-Id<BR>&nbsp;&nbsp; Attribute in a Disconnect-Request or CoA-=
Request can assist with<BR>&nbsp;&nbsp; Diameter/RADIUS translation, since =
Diameter RAR and ASR commands<BR>&nbsp;&nbsp; include a Session-Id AVP.&nbs=
p; An Acct-Session-Id attribute SHOULD be<BR>&nbsp;&nbsp; included in Disco=
nnect-Request and CoA-Request packets.<BR><BR>&nbsp;&nbsp; Where the Acct-S=
ession-Id Attribute is not present in a CoA-Request<BR>&nbsp;&nbsp; or Disc=
onnect-Request, it is possible that the User-Name or<BR>&nbsp;&nbsp; Charge=
able-User-Identity attributes will not be sufficient to<BR>&nbsp;&nbsp; uni=
quely identify the session (e.g. if the same user has multiple<BR>&nbsp;&nb=
sp; sessions on the NAS, or the privacy NAI is used).&nbsp; As a result, on=
e<BR>&nbsp;&nbsp; or more of the Acct-Multi-Session-Id, Called-Station-Id, =
Calling-<BR>&nbsp;&nbsp; Station-Id, NAS-Port and NAS-Port-Id attributes MA=
Y be used as<BR>&nbsp;&nbsp; additional session identification.<BR><BR>&nbs=
p;&nbsp; To address security concerns described in Section 6.2, one or more=
 of<BR>&nbsp;&nbsp; the NAS-IP-Address or NAS-IPv6-Address Attributes SHOUL=
D be present<BR>&nbsp;&nbsp; in Disconnect-Request and CoA-Request packets;=
 the NAS-Identifier<BR>&nbsp;&nbsp; Attribute MAY be present.<BR><BR>&nbsp;=
&nbsp; A Disconnect-Request MUST contain only NAS and session identificatio=
n<BR>&nbsp;&nbsp; attributes.&nbsp; If other attributes are included in a D=
isconnect-<BR>&nbsp;&nbsp; Request, implementations MUST send a Disconnect-=
NAK; an Error-Cause<BR>&nbsp;&nbsp; Attribute with value "Unsupported Attri=
bute" MAY be included."<BR>
&nbsp;<BR>
3.1.&nbsp; Proxy State<BR><BR>&nbsp;&nbsp; If there are any Proxy-State att=
ributes in a Disconnect-Request or<BR>&nbsp;&nbsp; CoA-Request received fro=
m the server, the forwarding proxy or NAS<BR>&nbsp;&nbsp; MUST include thos=
e Proxy-State attributes in its response to the<BR>&nbsp;&nbsp; server.<BR>=
<BR>&nbsp;&nbsp; A forwarding proxy or NAS MUST NOT modify existing Proxy-S=
tate,<BR>&nbsp;&nbsp; State, or Class attributes present in the packet.&nbs=
p; The forwarding<BR>&nbsp;&nbsp; proxy or NAS MUST treat any Proxy-State a=
ttributes already in the<BR>&nbsp;&nbsp; packet as opaque data.&nbsp; Its o=
peration MUST NOT depend on the content<BR>&nbsp;&nbsp; of Proxy-State attr=
ibutes added by previous proxies.&nbsp; The forwarding<BR>&nbsp;&nbsp; prox=
y MUST NOT modify any other Proxy-State attributes that were in<BR>&nbsp;&n=
bsp; the packet; it may choose not to forward them, but it MUST NOT change<=
BR>&nbsp;&nbsp; their contents.&nbsp; If the forwarding proxy omits the Pro=
xy-State<BR>&nbsp;&nbsp; attributes in the request, it MUST attach them to =
the response before<BR>&nbsp;&nbsp; sending it.<BR><BR>&nbsp;&nbsp; When th=
e proxy forwards a Disconnect or CoA-Request, it MAY add a<BR>&nbsp;&nbsp; =
Proxy-State Attribute, but it MUST NOT add more than one.&nbsp; If a<BR>&nb=
sp;&nbsp; Proxy-State Attribute is added to a packet when forwarding the<BR=
>&nbsp;&nbsp; packet, the Proxy-State Attribute MUST be added after any exi=
sting<BR>&nbsp;&nbsp; Proxy-State attributes.&nbsp; The forwarding proxy MU=
ST NOT change the<BR>&nbsp;&nbsp; order of any attributes of the same type,=
 including Proxy-State.<BR>&nbsp;&nbsp; Other attributes can be placed befo=
re, after or even between the<BR>&nbsp;&nbsp; Proxy-State attributes.<BR><B=
R>&nbsp;&nbsp; When the proxy receives a response to a CoA-Request or Disco=
nnect-<BR>&nbsp;&nbsp; Request, it MUST remove its own Proxy-State (the las=
t Proxy- State in<BR>&nbsp;&nbsp; the packet) Attribute before forwarding t=
he response.&nbsp; Since<BR>&nbsp;&nbsp; Disconnect and CoA responses are a=
uthenticated on the entire packet<BR>&nbsp;&nbsp; contents, the stripping o=
f the Proxy-State Attribute invalidates the<BR>&nbsp;&nbsp; integrity check=
 - so the proxy needs to recompute it.<BR>
&nbsp;<BR>
3.2.&nbsp; Authorize Only<BR><BR>&nbsp;&nbsp; Support for a CoA-Request inc=
luding a Service-Type Attribute with<BR>&nbsp;&nbsp; value "Authorize Only"=
 is OPTIONAL on the NAS and RADIUS server.&nbsp; A<BR>&nbsp;&nbsp; Service-=
Type Attribute MUST NOT be included within a Disconnect-<BR>&nbsp;&nbsp; Re=
quest.<BR><BR>&nbsp;&nbsp; A NAS MUST respond to a CoA-Request including a =
Service-Type<BR>&nbsp;&nbsp; Attribute with value "Authorize Only" with a C=
oA-NAK; a CoA-ACK MUST<BR>&nbsp;&nbsp; NOT be sent.&nbsp; If the NAS does n=
ot support a Service-Type value of<BR>&nbsp;&nbsp; "Authorize Only" then it=
 MUST respond with a CoA-NAK; an Error-Cause<BR>&nbsp;&nbsp; value of 405 (=
Unsupported Service) SHOULD be included.<BR><BR>&nbsp;&nbsp; A CoA-Request =
containing a Service-Type Attribute with value<BR>&nbsp;&nbsp; "Authorize O=
nly" MUST in addition contain only NAS or session<BR>&nbsp;&nbsp; identific=
ation attributes, as well as a State Attribute.&nbsp; If other<BR>&nbsp;&nb=
sp; attributes are included in such a CoA-Request, a CoA-NAK MUST be<BR>&nb=
sp;&nbsp; sent; an Error-Cause Attribute with value 401 (Unsupported Attrib=
ute)<BR>&nbsp;&nbsp; SHOULD be included.<BR><BR>&nbsp;&nbsp; If a CoA-Reque=
st packet including a Service-Type value of "Authorize<BR>&nbsp;&nbsp; Only=
" is successfully processed, the NAS MUST respond with a CoA-NAK<BR>&nbsp;&=
nbsp; containing a Service-Type Attribute with value "Authorize Only", and<=
BR>&nbsp;&nbsp; an Error-Cause Attribute with value 507 (Request Initiated)=
.&nbsp; The NAS<BR>&nbsp;&nbsp; then MUST send an Access-Request to the RAD=
IUS server including a<BR>&nbsp;&nbsp; Service-Type Attribute with value "A=
uthorize Only".&nbsp; This Access-<BR>&nbsp;&nbsp; Request SHOULD contain t=
he NAS identification attributes from the<BR>&nbsp;&nbsp; CoA-Request, as w=
ell as the session identification attributes from<BR>&nbsp;&nbsp; the CoA-R=
equest legal for inclusion in an Access-Request as specified<BR>&nbsp;&nbsp=
; in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].&nbsp; As noted in<BR>&n=
bsp;&nbsp; [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD=
 be<BR>&nbsp;&nbsp; included in an Access-Request that does not contain a U=
ser-Password,<BR>&nbsp;&nbsp; CHAP-Password, ARAP-Password or EAP-Message A=
ttribute.&nbsp; The RADIUS<BR>&nbsp;&nbsp; server then will respond to the =
Access-Request with an Access-Accept<BR>&nbsp;&nbsp; to (re-)authorize the =
session or an Access-Reject to refuse to<BR>&nbsp;&nbsp; (re-)authorize it.=
<BR><BR>3.3.&nbsp; State<BR><BR>&nbsp;&nbsp; The State Attribute is availab=
le to be sent by the RADIUS server to<BR>&nbsp;&nbsp; the NAS in a CoA-Requ=
est packet and MUST be sent unmodified from the<BR>&nbsp;&nbsp; NAS to the =
RADIUS server in a subsequent ACK or NAK packet.<BR><BR>&nbsp;&nbsp; [RFC28=
65] Section 5.44 states:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An Access-Re=
quest MUST contain either a User-Password or a CHAP-<BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; Password or State.&nbsp; An Access-Request MUST NOT contain bot=
h a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password and a CHAP-Password.&nb=
sp; If future extensions allow<BR>&nbsp;&nbsp;&nbsp;&nbsp; other kinds of a=
uthentication information to be conveyed, the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; attribute for that can be used in an Access-Request instead of<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; User-Password or CHAP-Password.<BR><BR>&nbsp;&nb=
sp; In order to satisfy the requirements of [RFC2865] Section 5.44, an<BR>&=
nbsp;&nbsp; Access-Request with Service-Type=3D"Authorize-Only" MUST contai=
n a<BR>&nbsp;&nbsp; State attribute.<BR><BR>&nbsp;&nbsp; In order to provid=
e a State attribute to the NAS, a server sending a<BR>&nbsp;&nbsp; CoA-Requ=
est with a Service-Type value of "Authorize-Only" MUST<BR>&nbsp;&nbsp; incl=
ude a State Attribute, and the NAS MUST send the State Attribute<BR>&nbsp;&=
nbsp; unmodified to the RADIUS server in the resulting Access-Request, if<B=
R>&nbsp;&nbsp; any.&nbsp; A NAS receiving a CoA-Request containing a Servic=
e-Type value<BR>&nbsp;&nbsp; of "Authorize-Only" but lacking a State attrib=
ute MUST send a CoA-NAK<BR>&nbsp;&nbsp; and SHOULD include an Error-Cause a=
ttribute with value 402 (Missing<BR>&nbsp;&nbsp; Attribute).<BR><BR>&nbsp;&=
nbsp; The State Attribute is also available to be sent by the RADIUS server=
<BR>&nbsp;&nbsp; to the NAS in a CoA-Request that also includes a Terminati=
on-Action<BR>&nbsp;&nbsp; Attribute with the value of RADIUS-Request.&nbsp;=
 If the client performs<BR>&nbsp;&nbsp; the Termination-Action by sending a=
 new Access-Request upon<BR>&nbsp;&nbsp; termination of the current session=
, it MUST include the State<BR>&nbsp;&nbsp; Attribute unchanged in that Acc=
ess-Request.&nbsp; In either usage, the<BR>&nbsp;&nbsp; client MUST NOT int=
erpret the Attribute locally.&nbsp; A CoA-Request<BR>&nbsp;&nbsp; packet mu=
st have only zero or one State Attribute.&nbsp; Usage of the<BR>&nbsp;&nbsp=
; State Attribute is implementation dependent."<BR></body>
</html>=

--_36f8c6cf-d339-4319-8ee2-29f43acd6f7f_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 24 May 2007 00:22:25 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Re: Issue 227:  Proxy State
Date: Wed, 23 May 2007 17:22:12 -0700

--_f486038a-c510-4004-a71f-d628c9a73d34_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Alan DeKok said:
=20
"> [BA] This suggests that paragraphs 3 and 4 in the text below are not> co=
rrect. Any suggestions on how we can fix it?  Before I do that, it would ap=
pear that my recommendation here isopposite to what RFC 3576 says.  Are we =
OK with changing therecommendation in -bis?  That is, do current implementa=
tions behave as per RFC 3576?  If so, Iwould prefer to maintain inter-opera=
bility.  The text can then be leftas-is.  If not, then the implementations =
do not use Proxy-State, and I wouldprefer to replace the paragraphs with ot=
her text explaining whyProxy-State is not used.  The text in RFC 3576 permi=
ts implementationsto receive Proxy-State, but to not forward it.  Maybe the=
implementations have chosen that method.  My preference is to have one reco=
mmended method of operation, ratherthan 2-3.  I'd like to get clarity on th=
ose questions before submitting suggestedtext."
=20
Some responses from RFC 3576 implementers are enclosed below  Any thoughts =
on how we should proceed?
=20
As an aside, I've pulled all the text relating to Proxy State into a single=
 Section 3.1, so it will be easier to modify:
=20
3.1.  Proxy State   If there are any Proxy-State attributes in a Disconnect=
-Request or   CoA-Request received from the server, the forwarding proxy or=
 NAS   MUST include those Proxy-State attributes in its response to the   s=
erver.   A forwarding proxy or NAS MUST NOT modify existing Proxy-State,   =
State, or Class attributes present in the packet.  The forwarding   proxy o=
r NAS MUST treat any Proxy-State attributes already in the   packet as opaq=
ue data.  Its operation MUST NOT depend on the content   of Proxy-State att=
ributes added by previous proxies.  The forwarding   proxy MUST NOT modify =
any other Proxy-State attributes that were in   the packet; it may choose n=
ot to forward them, but it MUST NOT change   their contents.  If the forwar=
ding proxy omits the Proxy-State   attributes in the request, it MUST attac=
h them to the response before   sending it.   When the proxy forwards a Dis=
connect or CoA-Request, it MAY add a   Proxy-State Attribute, but it MUST N=
OT add more than one.  If a   Proxy-State Attribute is added to a packet wh=
en forwarding the   packet, the Proxy-State Attribute MUST be added after a=
ny existing   Proxy-State attributes.  The forwarding proxy MUST NOT change=
 the   order of any attributes of the same type, including Proxy-State.   O=
ther attributes can be placed before, after or even between the   Proxy-Sta=
te attributes.   When the proxy receives a response to a CoA-Request or Dis=
connect-   Request, it MUST remove its own Proxy-State (the last Proxy- Sta=
te in   the packet) Attribute before forwarding the response.  Since   Disc=
onnect and CoA responses are authenticated on the entire packet   contents,=
 the stripping of the Proxy-State Attribute invalidates the   integrity che=
ck - so the proxy needs to recompute it.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
=20
Date: Wed, 16 May 2007 13:37:41 -0700From: James Blaisdell <[email-masked]=
m>To: Bernard Aboba <[email-masked]>Subject: Re: RFC 3576bis Open Issu=
es
=20
Hello Bernard,
I don't believe either of these items are an issue for us.  It's been a whi=
le, since we implemented RFC-3576 CoA support.  Issue #227 does not affect =
us, as we provide a RADIUS client.  As for issue #226, we're operating at a=
 lower level; we handle the processing of requests, failover, CoA notificat=
ions, building varbinds, other sundry tasks --- the actual message processi=
ng is left up to the application.
=20
fyi - RFC-3576 for some reason doesn't seem to have caught on as quickly as=
 I would have expected.  We had a very difficult time finding a RADIUS serv=
er that supported this capability when we released this feature last year.
At 12:42 PM -0700 5/16/07, Bernard Aboba wrote:>In the IETF RADEXT WG,  we =
have two open issues on RFC 3576bis:>>Issue 226: RFC 3576bis and Renumberin=
g>Issue 227: Proxy State>>Details on the open issues are>available at:>http=
://www.drizzle.com/~aboba/RADEXT/>>In order to resolve these issues, we are=
 seeking answers to the following>questions from implementers of RFC 3576:>=
>a.  Have you implemented Framed-IP-Address or>Framed-IPv6-Prefix/Framed-In=
terface-Id as a Session Identification>attribute (as opposed to a parameter=
 that can be changed in a>CoA-Request)?>b.  Have you implemented the proxy =
state algorithm described below (as>opposed to an alternative approach)?>>A=
ny information you can provide on these issues would be helpful in>enabling=
 the timely completion of the RFC 3576bis effort.>>Current Proxy State text=
 in RFC 3576bis>>     If there are any Proxy-State Attributes in a Disconne=
ct-Request or>     CoA-Request received from the server, the forwarding pro=
xy or NAS>     MUST include those Proxy-State Attributes in its response to=
 the>     server.>>     A forwarding proxy or NAS MUST NOT modify existing =
Proxy-State,>     State, or Class Attributes present in the packet.  The fo=
rwarding>     proxy or NAS MUST treat any Proxy-State attributes already in=
 the>     packet as opaque data.  Its operation MUST NOT depend on the>    =
 content of Proxy-State attributes added by previous proxies.  The>     for=
warding proxy MUST NOT modify any other Proxy-State Attributes>     that we=
re in the packet; it may choose not to forward them, but it>     MUST NOT c=
hange their contents.  If the forwarding proxy omits the>     Proxy-State A=
ttributes in the request, it MUST attach them to the>     response before s=
ending it.>>     When the proxy forwards a Disconnect or CoA-Request, it MA=
Y add a>     Proxy-State Attribute, but it MUST NOT add more than one.  If =
a>     Proxy-State Attribute is added to a packet when forwarding the>     =
packet, the Proxy-State Attribute MUST be added after any existing>     Pro=
xy-State attributes.  The forwarding proxy MUST NOT change the>     order o=
f any attributes of the same type, including Proxy-State.>     Other Attrib=
utes can be placed before, after or even between the>     Proxy-State Attri=
butes.>>     When the proxy receives a response to a CoA-Request or Disconn=
ect->     Request, it MUST remove its own Proxy-State (the last Proxy- Stat=
e>     in the packet) before forwarding the response.  Since Disconnect>   =
  and CoA responses are authenticated on the entire packet contents,>     t=
he stripping of the Proxy-State Attribute invalidates the>     integrity ch=
eck - so the proxy needs to recompute it.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Date: Thu, 17 May 2007 12:54:29 -0400From: Michael Lecuyer <[email-masked]=
>To: Bernard Aboba <[email-masked]>Subject: Re: RFC 3576bis Open Issue=
s
=20
The Proxy-State attribute behaves correctly through the AXL RADIUS Server A=
PI. The authenticators are re-calculated correctly.
The AXL RADIUS Server tracks upstream routing tables based on the source IP=
 address of the Access-Request packet and routed back on any of the followi=
ng attributes: NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address. Downstr=
eam proxy servers may send DM/COA packets if permitted by the AXL server's =
configuration.
=20
So if an Access-Request comes from 192.168.1.1 the routing tables are loade=
d with any existing routing attributes (e.g. NAS-IP-Address). When a DMCOA =
packet is sent either by the AXL server or by a proxy server the AXL routin=
g will send them to the example 192.168.1.1. The upstream routing tables ar=
e many-to-one allowing for different NAS-IP-Address's to be routed back to =
a single origin.
=20
Proxy-State attributes are used in the normal way for reverse/forward DMCOA=
 requests. One is added if there is a request or response for a proxy serve=
r. None are added if the AXL server is the source of the DM/COA request.
=20
The Server uses the originally defined session identifier attributes found =
in RFC 3576:
=20
User-NameNAS-PortFramed-IP-AddressCalled-Station-IdCalling-Station-IdAcct-S=
ession-IdAcct-Multi-Session-IdNAS-Port-TypeNAS-Port-IdOriginating-Line-Info=
Framed-Interface-IdFramed-IPv6-Prefix
=20
There seems to be a fair bit of controversy in the 'Issue 200: RADIUS Respo=
nse and Retransmissions' over these identifiers. It's certainly a good arti=
cle on the vague nature of the original RFC.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Date: Wed, 23 May 2007 13:02:14 -0700From: "Murtaza Chiba (mchiba)" <mchiba=
@cisco.com>To: Bernard Aboba <[email-masked]>Subject: RE: RFC 3576bis =
Open Issues
=20
Hi Bernard,
=20
The answers are the question a) is configurable and b) is not implemented.
=20
Regards,Murtaza=

--_f486038a-c510-4004-a71f-d628c9a73d34_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Alan DeKok said:<BR>
&nbsp;<BR>
"&gt; [BA] This suggests that paragraphs 3 and 4 in the text below are not<=
BR>&gt; correct. Any suggestions on how we can fix it?<BR><BR>&nbsp; Before=
 I do that, it would appear that my recommendation here is<BR>opposite to w=
hat RFC 3576 says.&nbsp; Are we OK with changing the<BR>recommendation in -=
bis?<BR><BR>&nbsp; That is, do current implementations behave as per RFC 35=
76?&nbsp; If so, I<BR>would prefer to maintain inter-operability.&nbsp; The=
 text can then be left<BR>as-is.<BR><BR>&nbsp; If not, then the implementat=
ions do not use Proxy-State, and I would<BR>prefer to replace the paragraph=
s with other text explaining why<BR>Proxy-State is not used.&nbsp; The text=
 in RFC 3576 permits implementations<BR>to receive Proxy-State, but to not =
forward it.&nbsp; Maybe the<BR>implementations have chosen that method.<BR>=
<BR>&nbsp; My preference is to have one recommended method of operation, ra=
ther<BR>than 2-3.<BR><BR>&nbsp; I'd like to get clarity on those questions =
before submitting suggested<BR>text."<BR>
&nbsp;<BR>
Some&nbsp;responses from RFC 3576 implementers are enclosed below&nbsp; Any=
 thoughts on how we should proceed?<BR>
&nbsp;<BR>
As an aside, I've pulled all the text relating to Proxy State into a single=
 Section 3.1, so it will be easier to modify:<BR>
&nbsp;<BR>
3.1.&nbsp; Proxy State<BR><BR>&nbsp;&nbsp; If there are any Proxy-State att=
ributes in a Disconnect-Request or<BR>&nbsp;&nbsp; CoA-Request received fro=
m the server, the forwarding proxy or NAS<BR>&nbsp;&nbsp; MUST include thos=
e Proxy-State attributes in its response to the<BR>&nbsp;&nbsp; server.<BR>=
<BR>&nbsp;&nbsp; A forwarding proxy or NAS MUST NOT modify existing Proxy-S=
tate,<BR>&nbsp;&nbsp; State, or Class attributes present in the packet.&nbs=
p; The forwarding<BR>&nbsp;&nbsp; proxy or NAS MUST treat any Proxy-State a=
ttributes already in the<BR>&nbsp;&nbsp; packet as opaque data.&nbsp; Its o=
peration MUST NOT depend on the content<BR>&nbsp;&nbsp; of Proxy-State attr=
ibutes added by previous proxies.&nbsp; The forwarding<BR>&nbsp;&nbsp; prox=
y MUST NOT modify any other Proxy-State attributes that were in<BR>&nbsp;&n=
bsp; the packet; it may choose not to forward them, but it MUST NOT change<=
BR>&nbsp;&nbsp; their contents.&nbsp; If the forwarding proxy omits the Pro=
xy-State<BR>&nbsp;&nbsp; attributes in the request, it MUST attach them to =
the response before<BR>&nbsp;&nbsp; sending it.<BR><BR>&nbsp;&nbsp; When th=
e proxy forwards a Disconnect or CoA-Request, it MAY add a<BR>&nbsp;&nbsp; =
Proxy-State Attribute, but it MUST NOT add more than one.&nbsp; If a<BR>&nb=
sp;&nbsp; Proxy-State Attribute is added to a packet when forwarding the<BR=
>&nbsp;&nbsp; packet, the Proxy-State Attribute MUST be added after any exi=
sting<BR>&nbsp;&nbsp; Proxy-State attributes.&nbsp; The forwarding proxy MU=
ST NOT change the<BR>&nbsp;&nbsp; order of any attributes of the same type,=
 including Proxy-State.<BR>&nbsp;&nbsp; Other attributes can be placed befo=
re, after or even between the<BR>&nbsp;&nbsp; Proxy-State attributes.<BR><B=
R>&nbsp;&nbsp; When the proxy receives a response to a CoA-Request or Disco=
nnect-<BR>&nbsp;&nbsp; Request, it MUST remove its own Proxy-State (the las=
t Proxy- State in<BR>&nbsp;&nbsp; the packet) Attribute before forwarding t=
he response.&nbsp; Since<BR>&nbsp;&nbsp; Disconnect and CoA responses are a=
uthenticated on the entire packet<BR>&nbsp;&nbsp; contents, the stripping o=
f the Proxy-State Attribute invalidates the<BR>&nbsp;&nbsp; integrity check=
 - so the proxy needs to recompute it.<BR>
&nbsp;<BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<BR>
&nbsp;<BR>
Date: Wed, 16 May 2007 13:37:41 -0700<BR>From: James Blaisdell &lt;<A href=
=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR>To: Bernard Aboba =
&lt;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR>S=
ubject: Re: RFC 3576bis Open Issues<BR>
&nbsp;<BR>
Hello Bernard,<BR>
I don't believe either of these items are an issue for us.&nbsp; It's been =
a while, since we implemented RFC-3576 CoA support.&nbsp; Issue #227 does n=
ot affect us, as we provide a RADIUS client.&nbsp; As for issue #226, we're=
 operating at a lower level; we handle the processing of requests, failover=
, CoA notifications, building varbinds, other sundry tasks --- the actual m=
essage processing is left up to the application.<BR>
&nbsp;<BR>
fyi - RFC-3576 for some reason doesn't seem to have caught on as quickly as=
 I would have expected.&nbsp; We had a very difficult time finding a RADIUS=
 server that supported this capability when we released this feature last y=
ear.<BR>
<BR>At 12:42 PM -0700 5/16/07, Bernard Aboba wrote:<BR>&gt;In the IETF RADE=
XT WG,&nbsp; we have two open issues on RFC 3576bis:<BR>&gt;<BR>&gt;Issue 2=
26: RFC 3576bis and Renumbering<BR>&gt;Issue 227: Proxy State<BR>&gt;<BR>&g=
t;Details on the open issues are<BR>&gt;available at:<BR>&gt;http://www.dri=
zzle.com/~aboba/RADEXT/<BR>&gt;<BR>&gt;In order to resolve these issues, we=
 are seeking answers to the following<BR>&gt;questions from implementers of=
 RFC 3576:<BR>&gt;<BR>&gt;a.&nbsp; Have you implemented Framed-IP-Address o=
r<BR>&gt;Framed-IPv6-Prefix/Framed-Interface-Id as a Session Identification=
<BR>&gt;attribute (as opposed to a parameter that can be changed in a<BR>&g=
t;CoA-Request)?<BR>&gt;b.&nbsp; Have you implemented the proxy state algori=
thm described below (as<BR>&gt;opposed to an alternative approach)?<BR>&gt;=
<BR>&gt;Any information you can provide on these issues would be helpful in=
<BR>&gt;enabling the timely completion of the RFC 3576bis effort.<BR>&gt;<B=
R>&gt;Current Proxy State text in RFC 3576bis<BR>&gt;<BR>&gt;&nbsp;&nbsp;&n=
bsp;&nbsp; If there are any Proxy-State Attributes in a Disconnect-Request =
or<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; CoA-Request received from the server, th=
e forwarding proxy or NAS<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; MUST include thos=
e Proxy-State Attributes in its response to the<BR>&gt;&nbsp;&nbsp;&nbsp;&n=
bsp; server.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; A forwarding proxy or =
NAS MUST NOT modify existing Proxy-State,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; S=
tate, or Class Attributes present in the packet.&nbsp; The forwarding<BR>&g=
t;&nbsp;&nbsp;&nbsp;&nbsp; proxy or NAS MUST treat any Proxy-State attribut=
es already in the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; packet as opaque data.&nb=
sp; Its operation MUST NOT depend on the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; co=
ntent of Proxy-State attributes added by previous proxies.&nbsp; The<BR>&gt=
;&nbsp;&nbsp;&nbsp;&nbsp; forwarding proxy MUST NOT modify any other Proxy-=
State Attributes<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that were in the packet; i=
t may choose not to forward them, but it<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; MU=
ST NOT change their contents.&nbsp; If the forwarding proxy omits the<BR>&g=
t;&nbsp;&nbsp;&nbsp;&nbsp; Proxy-State Attributes in the request, it MUST a=
ttach them to the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; response before sending i=
t.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; When the proxy forwards a Discon=
nect or CoA-Request, it MAY add a<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Proxy-Sta=
te Attribute, but it MUST NOT add more than one.&nbsp; If a<BR>&gt;&nbsp;&n=
bsp;&nbsp;&nbsp; Proxy-State Attribute is added to a packet when forwarding=
 the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; packet, the Proxy-State Attribute MUST=
 be added after any existing<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Proxy-State at=
tributes.&nbsp; The forwarding proxy MUST NOT change the<BR>&gt;&nbsp;&nbsp=
;&nbsp;&nbsp; order of any attributes of the same type, including Proxy-Sta=
te.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Other Attributes can be placed before, =
after or even between the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Proxy-State Attri=
butes.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; When the proxy receives a re=
sponse to a CoA-Request or Disconnect-<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Requ=
est, it MUST remove its own Proxy-State (the last Proxy- State<BR>&gt;&nbsp=
;&nbsp;&nbsp;&nbsp; in the packet) before forwarding the response.&nbsp; Si=
nce Disconnect<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; and CoA responses are authen=
ticated on the entire packet contents,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; the =
stripping of the Proxy-State Attribute invalidates the<BR>&gt;&nbsp;&nbsp;&=
nbsp;&nbsp; integrity check - so the proxy needs to recompute it.<BR><BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<BR>
Date: Thu, 17 May 2007 12:54:29 -0400<BR>From: Michael Lecuyer &lt;<A href=
=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR>To: Bernard Aboba &l=
t;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR>Sub=
ject: Re: RFC 3576bis Open Issues<BR>
&nbsp;<BR>
The Proxy-State attribute behaves correctly through the AXL RADIUS Server A=
PI. The authenticators are re-calculated correctly.<BR>
The AXL RADIUS Server tracks upstream routing tables based on the source IP=
 address of the Access-Request packet and routed back on any of the followi=
ng attributes: NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address. Downstr=
eam proxy servers may send DM/COA packets if permitted by the AXL server's =
configuration.<BR>
&nbsp;<BR>
So if an Access-Request comes from 192.168.1.1 the routing tables are loade=
d with any existing routing attributes (e.g. NAS-IP-Address). When a DMCOA =
packet is sent either by the AXL server or by a proxy server the&nbsp;AXL r=
outing will send them to the example 192.168.1.1. The upstream routing tabl=
es are many-to-one allowing for different NAS-IP-Address's to be routed bac=
k to a single origin.<BR>
&nbsp;<BR>
Proxy-State attributes are used in the normal way for reverse/forward DMCOA=
 requests. One is added if there is a request or response for a proxy serve=
r. None are added if the AXL server is the source of the DM/COA request.<BR=
>
&nbsp;<BR>
The Server uses the originally defined session identifier attributes found =
in RFC 3576:<BR>
&nbsp;<BR>
User-Name<BR>NAS-Port<BR>Framed-IP-Address<BR>Called-Station-Id<BR>Calling-=
Station-Id<BR>Acct-Session-Id<BR>Acct-Multi-Session-Id<BR>NAS-Port-Type<BR>=
NAS-Port-Id<BR>Originating-Line-Info<BR>Framed-Interface-Id<BR>Framed-IPv6-=
Prefix<BR>
&nbsp;<BR>
There seems to be a fair bit of controversy in the 'Issue 200: RADIUS Respo=
nse and Retransmissions' over these identifiers. It's certainly a good arti=
cle on the vague nature of the original RFC.<BR>
&nbsp;<BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<BR>
Date: Wed, 23 May 2007 13:02:14 -0700<BR>From: "Murtaza Chiba (mchiba)" &lt=
;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR>To: Bernar=
d Aboba &lt;<A href=3D"mailto:[email-masked]">[email-masked]</A>&=
gt;<BR>Subject: RE: RFC 3576bis Open Issues<BR>
&nbsp;<BR>
Hi Bernard,<BR>
&nbsp;<BR>
The answers are the question a) is configurable and b) is not implemented.<=
BR>
&nbsp;<BR>
Regards,<BR>Murtaza<BR><BR><BR><BR></body>
</html>=

--_f486038a-c510-4004-a71f-d628c9a73d34_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 24 May 2007 00:11:37 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue:  Error-Cause Attribute in Disconnect-ACK?
Date: Wed, 23 May 2007 17:11:28 -0700

--_116ae3dd-96c1-4f59-805d-380fbdf1233d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In going over the Error-Cause Attribute values, I noticed that there was no=
 value for "Invalid Attribute Value" even though such an error is mentioned=
 in the text.  Here is a revised version of Sections 3.5, 4 and 5 taking th=
at into account.=20
=20
3.5.  Error-Cause   Description      It is possible that the NAS cannot hon=
or Disconnect-Request or      CoA-Request packets for some reason.  The Err=
or-Cause Attribute      provides more detail on the cause of the problem.  =
It MAY be      included within Disconnect-NAK and CoA-NAK packets.      A s=
ummary of the Error-Cause Attribute format is shown below.  The      fields=
 are transmitted from left to right.       0                   1           =
        2                   3       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9=
 0 1 2 3 4 5 6 7 8 9 0 1      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+      |     Type      |    Length     |             Val=
ue      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =
               Value (cont)         |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+   Type      101 for Error-Cause   Length      6   Value      The Value fi=
eld is four octets, containing an integer specifying      the cause of the =
error. Values 0-199 and 300-399 are reserved.      Values 200-299 represent=
 successful completion, so that these      values may only be sent within D=
isconnect-ACK or CoA-ACK packets      and MUST NOT be sent within a Disconn=
ect-NAK or CoA-NAK.  Values      400-499 represent fatal errors committed b=
y the RADIUS server, so      that they MAY be sent within CoA-NAK or Discon=
nect-NAK packets,      and MUST NOT be sent within CoA-ACK or Disconnect-AC=
K packets.      Values 500-599 represent fatal errors occurring on a NAS or=
 RADIUS      proxy, so that they MAY be sent within CoA-NAK and Disconnect-=
NAK      packets, and MUST NOT be sent within CoA-ACK or Disconnect-ACK    =
  packets.  Error-Cause values SHOULD be logged by the RADIUS      server. =
 Error-Code values (expressed in decimal) include:       #     Value      -=
--    -----      201    Residual Session Context Removed      202    Invali=
d EAP Packet (Ignored)      401    Unsupported Attribute      402    Missin=
g Attribute      403    NAS Identification Mismatch      404    Invalid Req=
uest      405    Unsupported Service      406    Unsupported Extension     =
 407    Invalid Attribute Value      501    Administratively Prohibited    =
  502    Request Not Routable (Proxy)      503    Session Context Not Found=
      504    Session Context Not Removable      505    Other Proxy Processi=
ng Error      506    Resources Unavailable      507    Request Initiated   =
   "Residual Session Context Removed" is sent in response to a      Disconn=
ect-Request if the user session is no longer active, but      residual sess=
ion context was found and successfully removed.  This      value is only se=
nt within a Disconnect-ACK and MUST NOT be sent      within a CoA-ACK, Disc=
onnect-NAK or CoA-NAK.      "Invalid EAP Packet (Ignored)" is a non-fatal e=
rror that MUST NOT      be sent by implementations of this specification.  =
    "Unsupported Attribute" is a fatal error sent if a Request      contain=
s an attribute (such as a Vendor-Specific or EAP-Message      Attribute) th=
at is not supported.      "Missing Attribute" is a fatal error sent if crit=
ical attributes      (such as NAS or session identification attributes) are=
 missing      from a Request.      "NAS Identification Mismatch" is a fatal=
 error sent if one or more      NAS identification attributes (see Section =
3) do not match the      identity of the NAS receiving the Request.      "I=
nvalid Request" is a fatal error sent if some other aspect of      the Requ=
est is invalid, such as if one or more attributes (such as      EAP- Messag=
e Attribute(s)) are not formatted properly.      "Unsupported Service" is a=
 fatal error sent if a Service-Type      Attribute included with the Reques=
t is sent with an invalid or      unsupported value.  This error cannot be =
sent in response to a      Disconnect-Request.      "Unsupported Extension"=
 is a fatal error sent due to lack of      support for an extension such as=
 Disconnect and/or CoA packets.      This will typically be sent by a proxy=
 receiving an ICMP port      unreachable message after attempting to forwar=
d a Request to the      NAS.      "Unsupported Attribute Value" is a fatal =
error sent if a Request      contains an attribute with an unsupported valu=
e.      "Administratively Prohibited" is a fatal error sent if the NAS is  =
    configured to prohibit honoring of Request packets for the      specifi=
ed session.      "Request Not Routable" is a fatal error which MAY be sent =
by a      RADIUS proxy and MUST NOT be sent by a NAS.  It indicates that th=
e      RADIUS proxy was unable to determine how to route the Request to    =
  the NAS.  For example, this can occur if the required entries are      no=
t present in the proxy's realm routing table.      "Session Context Not Fou=
nd" is a fatal error sent if the session      context identified in the Req=
uest does not exist on the NAS.      "Session Context Not Removable" is a f=
atal error sent in response      to a Disconnect-Request if the NAS was abl=
e to locate the session      context, but could not remove it for some reas=
on.  It MUST NOT be      sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, =
only within a      Disconnect-NAK.      "Other Proxy Processing Error" is a=
 fatal error sent in response      to a Request that could not be processed=
 by a proxy, for reasons      other than routing.      "Resources Unavailab=
le" is a fatal error sent when a Request could      not be honored due to l=
ack of available NAS resources (memory,      non- volatile storage, etc.). =
     "Request Initiated" is a fatal error sent in response to a CoA-      R=
equest including a Service-Type Attribute with a value of      "Authorize O=
nly".  It indicates that the CoA-Request has not been      honored, but tha=
t a RADIUS Access-Request including a Service-Type      Attribute with valu=
e "Authorize Only" is being sent to the RADIUS      server.4.  Diameter Con=
siderations   Due to differences in handling change-of-authorization reques=
ts in   RADIUS and Diameter, it may be difficult or impossible for a   Diam=
eter/RADIUS gateway to successfully translate a Diameter Re-Auth-   Request=
 (RAR) to a CoA-Request and vice versa.  For example, since a   CoA-Request=
 only initiates an authorization change but does not   initiate re-authenti=
cation, a RAR command containing a Re-Auth-   Request-Type AVP with value "=
AUTHORIZE_AUTHENTICATE" cannot be   directly translated to a CoA-Request.  =
A Diameter/RADIUS gateway   receiving a CoA-Request containing authorizatio=
n changes will need to   translate this into two Diameter exchange.  First,=
 the   Diameter/RADIUS gateway will issue a RAR command including a Session=
-   Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".   Th=
en the Diameter/RADIUS gateway will respond to the ensuing access   request=
 with a response including the authorization attributes   gleaned from the =
CoA-Request.  For the translation to be possible,   the CoA-Request MUST in=
clude a Acct-Session-Id Attribute.  If the   Diameter client uses the same =
Session-Id for both authorization and   accounting, then the Diameter/RADIU=
S gateway can copy the contents of   the Acct-Session-Id Attribute into the=
 Session-Id AVP;  otherwise, it   will need to map the Acct-Session-Id valu=
e to an equivalent Session-   Id for use within a RAR command.   To simplif=
y translation between RADIUS and Diameter, a server   compliant with this s=
pecification MAY include a Service-Type   Attribute with value "Authorize O=
nly" within a CoA-Request.  Such a   CoA-Request MUST contain a State Attri=
bute.  A NAS supporting the   "Authorize Only" Service-Type within a CoA-Re=
quest responds with a   CoA-NAK containing a Service-Type Attribute with va=
lue "Authorize   Only", and an Error-Cause Attribute with value "Request In=
itiated".   The NAS will then send an Access-Request containing a Service-T=
ype   Attribute with a value of "Authorize Only", along with a State   Attr=
ibute.  A Diameter/RADIUS gateway receiving a CoA-Request   containing a Se=
rvice-Type with value "Authorize Only" translates this   to a RAR with Re-A=
uth-Request-Type AVP with value "AUTHORIZE ONLY".   The received RAA is the=
n translated to a CoA-NAK with a Service-Type   value of "Authorize Only". =
  If the Result-Code AVP in the RAA has a   value in the success category, =
then an Error-Cause Attribute with   value "Request Initiated" is included =
in the CoA-NAK.   If the   Result-Code AVP in the RAA has a value indicatin=
g a Protocol Error or   a Transient or Permanent Failure, then an alternate=
 Error-Cause   Attribute is returned as suggested below.   Within Diameter,=
 a server can request that a session be aborted by   sending an Abort-Sessi=
on-Request (ASR), identifying the session to be   terminated using Session-=
ID and User-Name AVPs.  The ASR command is   translated to a Disconnect-Req=
uest containing an Acct-Session-Id and   User-Name attribute.  If the Diame=
ter client utilizes the same   Session-Id in both authorization and account=
ing, then the value of   the Session-ID AVP may be placed in the Acct-Sessi=
on-Id attribute;   otherwise the value of the Session-ID AVP will need to b=
e mapped to   an appropriate Acct-Session-Id value.   For a Disconnect-Requ=
est to   be translatable to an ASR, an Acct-Session-Id attribute MUST be   =
present.  If the Diameter client utilizes the same Session-Id in both   aut=
horization and accounting, then the value of the Acct-Session-Id   may be p=
laced into the Session-ID AVP within the ASR;  otherwise the   value of the=
 Acct-Session-Id will need to be mapped to an appropriate   Session-ID valu=
e.   An Abort-Session-Answer (ASA) command is sent in response to an ASR   =
in order to indicate the disposition of the request.  A   Diameter/RADIUS g=
ateway receiving a Disconnect-ACK translates this to   an ASA command with =
a Result-Code AVP of "DIAMETER_SUCCESS".  A   Disconnect-NAK received from =
the server is translated to an ASA   command with a Result-Code AVP which d=
epends on the value of the   Error-Cause Attribute.  Suggested translations=
 between Error-Cause   Attribute values and Result-Code AVP values are incl=
uded below:    #    Error-Cause Attribute Value   Result-Code AVP   ---   -=
--------------------------  ------------------------   201   Residual Sessi=
on Context     DIAMETER_SUCCESS         Removed   202   Invalid EAP Packet =
          DIAMETER_LIMITED_SUCCESS         (Ignored)   401   Unsupported At=
tribute        DIAMETER_AVP_UNSUPPORTED   402   Missing Attribute          =
  DIAMETER_MISSING_AVP   403   NAS Identification           DIAMETER_REALM_=
NOT_SERVED         Mismatch   404   Invalid Request              DIAMETER_U=
NABLE_TO_COMPLY   405   Unsupported Service          DIAMETER_COMMAND_UNSUP=
PORTED   406   Unsupported Extension        DIAMETER_APPLICATION_UNSUPPORTE=
D   407   Invalid Attribute Value      DIAMETER_INVALID_AVP_VALUE   501   A=
dministratively             DIAMETER_AUTHORIZATION_REJECTED         Prohibi=
ted   502   Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER   503  =
 Session Context Not Found    DIAMETER_UNKNOWN_SESSION_ID   504   Session C=
ontext Not          DIAMETER_AUTHORIZATION_REJECTED         Removable   505=
   Other Proxy Processing       DIAMETER_UNABLE_TO_COMPLY         Error   5=
06   Resources Unavailable        DIAMETER_RESOURCES_EXCEEDED   507   Reque=
st Initiated            DIAMETER_SUCCESS   Since both the ASR/ASA and Disco=
nnect-Request/Disconnect-   NAK/Disconnect-ACK exchanges involve just a req=
uest and response,   inclusion of an "Authorize Only" Service-Type within a=
 Disconnect-   Request is not needed to assist in Diameter/RADIUS translati=
on, and   may make translation more difficult.  As a result, the Service-Ty=
pe   Attribute MUST NOT be used within a Disconnect-Request.5.  IANA Consid=
erations   This document uses the RADIUS [RFC2865] namespace, see   <http:/=
/www.iana.org/assignments/radius-types>.  In addition to the   allocations =
already made in [RFC3576], this specification requests   allocation of an a=
dditional value of the Error-Cause Attribute (101):    #    Value   ---   -=
----   407   Invalid Attribute Value

From: [email-masked]: [email-masked]: RE: Issue=
: Error-Cause Attribute in Disconnect-ACK?Date: Tue, 22 May 2007 12:57:11 -=
0700

I also noticed another oddity in usage of the Error-Cause Attribute.  It is=
 stated that a CoA-NAK MUST always be sent in response to a CoA-Request inc=
luding a Service-Type Attribute with value "Authorize Only".  If the CoA-Re=
quest can be processed, then sending an Error-Cause Attribute with value 50=
7 (Request Initiated) is required.  However, if the CoA-Request cannot be p=
rocessed, sending an Error-Cause attribute is optional.  Given that NAS imp=
lementations supporting a Service-Type attribute with value "Authorize Only=
" have to be able to send the Error-Cause Attribute in the event that the R=
equest can be processed, why isn't sending an Error-Cause attribute a SHOUL=
D in the event of an error?   > From: [email-masked]> To: radius=
[email-masked]> Subject: Issue: Error-Cause Attribute in Disconnect-ACK?>=
 Date: Tue, 22 May 2007 10:31:40 -0700> > > Issue: Error-Cause Attribute in=
 Disconnect-ACK?> Submitter name: Bernard Aboba> Submitter email address: a=
[email-masked]> Date first submitted: May 22, 2007> Reference: > Docume=
nt: RFC3576bis-05> Comment type: Technical> Priority: S> Section: 3.4> Rati=
onale/Explanation of issue:> > In the process of editing the attribute tabl=
e to address Issue 226, I noticed an oddity. > > RFC 3576 Section 3.1 state=
s the following:> > It is possible that the NAS cannot honor Disconnect-Req=
uest or> CoA-Request messages for some reason. The Error-Cause Attribute> p=
rovides more detail on the cause of the problem. It MAY be> included within=
 Disconnect-ACK, Disconnect-NAK and CoA-NAK> messages.> > Why would an Erro=
r-Cause Attribute be included in a Disconnect-ACK? It is not allowed in a C=
oA-ACK, for example. > --> to unsubscribe send a message to radiusext-reque=
[email-masked] with> the word 'unsubscribe' in a single line as the messag=
e text body.> archive: <http://psg.com/lists/radiusext/>=

--_116ae3dd-96c1-4f59-805d-380fbdf1233d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
In going over the Error-Cause Attribute values, I noticed that there was no=
 value for "Invalid Attribute Value" even though such an error is mentioned=
 in the text.&nbsp; Here is a revised version of Sections 3.5, 4 and 5 taki=
ng that into account. <BR>
&nbsp;<BR>
3.5.&nbsp; Error-Cause<BR><BR>&nbsp;&nbsp; Description<BR><BR>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; It is possible that the NAS cannot honor Disconnect-Reque=
st or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CoA-Request packets for some reason=
.&nbsp; The Error-Cause Attribute<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provide=
s more detail on the cause of the problem.&nbsp; It MAY be<BR>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; included within Disconnect-NAK and CoA-NAK packets.<BR><B=
R>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A summary of the Error-Cause Attribute for=
mat is shown below.&nbsp; The<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fields are =
transmitted from left to right.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 =
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Typ=
e&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp=
;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; Value<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Value (cont)=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>&nbsp;&nbsp; Type<BR><BR=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101 for Error-Cause<BR><BR>&nbsp;&nbsp; Len=
gth<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6<BR><BR>&nbsp;&nbsp; Value<BR><B=
R>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Value field is four octets, containing=
 an integer specifying<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the cause of the e=
rror. Values 0-199 and 300-399 are reserved.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; Values 200-299 represent successful completion, so that these<BR>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; values may only be sent within Disconnect-ACK or C=
oA-ACK packets<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and MUST NOT be sent withi=
n a Disconnect-NAK or CoA-NAK.&nbsp; Values<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 400-499 represent fatal errors committed by the RADIUS server, so<BR>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; that they MAY be sent within CoA-NAK or Disconn=
ect-NAK packets,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and MUST NOT be sent wit=
hin CoA-ACK or Disconnect-ACK packets.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Va=
lues 500-599 represent fatal errors occurring on a NAS or RADIUS<BR>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; proxy, so that they MAY be sent within CoA-NAK and =
Disconnect-NAK<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets, and MUST NOT be s=
ent within CoA-ACK or Disconnect-ACK<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pack=
ets.&nbsp; Error-Cause values SHOULD be logged by the RADIUS<BR>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; server.&nbsp; Error-Code values (expressed in decimal) =
include:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp;&nb=
sp; Value<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---&nbsp;&nbsp;&nbsp; -----<BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 201&nbsp;&nbsp;&nbsp; Residual Session Conte=
xt Removed<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 202&nbsp;&nbsp;&nbsp; Invalid =
EAP Packet (Ignored)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 401&nbsp;&nbsp;&nbsp=
; Unsupported Attribute<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 402&nbsp;&nbsp;&n=
bsp; Missing Attribute<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 403&nbsp;&nbsp;&nb=
sp; NAS Identification Mismatch<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 404&nbsp;=
&nbsp;&nbsp; Invalid Request<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 405&nbsp;&nb=
sp;&nbsp; Unsupported Service<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 406&nbsp;&n=
bsp;&nbsp; Unsupported Extension<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 407&nbsp=
;&nbsp;&nbsp; Invalid Attribute Value<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 501=
&nbsp;&nbsp;&nbsp; Administratively Prohibited<BR>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; 502&nbsp;&nbsp;&nbsp; Request Not Routable (Proxy)<BR>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; 503&nbsp;&nbsp;&nbsp; Session Context Not Found<BR>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; 504&nbsp;&nbsp;&nbsp; Session Context Not Removable<=
BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 505&nbsp;&nbsp;&nbsp; Other Proxy Process=
ing Error<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 506&nbsp;&nbsp;&nbsp; Resources=
 Unavailable<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 507&nbsp;&nbsp;&nbsp; Reques=
t Initiated<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Residual Session Context=
 Removed" is sent in response to a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Discon=
nect-Request if the user session is no longer active, but<BR>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; residual session context was found and successfully remove=
d.&nbsp; This<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value is only sent within a=
 Disconnect-ACK and MUST NOT be sent<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with=
in a CoA-ACK, Disconnect-NAK or CoA-NAK.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; be sent by implementations of this specificati=
on.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Unsupported Attribute" is a fata=
l error sent if a Request<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contains an att=
ribute (such as a Vendor-Specific or EAP-Message<BR>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; Attribute) that is not supported.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; "Missing Attribute" is a fatal error sent if critical attributes<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; (such as NAS or session identification attribu=
tes) are missing<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from a Request.<BR><BR>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "NAS Identification Mismatch" is a fatal erro=
r sent if one or more<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAS identification =
attributes (see Section 3) do not match the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; identity of the NAS receiving the Request.<BR><BR>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; "Invalid Request" is a fatal error sent if some other aspect of<BR=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Request is invalid, such as if one or m=
ore attributes (such as<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EAP- Message Attr=
ibute(s)) are not formatted properly.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 "Unsupported Service" is a fatal error sent if a Service-Type<BR>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; Attribute included with the Request is sent with an i=
nvalid or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unsupported value.&nbsp; This e=
rror cannot be sent in response to a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Disc=
onnect-Request.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Unsupported Extensio=
n" is a fatal error sent due to lack of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; s=
upport for an extension such as Disconnect and/or CoA packets.<BR>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; This will typically be sent by a proxy receiving an I=
CMP port<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unreachable message after attemp=
ting to forward a Request to the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAS.<BR>=
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Unsupported Attribute Value" is a fatal=
 error sent if a Request<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contains an attr=
ibute with an unsupported value.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Adm=
inistratively Prohibited" is a fatal error sent if the NAS is<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; configured to prohibit honoring of Request packets for=
 the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specified session.<BR><BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; "Request Not Routable" is a fatal error which MAY be s=
ent by a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RADIUS proxy and MUST NOT be sen=
t by a NAS.&nbsp; It indicates that the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R=
ADIUS proxy was unable to determine how to route the Request to<BR>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; the NAS.&nbsp; For example, this can occur if the re=
quired entries are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not present in the pro=
xy's realm routing table.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Session Co=
ntext Not Found" is a fatal error sent if the session<BR>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; context identified in the Request does not exist on the NAS.<B=
R><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Session Context Not Removable" is a f=
atal error sent in response<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to a Disconne=
ct-Request if the NAS was able to locate the session<BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; context, but could not remove it for some reason.&nbsp; It MUST=
 NOT be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sent within a CoA-ACK, CoA-NAK or=
 Disconnect-ACK, only within a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Disconnect=
-NAK.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Other Proxy Processing Error" =
is a fatal error sent in response<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to a Re=
quest that could not be processed by a proxy, for reasons<BR>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; other than routing.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
"Resources Unavailable" is a fatal error sent when a Request could<BR>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; not be honored due to lack of available NAS resou=
rces (memory,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; non- volatile storage, etc.=
).<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Request Initiated" is a fatal err=
or sent in response to a CoA-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request inc=
luding a Service-Type Attribute with a value of<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; "Authorize Only".&nbsp; It indicates that the CoA-Request has not be=
en<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; honored, but that a RADIUS Access-Requ=
est including a Service-Type<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Attribute wi=
th value "Authorize Only" is being sent to the RADIUS<BR>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; server.<BR><BR>4.&nbsp; Diameter Considerations<BR><BR>&nbsp;&=
nbsp; Due to differences in handling change-of-authorization requests in<BR=
>&nbsp;&nbsp; RADIUS and Diameter, it may be difficult or impossible for a<=
BR>&nbsp;&nbsp; Diameter/RADIUS gateway to successfully translate a Diamete=
r Re-Auth-<BR>&nbsp;&nbsp; Request (RAR) to a CoA-Request and vice versa.&n=
bsp; For example, since a<BR>&nbsp;&nbsp; CoA-Request only initiates an aut=
horization change but does not<BR>&nbsp;&nbsp; initiate re-authentication, =
a RAR command containing a Re-Auth-<BR>&nbsp;&nbsp; Request-Type AVP with v=
alue "AUTHORIZE_AUTHENTICATE" cannot be<BR>&nbsp;&nbsp; directly translated=
 to a CoA-Request.&nbsp; A Diameter/RADIUS gateway<BR>&nbsp;&nbsp; receivin=
g a CoA-Request containing authorization changes will need to<BR>&nbsp;&nbs=
p; translate this into two Diameter exchange.&nbsp; First, the<BR>&nbsp;&nb=
sp; Diameter/RADIUS gateway will issue a RAR command including a Session-<B=
R>&nbsp;&nbsp; Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE =
ONLY".<BR>&nbsp;&nbsp; Then the Diameter/RADIUS gateway will respond to the=
 ensuing access<BR>&nbsp;&nbsp; request with a response including the autho=
rization attributes<BR>&nbsp;&nbsp; gleaned from the CoA-Request.&nbsp; For=
 the translation to be possible,<BR>&nbsp;&nbsp; the CoA-Request MUST inclu=
de a Acct-Session-Id Attribute.&nbsp; If the<BR><BR>&nbsp;&nbsp; Diameter c=
lient uses the same Session-Id for both authorization and<BR>&nbsp;&nbsp; a=
ccounting, then the Diameter/RADIUS gateway can copy the contents of<BR>&nb=
sp;&nbsp; the Acct-Session-Id Attribute into the Session-Id AVP;&nbsp; othe=
rwise, it<BR>&nbsp;&nbsp; will need to map the Acct-Session-Id value to an =
equivalent Session-<BR>&nbsp;&nbsp; Id for use within a RAR command.<BR><BR=
>&nbsp;&nbsp; To simplify translation between RADIUS and Diameter, a server=
<BR>&nbsp;&nbsp; compliant with this specification MAY include a Service-Ty=
pe<BR>&nbsp;&nbsp; Attribute with value "Authorize Only" within a CoA-Reque=
st.&nbsp; Such a<BR>&nbsp;&nbsp; CoA-Request MUST contain a State Attribute=
.&nbsp; A NAS supporting the<BR>&nbsp;&nbsp; "Authorize Only" Service-Type =
within a CoA-Request responds with a<BR>&nbsp;&nbsp; CoA-NAK containing a S=
ervice-Type Attribute with value "Authorize<BR>&nbsp;&nbsp; Only", and an E=
rror-Cause Attribute with value "Request Initiated".<BR>&nbsp;&nbsp; The NA=
S will then send an Access-Request containing a Service-Type<BR>&nbsp;&nbsp=
; Attribute with a value of "Authorize Only", along with a State<BR>&nbsp;&=
nbsp; Attribute.&nbsp; A Diameter/RADIUS gateway receiving a CoA-Request<BR=
>&nbsp;&nbsp; containing a Service-Type with value "Authorize Only" transla=
tes this<BR>&nbsp;&nbsp; to a RAR with Re-Auth-Request-Type AVP with value =
"AUTHORIZE ONLY".<BR>&nbsp;&nbsp; The received RAA is then translated to a =
CoA-NAK with a Service-Type<BR>&nbsp;&nbsp; value of "Authorize Only".&nbsp=
;&nbsp; If the Result-Code AVP in the RAA has a<BR>&nbsp;&nbsp; value in th=
e success category, then an Error-Cause Attribute with<BR>&nbsp;&nbsp; valu=
e "Request Initiated" is included in the CoA-NAK.&nbsp;&nbsp; If the<BR>&nb=
sp;&nbsp; Result-Code AVP in the RAA has a value indicating a Protocol Erro=
r or<BR>&nbsp;&nbsp; a Transient or Permanent Failure, then an alternate Er=
ror-Cause<BR>&nbsp;&nbsp; Attribute is returned as suggested below.<BR><BR>=
&nbsp;&nbsp; Within Diameter, a server can request that a session be aborte=
d by<BR>&nbsp;&nbsp; sending an Abort-Session-Request (ASR), identifying th=
e session to be<BR>&nbsp;&nbsp; terminated using Session-ID and User-Name A=
VPs.&nbsp; The ASR command is<BR>&nbsp;&nbsp; translated to a Disconnect-Re=
quest containing an Acct-Session-Id and<BR>&nbsp;&nbsp; User-Name attribute=
.&nbsp; If the Diameter client utilizes the same<BR>&nbsp;&nbsp; Session-Id=
 in both authorization and accounting, then the value of<BR>&nbsp;&nbsp; th=
e Session-ID AVP may be placed in the Acct-Session-Id attribute;<BR>&nbsp;&=
nbsp; otherwise the value of the Session-ID AVP will need to be mapped to<B=
R>&nbsp;&nbsp; an appropriate Acct-Session-Id value.&nbsp;&nbsp; For a Disc=
onnect-Request to<BR>&nbsp;&nbsp; be translatable to an ASR, an Acct-Sessio=
n-Id attribute MUST be<BR>&nbsp;&nbsp; present.&nbsp; If the Diameter clien=
t utilizes the same Session-Id in both<BR>&nbsp;&nbsp; authorization and ac=
counting, then the value of the Acct-Session-Id<BR>&nbsp;&nbsp; may be plac=
ed into the Session-ID AVP within the ASR;&nbsp; otherwise the<BR>&nbsp;&nb=
sp; value of the Acct-Session-Id will need to be mapped to an appropriate<B=
R>&nbsp;&nbsp; Session-ID value.<BR><BR>&nbsp;&nbsp; An Abort-Session-Answe=
r (ASA) command is sent in response to an ASR<BR>&nbsp;&nbsp; in order to i=
ndicate the disposition of the request.&nbsp; A<BR>&nbsp;&nbsp; Diameter/RA=
DIUS gateway receiving a Disconnect-ACK translates this to<BR>&nbsp;&nbsp; =
an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS".&nbsp; A<BR>&nb=
sp;&nbsp; Disconnect-NAK received from the server is translated to an ASA<B=
R>&nbsp;&nbsp; command with a Result-Code AVP which depends on the value of=
 the<BR>&nbsp;&nbsp; Error-Cause Attribute.&nbsp; Suggested translations be=
tween Error-Cause<BR>&nbsp;&nbsp; Attribute values and Result-Code AVP valu=
es are included below:<BR><BR>&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; Error-=
Cause Attribute Value&nbsp;&nbsp; Result-Code AVP<BR>&nbsp;&nbsp; ---&nbsp;=
&nbsp; ---------------------------&nbsp; ------------------------<BR>&nbsp;=
&nbsp; 201&nbsp;&nbsp; Residual Session Context&nbsp;&nbsp;&nbsp;&nbsp; DIA=
METER_SUCCESS<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Removed<B=
R>&nbsp;&nbsp; 202&nbsp;&nbsp; Invalid EAP Packet&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_LIMITED_SUCCESS<BR>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Ignored)<BR>&nbsp;&nbsp; 401&nbsp;&nb=
sp; Unsupported Attribute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETE=
R_AVP_UNSUPPORTED<BR>&nbsp;&nbsp; 402&nbsp;&nbsp; Missing Attribute&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_MISSING=
_AVP<BR>&nbsp;&nbsp; 403&nbsp;&nbsp; NAS Identification&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_REALM_NOT_SERVED<BR>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mismatch<BR>&nbsp;&nbsp; 404&nb=
sp;&nbsp; Invalid Request&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_UNABLE_TO_COMPLY<BR>&nbsp;&nbsp; 405&=
nbsp;&nbsp; Unsupported Service&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; DIAMETER_COMMAND_UNSUPPORTED<BR>&nbsp;&nbsp; 406&nbsp;&nbsp; Uns=
upported Extension&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_APPLI=
CATION_UNSUPPORTED<BR>&nbsp;&nbsp; 407&nbsp;&nbsp; Invalid Attribute Value&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_INVALID_AVP_VALUE<BR>&nbsp;&nbsp; 50=
1&nbsp;&nbsp; Administratively&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_AUTHORIZATION_REJECTED<BR>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Prohibited<BR>&nbsp;&nbsp; 502&nbsp;&n=
bsp; Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER<BR>&nbsp;&nbsp=
; 503&nbsp;&nbsp; Session Context Not Found&nbsp;&nbsp;&nbsp; DIAMETER_UNKN=
OWN_SESSION_ID<BR>&nbsp;&nbsp; 504&nbsp;&nbsp; Session Context Not&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_AUTHORIZATION_REJECT=
ED<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Removable<BR>&nbsp;&=
nbsp; 505&nbsp;&nbsp; Other Proxy Processing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; DIAMETER_UNABLE_TO_COMPLY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Error<BR>&nbsp;&nbsp; 506&nbsp;&nbsp; Resources Unavailable&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_RESOURCES_EXCEEDED<BR>&nbsp;&n=
bsp; 507&nbsp;&nbsp; Request Initiated&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER_SUCCESS<BR><BR>&nbsp;&nbsp; Since bo=
th the ASR/ASA and Disconnect-Request/Disconnect-<BR>&nbsp;&nbsp; NAK/Disco=
nnect-ACK exchanges involve just a request and response,<BR>&nbsp;&nbsp; in=
clusion of an "Authorize Only" Service-Type within a Disconnect-<BR>&nbsp;&=
nbsp; Request is not needed to assist in Diameter/RADIUS translation, and<B=
R>&nbsp;&nbsp; may make translation more difficult.&nbsp; As a result, the =
Service-Type<BR>&nbsp;&nbsp; Attribute MUST NOT be used within a Disconnect=
-Request.<BR><BR>5.&nbsp; IANA Considerations<BR><BR>&nbsp;&nbsp; This docu=
ment uses the RADIUS [RFC2865] namespace, see<BR>&nbsp;&nbsp; &lt;http://ww=
w.iana.org/assignments/radius-types&gt;.&nbsp; In addition to the<BR>&nbsp;=
&nbsp; allocations already made in [RFC3576], this specification requests<B=
R>&nbsp;&nbsp; allocation of an additional value of the Error-Cause Attribu=
te (101):<BR><BR>&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; Value<BR>&nbsp;&nbs=
p; ---&nbsp;&nbsp; -----<BR>&nbsp;&nbsp; 407&nbsp;&nbsp; Invalid Attribute =
Value<BR><BR><BR><BR>
<BLOCKQUOTE>
<HR>
From: [email-masked]<BR>To: [email-masked]<BR>Subject: R=
E: Issue: Error-Cause Attribute in Disconnect-ACK?<BR>Date: Tue, 22 May 200=
7 12:57:11 -0700<BR><BR>
<META content=3D"Microsoft SafeHTML" name=3DGenerator>
<STYLE>
.ExternalClass P
{padding:0px;}
.ExternalClass
{font-size:10pt;font-family:Tahoma;}
</STYLE>
I also noticed another oddity in usage of the Error-Cause Attribute. <BR>&n=
bsp;<BR>It&nbsp;is stated that a CoA-NAK MUST always be sent in response to=
 a CoA-Request&nbsp;including a Service-Type Attribute with value "Authoriz=
e Only".&nbsp; If the CoA-Request can be processed, then sending an Error-C=
ause Attribute with value 507 (Request Initiated) is required.&nbsp; Howeve=
r, if the CoA-Request cannot be processed, sending an Error-Cause attribute=
 is optional.&nbsp; Given that NAS implementations supporting a Service-Typ=
e attribute with value "Authorize Only" have to be able to send the Error-C=
ause Attribute in the event that the Request can be processed, why isn't se=
nding an Error-Cause attribute a SHOULD in the event of an error? &nbsp;<BR=
>&nbsp;<BR><BR><BR>&gt; From: [email-masked]<BR>&gt; To: radiuse=
[email-masked]<BR>&gt; Subject: Issue: Error-Cause Attribute in Disconnect=
-ACK?<BR>&gt; Date: Tue, 22 May 2007 10:31:40 -0700<BR>&gt; <BR>&gt; <BR>&g=
t; Issue: Error-Cause Attribute in Disconnect-ACK?<BR>&gt; Submitter name: =
Bernard Aboba<BR>&gt; Submitter email address: [email-masked]<BR>&gt; =
Date first submitted: May 22, 2007<BR>&gt; Reference: <BR>&gt; Document: RF=
C3576bis-05<BR>&gt; Comment type: Technical<BR>&gt; Priority: S<BR>&gt; Sec=
tion: 3.4<BR>&gt; Rationale/Explanation of issue:<BR>&gt; <BR>&gt; In the p=
rocess of editing the attribute table to address Issue 226, I noticed an od=
dity. <BR>&gt; <BR>&gt; RFC 3576 Section 3.1 states the following:<BR>&gt; =
<BR>&gt; It is possible that the NAS cannot honor Disconnect-Request or<BR>=
&gt; CoA-Request messages for some reason. The Error-Cause Attribute<BR>&gt=
; provides more detail on the cause of the problem. It MAY be<BR>&gt; inclu=
ded within Disconnect-ACK, Disconnect-NAK and CoA-NAK<BR>&gt; messages.<BR>=
&gt; <BR>&gt; Why would an Error-Cause Attribute be included in a Disconnec=
t-ACK? It is not allowed in a CoA-ACK, for example. <BR>&gt; --<BR>&gt; to =
unsubscribe send a message to [email-masked] with<BR>&gt; t=
he word 'unsubscribe' in a single line as the message text body.<BR>&gt; ar=
chive: &lt;http://psg.com/lists/radiusext/&gt;<BR><BR></BLOCKQUOTE></body>
</html>=

--_116ae3dd-96c1-4f59-805d-380fbdf1233d_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 24 May 2007 00:09:16 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Wed, 23 May 2007 17:08:23 -0700

--_620ce6a7-56f2-442e-8219-cf050028ab68_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In looking over the text, there are some places where it could be cleaned u=
p.  Here is a revision of Sections 3, 3.2, 3.3, 3.6 and Appendix A:
=20
3.  Attributes   In Disconnect-Request and CoA-Request packets, certain att=
ributes are   used to uniquely identify the NAS as well as a user session o=
n the   NAS.  All NAS identification attributes included in a Request packe=
t   MUST match in order for a Disconnect-Request or CoA-Request to be   suc=
cessful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.   For sessio=
n identification attributes, the User-Name and Acct-   Session-Id Attribute=
s, if included, MUST match in order for a   Disconnect-Request or CoA-Reque=
st to be successful; other session   identification attributes SHOULD match=
.  Where a mismatch of session   identification attributes is detected, a D=
isconnect-NAK or CoA-NAK   SHOULD  be sent.   The ability to use NAS or ses=
sion identification attributes to map to   unique/multiple sessions is beyo=
nd the scope of this document.   Identification attributes include NAS and =
session identification   attributes, as described below.     NAS identifica=
tion attributes     Attribute             #    Reference  Description     -=
--------            ---   ---------  -----------     NAS-IP-Address        =
4    [RFC2865]  The IPv4 address of the NAS.     NAS-Identifier       32   =
 [RFC2865]  String identifying the NAS.     NAS-IPv6-Address     95    [RFC=
3162]  The IPv6 address of the NAS.     Session identification attributes  =
   Attribute              #   Reference  Description     ---------         =
    ---  ---------  -----------     User-Name              1   [RFC2865]  T=
he name of the user                                           associated wi=
th the session.     NAS-Port               5   [RFC2865]  The port on which=
 the                                           session is terminated.     C=
alled-Station-Id     30   [RFC2865]  The link address to which             =
                              the session is connected.     Calling-Station=
-Id    31   [RFC2865]  The link address from which                         =
                  the session is connected.     Acct-Session-Id       44   =
[RFC2866]  The identifier uniquely                                         =
  identifying the session                                           on the =
NAS.     Acct-Multi-Session-Id 50   [RFC2866]  The identifier uniquely     =
                                      identifying related sessions.     NAS=
-Port-Id           87   [RFC2869]  String identifying the port             =
                              where the session is.     Chargeable-User-   =
   89   [RFC4372]  The CUI associated with the     Identity                =
              session.  Needed where a                                     =
      privacy NAI is used, because                                         =
  the User-Name may not be                                           unique=
 (e.g. "anonymous").   To address security concerns described in Section 6.=
1, either the   User-Name or Chargeable-User-Identity attribute SHOULD be p=
resent in   Disconnect-Request and CoA-Request packets.   Where a Diameter =
client utilizes the same Session-Id for both   authorization and accounting=
, inclusion of an Acct-Session-Id   Attribute in a Disconnect-Request or Co=
A-Request can assist with   Diameter/RADIUS translation, since Diameter RAR=
 and ASR commands   include a Session-Id AVP.  An Acct-Session-Id attribute=
 SHOULD be   included in Disconnect-Request and CoA-Request packets.   Wher=
e the Acct-Session-Id Attribute is not present in a CoA-Request   or Discon=
nect-Request, it is possible that the User-Name or   Chargeable-User-Identi=
ty attributes will not be sufficient to   uniquely identify the session (e.=
g. if the same user has multiple   sessions on the NAS, or the privacy NAI =
is used).  As a result, one   or more of the Acct-Multi-Session-Id, Called-=
Station-Id, Calling-   Station-Id, NAS-Port and NAS-Port-Id attributes MAY =
be used as   additional session identification.   To address security conce=
rns described in Section 6.2, one or more of   the NAS-IP-Address or NAS-IP=
v6-Address Attributes SHOULD be present   in Disconnect-Request and CoA-Req=
uest packets; the NAS-Identifier   Attribute MAY be present.   A Disconnect=
-Request MUST contain only NAS and session identification   attributes.  If=
 other attributes are included in a Disconnect-   Request, implementations =
MUST send a Disconnect-NAK; an Error-Cause   Attribute with value "Unsuppor=
ted Attribute" MAY be included.
=20
3.2.  Authorize Only   Support for a CoA-Request including a Service-Type A=
ttribute with   value "Authorize Only" is OPTIONAL on the NAS and RADIUS se=
rver.  A   Service-Type Attribute MUST NOT be included within a Disconnect-=
   Request.   A NAS MUST respond to a CoA-Request including a Service-Type =
  Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST   NO=
T be sent.  If the NAS does not support a Service-Type value of   "Authoriz=
e Only" then it MUST respond with a CoA-NAK; an Error-Cause   value of 405 =
(Unsupported Service) SHOULD be included.   A CoA-Request containing a Serv=
ice-Type Attribute with value   "Authorize Only" MUST in addition contain o=
nly NAS or session   identification attributes, as well as a State Attribut=
e.  If other   attributes are included in such a CoA-Request, a CoA-NAK MUS=
T be   sent; an Error-Cause Attribute with value 401 (Unsupported Attribute=
)   SHOULD be included.   If a CoA-Request packet including a Service-Type =
value of "Authorize   Only" is successfully processed, the NAS MUST respond=
 with a CoA-NAK   containing a Service-Type Attribute with value "Authorize=
 Only", and   an Error-Cause Attribute with value 507 (Request Initiated). =
 The NAS   then MUST send an Access-Request to the RADIUS server including =
a   Service-Type Attribute with value "Authorize Only".  This Access-   Req=
uest SHOULD contain the NAS identification attributes from the   CoA-Reques=
t, as well as the session identification attributes from   the CoA-Request =
legal for inclusion in an Access-Request as specified   in [RFC2865], [RFC2=
868], [RFC2869] and [RFC3162].  As noted in   [RFC2869] Section 5.19, a Mes=
sage-Authenticator attribute SHOULD be   included in an Access-Request that=
 does not contain a User-Password,   CHAP-Password, ARAP-Password or EAP-Me=
ssage Attribute.  The RADIUS   server then will respond to the Access-Reque=
st with an Access-Accept   to (re-)authorize the session or an Access-Rejec=
t to refuse to   (re-)authorize it.3.3.  State   The State Attribute is ava=
ilable to be sent by the RADIUS server to   the NAS in a CoA-Request packet=
 and MUST be sent unmodified from the   NAS to the RADIUS server in a subse=
quent ACK or NAK packet.   [RFC2865] Section 5.44 states:      An Access-Re=
quest MUST contain either a User-Password or a CHAP-      Password or State=
.  An Access-Request MUST NOT contain both a      User-Password and a CHAP-=
Password.  If future extensions allow      other kinds of authentication in=
formation to be conveyed, the      attribute for that can be used in an Acc=
ess-Request instead of      User-Password or CHAP-Password.   In order to s=
atisfy the requirements of [RFC2865] Section 5.44, an   Access-Request with=
 Service-Type=3D"Authorize-Only" MUST contain a   State attribute.   In ord=
er to provide a State attribute to the NAS, a server sending a   CoA-Reques=
t with a Service-Type value of "Authorize-Only" MUST   include a State Attr=
ibute, and the NAS MUST send the State Attribute   unmodified to the RADIUS=
 server in the resulting Access-Request, if   any.  A NAS receiving a CoA-R=
equest containing a Service-Type value   of "Authorize-Only" but lacking a =
State attribute MUST send a CoA-NAK   and SHOULD include an Error-Cause att=
ribute with value 402 (Missing   Attribute).   The State Attribute is also =
available to be sent by the RADIUS server   to the NAS in a CoA-Request tha=
t also includes a Termination-Action   Attribute with the value of RADIUS-R=
equest.  If the client performs   the Termination-Action by sending a new A=
ccess-Request upon   termination of the current session, it MUST include th=
e State   Attribute unchanged in that Access-Request.  In either usage, the=
   client MUST NOT interpret the Attribute locally.  A CoA-Request   packet=
 must have only zero or one State Attribute.  Usage of the   State Attribut=
e is implementation dependent.
=20
3.6.  Table of Attributes   The following table provides a guide to which a=
ttributes may be found   in which packets, and in what quantity.   Change-o=
f-Authorization Messages   Request   ACK      NAK   #   Attribute   0-1    =
   0        0     1   User-Name [Note 1]   0-1       0        0     4   NAS=
-IP-Address [Note 1]   0-1       0        0     5   NAS-Port [Note 1]   0-1=
       0        0-1   6   Service-Type   0-1       0        0     7   Frame=
d-Protocol [Note 3]   0-1       0        0     8   Framed-IP-Address [Note =
6]   0-1       0        0     9   Framed-IP-Netmask [Note 6]   0-1       0 =
       0    10   Framed-Routing [Note 3]   0+        0        0    11   Fil=
ter-ID [Note 3]   0-1       0        0    12   Framed-MTU [Note 3]   0+    =
    0        0    13   Framed-Compression [Note 3]   0+        0        0  =
  14   Login-IP-Host [Note 3]   0-1       0        0    15   Login-Service =
[Note 3]   0-1       0        0    16   Login-TCP-Port [Note 3]   0+       =
 0        0    18   Reply-Message [Note 2]   0-1       0        0    19   C=
allback-Number [Note 3]   0-1       0        0    20   Callback-Id [Note 3]=
   0+        0        0    22   Framed-Route [Note 3]   0-1       0        =
0    23   Framed-IPX-Network [Note 6]   0-1       0-1      0-1  24   State =
  0+        0        0    25   Class [Note 3]   0+        0        0    26 =
  Vendor-Specific [Note 3]   0-1       0        0    27   Session-Timeout [=
Note 3]   0-1       0        0    28   Idle-Timeout [Note 3]   0-1       0 =
       0    29   Termination-Action [Note 3]   0-1       0        0    30  =
 Called-Station-Id [Note 1]   0-1       0        0    31   Calling-Station-=
Id [Note 1]   0-1       0        0    32   NAS-Identifier [Note 1]   Reques=
t   ACK      NAK   #   Attribute   Request   ACK      NAK   #   Attribute  =
 0+        0+       0+   33   Proxy-State   0-1       0        0    34   Lo=
gin-LAT-Service [Note 3]   0-1       0        0    35   Login-LAT-Node [Not=
e 3]   0-1       0        0    36   Login-LAT-Group [Note 3]   0-1       0 =
       0    37   Framed-AppleTalk-Link [Note 3]   0+        0        0    3=
8   Framed-AppleTalk-Network [Note 3]   0-1       0        0    39   Framed=
-AppleTalk-Zone [Note 3]   0-1       0        0    44   Acct-Session-Id [No=
te 1]   0-1       0        0    50   Acct-Multi-Session-Id [Note 1]   0-1  =
     0-1      0-1  55   Event-Timestamp   0+        0        0    56   Egre=
ss-VLANID [Note 3]   0-1       0        0    57   Ingress-Filters [Note 3] =
  0+        0        0    58   Egress-VLAN-Name [Note 3]   0-1       0     =
   0    59   User-Priority-Table [Note 3]   0-1       0        0    61   NA=
S-Port-Type [Note 3]   0-1       0        0    62   Port-Limit [Note 3]   0=
-1       0        0    63   Login-LAT-Port [Note 3]   0+        0        0 =
   64   Tunnel-Type [Note 5]   0+        0        0    65   Tunnel-Medium-T=
ype [Note 5]   0+        0        0    66   Tunnel-Client-Endpoint [Note 5]=
   0+        0        0    67   Tunnel-Server-Endpoint [Note 5]   0+       =
 0        0    69   Tunnel-Password [Note 5]   0-1       0        0    71  =
 ARAP-Features [Note 3]   0-1       0        0    72   ARAP-Zone-Access [No=
te 3]   0+        0        0    78   Configuration-Token [Note 3]   0+     =
   0-1      0    79   EAP-Message [Note 2]   0-1       0-1      0-1  80   M=
essage-Authenticator   0+        0        0    81   Tunnel-Private-Group-ID=
 [Note 5]   0+        0        0    82   Tunnel-Assignment-ID [Note 5]   0+=
        0        0    83   Tunnel-Preference [Note 5]   0-1       0        =
0    85   Acct-Interim-Interval [Note 3]   0-1       0        0    87   NAS=
-Port-Id [Note 1]   0-1       0        0    88   Framed-Pool [Note 6]   0-1=
       0        0    89   Chargeable-User-Identity [Note 1]   0+        0  =
      0    90   Tunnel-Client-Auth-ID [Note 5]   0+        0        0    91=
   Tunnel-Server-Auth-ID [Note 5]   0-1       0        0    92   NAS-Filter=
-Rule [Note 3]   0         0        0    94   Originating-Line-Info   0-1  =
     0        0    95   NAS-IPv6-Address [Note 1]   0-1       0        0   =
 96   Framed-Interface-Id [Note 6]   0+        0        0    97   Framed-IP=
v6-Prefix [Note 6]   0+        0        0    98   Login-IPv6-Host [Note 3] =
  0+        0        0    99   Framed-IPv6-Route [Note 3]   0-1       0    =
    0   100   Framed-IPv6-Pool [Note 6]   0         0        0+  101   Erro=
r-Cause   0+        0        0   123   Delegated-IPv6-Prefix [Note 6]   Req=
uest   ACK      NAK   #   Attribute   Disconnect Messages   Request   ACK  =
    NAK   #   Attribute   0-1       0        0     1   User-Name [Note 1]  =
 0-1       0        0     4   NAS-IP-Address [Note 1]   0-1       0        =
0     5   NAS-Port [Note 1]   0         0        0     6   Service-Type   0=
         0        0     8   Framed-IP-Address [Note 6]   0+        0       =
 0    18   Reply-Message [Note 2]   0         0        0    24   State   0+=
        0        0    25   Class [Note 4]   0+        0        0    26   Ve=
ndor-Specific   0-1       0        0    30   Called-Station-Id [Note 1]   0=
-1       0        0    31   Calling-Station-Id [Note 1]   0-1       0      =
  0    32   NAS-Identifier [Note 1]   0+        0+       0+   33   Proxy-St=
ate   0-1       0        0    44   Acct-Session-Id [Note 1]   0-1       0-1=
      0    49   Acct-Terminate-Cause   0-1       0        0    50   Acct-Mu=
lti-Session-Id [Note 1]   0-1       0-1      0-1  55   Event-Timestamp   0 =
        0        0    61   NAS-Port-Type   0+        0-1      0    79   EAP=
-Message [Note 2]   0-1       0-1      0-1  80   Message-Authenticator   0-=
1       0        0    87   NAS-Port-Id [Note 1]   0-1       0        0    8=
9   Chargeable-User-Identity [Note 1]   0-1       0        0    95   NAS-IP=
v6-Address [Note 1]   0         0        0    96   Framed-Interface-Id [Not=
e 6]   0         0        0    97   Framed-IPv6-Prefix [Note 6]   0        =
 0        0   100   Framed-IPv6-Pool [Note 6]   0         0        0+  101 =
  Error-Cause   Request   ACK      NAK   #   Attribute   The following tabl=
e defines the meaning of the above table entries.0     This attribute MUST =
NOT be present in packet.0+    Zero or more instances of this attribute MAY=
 be present in packet.0-1   Zero or one instance of this attribute MAY be p=
resent in packet.1     Exactly one instance of this attribute MUST be prese=
nt in packet.   [Note 1] Where NAS or session identification attributes are=
 included   in Disconnect-Request or CoA-Request packets, they are used for=
   identification purposes only.  These attributes MUST NOT be used for   p=
urposes other than identification (e.g. within CoA-Request packets   to req=
uest authorization changes).   [Note 2] The Reply-Message Attribute is used=
 to present a displayable   message to the user.  The message is only displ=
ayed as a result of a   successful Disconnect-Request or CoA-Request (where=
 a Disconnect-ACK   or CoA-ACK is subsequently sent).  Where EAP is used fo=
r   authentication, an EAP-Message/Notification-Request Attribute is sent  =
 instead, and Disconnect-ACK or CoA-ACK packets contain an EAP-   Message/N=
otification-Response Attribute.   [Note 3] When included within a CoA-Reque=
st, these attributes   represent an authorization change request.  When one=
 of these   attributes is omitted from a CoA-Request, the NAS assumes that =
the   attribute value is to remain unchanged.  Attributes included in a   C=
oA-Request replace all existing value(s) of the same attribute(s).   [Note =
4] When included within a successful Disconnect-Request (where   a Disconne=
ct-ACK is subsequently sent), the Class Attribute SHOULD be   sent unmodifi=
ed by the client to the accounting server in the   Accounting Stop packet. =
 If the Disconnect-Request is unsuccessful,   then the Class Attribute is n=
ot processed.   [Note 5] When included within a CoA-Request, these attribut=
es   represent an authorization change request.  Where tunnel attribute(s) =
  are included within a successful CoA-Request, all existing tunnel   attri=
butes are removed and replaced by the new attribute(s).   [Note 6] Where in=
cluded within a CoA-Request, these attributes   represent a renumbering req=
uest.  Since these attributes are not used   for session identification, th=
ey MUST NOT be included within a   Disconnect-Request.  Note that renumberi=
ng may not be possible in all   situations.  For example, in order to chang=
e an IP address on receipt   of a changed  Framed-IP-Address address, IPCP =
re-negotiation could be   required, which is not supported by all PPP imple=
mentations.
=20
Appendix A - Changes from RFC 3576   This Appendix lists the major changes =
between [RFC3576] and this   document.  Minor changes, including style, gra=
mmar, spelling, and   editorial changes are not mentioned here.   o Added r=
equirement for duplicate detection on the RADIUS client   (Section 2.3).   =
o Added Chargeable-User-Identity as a session identification   attribute.  =
Removed Framed-IP-Address, Framed-IPv6-Prefix, Framed-   Interface-Id and N=
AS-Port-Type attributes as session identification   attributes (Section 3).=
   o Added details relating to handling of the Proxy-State Attribute   (Sec=
tion 3.1).   o Added statement that support for "Authorize Only" Service-Ty=
pe is   optional (Section 3.2).   o Added requirements for inclusion of the=
 State Attribute in CoA-   Request packets with a Service-Type of "Authoriz=
e Only" (Section   3.3).   o Added clarification on the calculation of the =
Message-Authenticator   Attribute (Section 3.4).   o An additional Error-Ca=
use Attribute value (407) is allocated for   Invalid Attribute Value (Secti=
ons 3.5, 4).   o Updated CoA-Request Attribute Table to include Filter-Rule=
,   Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN-   N=
ame and User-Priority attributes (Section 3.6).   o Added the Chargeable-Us=
er-Identity Attribute to both the CoA-   Request and Disconnect-Request Att=
ribute table (Section 3.6).   o Added note on the use of the CoA-Request fo=
r renumbering (Section   3.6).   o Use of Service-Type Attribute within a D=
isconnect-Request is   prohibited (Sections 3.2, 3.6, 4).   o Added Diamete=
r Considerations (Section 4).   o Changed the text to indicate that the Eve=
nt-Timestamp Attribute   should not be recalculated on retransmission.  The=
 implications for   replay and duplicate detection are discussed (Section 6=
.4).=

--_620ce6a7-56f2-442e-8219-cf050028ab68_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
In looking over the text, there are some places where it could be cleaned u=
p.&nbsp; Here is a revision of Sections 3, 3.2, 3.3, 3.6 and Appendix A:<BR=
>
&nbsp;<BR>
3.&nbsp; Attributes<BR><BR>&nbsp;&nbsp; In Disconnect-Request and CoA-Reque=
st packets, certain attributes are<BR>&nbsp;&nbsp; used to uniquely identif=
y the NAS as well as a user session on the<BR>&nbsp;&nbsp; NAS.&nbsp; All N=
AS identification attributes included in a Request packet<BR>&nbsp;&nbsp; M=
UST match in order for a Disconnect-Request or CoA-Request to be<BR>&nbsp;&=
nbsp; successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.<BR>=
&nbsp;&nbsp; For session identification attributes, the User-Name and Acct-=
<BR>&nbsp;&nbsp; Session-Id Attributes, if included, MUST match in order fo=
r a<BR>&nbsp;&nbsp; Disconnect-Request or CoA-Request to be successful; oth=
er session<BR>&nbsp;&nbsp; identification attributes SHOULD match.&nbsp; Wh=
ere a mismatch of session<BR>&nbsp;&nbsp; identification attributes is dete=
cted, a Disconnect-NAK or CoA-NAK<BR>&nbsp;&nbsp; SHOULD&nbsp; be sent.<BR>=
<BR>&nbsp;&nbsp; The ability to use NAS or session identification attribute=
s to map to<BR>&nbsp;&nbsp; unique/multiple sessions is beyond the scope of=
 this document.<BR>&nbsp;&nbsp; Identification attributes include NAS and s=
ession identification<BR>&nbsp;&nbsp; attributes, as described below.<BR><B=
R>&nbsp;&nbsp;&nbsp;&nbsp; NAS identification attributes<BR><BR>&nbsp;&nbsp=
;&nbsp;&nbsp; Attribute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; Reference&nbsp; Description<BR>&nb=
sp;&nbsp;&nbsp;&nbsp; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; ---&nbsp;&nbsp; ---------&nbsp; -----------<BR>&nbsp=
;&nbsp;&nbsp;&nbsp; NAS-IP-Address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 4&nbsp;&nbsp;&nbsp; [RFC2865]&nbsp; The IPv4 address of the NAS.<BR>&nbsp=
;&nbsp;&nbsp;&nbsp; NAS-Identifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32&n=
bsp;&nbsp;&nbsp; [RFC2865]&nbsp; String identifying the NAS.<BR>&nbsp;&nbsp=
;&nbsp;&nbsp; NAS-IPv6-Address&nbsp;&nbsp;&nbsp;&nbsp; 95&nbsp;&nbsp;&nbsp;=
 [RFC3162]&nbsp; The IPv6 address of the NAS.<BR><BR>&nbsp;&nbsp;&nbsp;&nbs=
p; Session identification attributes<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; Attrib=
ute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; #&nbsp;&nbsp; Reference&nbsp; Description<BR>&nbsp;&nbsp;&nbsp;&nbsp=
; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; ---&nbsp; ---------&nbsp; -----------<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
User-Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 1&nbsp;&nbsp; [RFC2865]&nbsp; The name of the user<BR>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; associated with the session.<BR>&nbsp;&nbsp;&nbsp;&nbsp=
; NAS-Port&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp; [RFC2865]&nbsp; The port on which the<BR>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; session is terminated.<BR>&nbsp;&nbsp;&nbsp;&nb=
sp; Called-Station-Id&nbsp;&nbsp;&nbsp;&nbsp; 30&nbsp;&nbsp; [RFC2865]&nbsp=
; The link address to which<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the session is c=
onnected.<BR>&nbsp;&nbsp;&nbsp;&nbsp; Calling-Station-Id&nbsp;&nbsp;&nbsp; =
31&nbsp;&nbsp; [RFC2865]&nbsp; The link address from which<BR>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; the session is connected.<BR>&nbsp;&nbsp;&nbsp;&nbsp; Acct-S=
ession-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44&nbsp;&nbsp; [RFC2866]&nbsp=
; The identifier uniquely<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifying the se=
ssion<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on the NAS.<BR>&nbsp;&nbsp;&nbsp;&nbsp=
; Acct-Multi-Session-Id 50&nbsp;&nbsp; [RFC2866]&nbsp; The identifier uniqu=
ely<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifying related sessions.<BR>&nbsp;&=
nbsp;&nbsp;&nbsp; NAS-Port-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; 87&nbsp;&nbsp; [RFC2869]&nbsp; String identifying the port<B=
R>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where the session is.<BR>&nbsp;&nbsp;&nbsp;&n=
bsp; Chargeable-User-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 89&nbsp;&nbsp; [RFC4372=
]&nbsp; The CUI associated with the<BR>&nbsp;&nbsp;&nbsp;&nbsp; Identity&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; session.&nbsp; Needed where a<BR>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; privacy NAI is used, because<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Use=
r-Name may not be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unique (e.g. "anonymous").=
<BR><BR>&nbsp;&nbsp; To address security concerns described in Section 6.1,=
 either the<BR>&nbsp;&nbsp; User-Name or Chargeable-User-Identity attribute=
 SHOULD be present in<BR>&nbsp;&nbsp; Disconnect-Request and CoA-Request pa=
ckets.<BR><BR>&nbsp;&nbsp; Where a Diameter client utilizes the same Sessio=
n-Id for both<BR>&nbsp;&nbsp; authorization and accounting, inclusion of an=
 Acct-Session-Id<BR>&nbsp;&nbsp; Attribute in a Disconnect-Request or CoA-R=
equest can assist with<BR>&nbsp;&nbsp; Diameter/RADIUS translation, since D=
iameter RAR and ASR commands<BR>&nbsp;&nbsp; include a Session-Id AVP.&nbsp=
; An Acct-Session-Id attribute SHOULD be<BR>&nbsp;&nbsp; included in Discon=
nect-Request and CoA-Request packets.<BR><BR>&nbsp;&nbsp; Where the Acct-Se=
ssion-Id Attribute is not present in a CoA-Request<BR>&nbsp;&nbsp; or Disco=
nnect-Request, it is possible that the User-Name or<BR>&nbsp;&nbsp; Chargea=
ble-User-Identity attributes will not be sufficient to<BR>&nbsp;&nbsp; uniq=
uely identify the session (e.g. if the same user has multiple<BR>&nbsp;&nbs=
p; sessions on the NAS, or the privacy NAI is used).&nbsp; As a result, one=
<BR>&nbsp;&nbsp; or more of the Acct-Multi-Session-Id, Called-Station-Id, C=
alling-<BR>&nbsp;&nbsp; Station-Id, NAS-Port and NAS-Port-Id attributes MAY=
 be used as<BR>&nbsp;&nbsp; additional session identification.<BR><BR>&nbsp=
;&nbsp; To address security concerns described in Section 6.2, one or more =
of<BR>&nbsp;&nbsp; the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD=
 be present<BR>&nbsp;&nbsp; in Disconnect-Request and CoA-Request packets; =
the NAS-Identifier<BR>&nbsp;&nbsp; Attribute MAY be present.<BR><BR>&nbsp;&=
nbsp; A Disconnect-Request MUST contain only NAS and session identification=
<BR>&nbsp;&nbsp; attributes.&nbsp; If other attributes are included in a Di=
sconnect-<BR>&nbsp;&nbsp; Request, implementations MUST send a Disconnect-N=
AK; an Error-Cause<BR>&nbsp;&nbsp; Attribute with value "Unsupported Attrib=
ute" MAY be included.<BR>
&nbsp;<BR>
3.2.&nbsp; Authorize Only<BR><BR>&nbsp;&nbsp; Support for a CoA-Request inc=
luding a Service-Type Attribute with<BR>&nbsp;&nbsp; value "Authorize Only"=
 is OPTIONAL on the NAS and RADIUS server.&nbsp; A<BR>&nbsp;&nbsp; Service-=
Type Attribute MUST NOT be included within a Disconnect-<BR>&nbsp;&nbsp; Re=
quest.<BR><BR>&nbsp;&nbsp; A NAS MUST respond to a CoA-Request including a =
Service-Type<BR>&nbsp;&nbsp; Attribute with value "Authorize Only" with a C=
oA-NAK; a CoA-ACK MUST<BR>&nbsp;&nbsp; NOT be sent.&nbsp; If the NAS does n=
ot support a Service-Type value of<BR>&nbsp;&nbsp; "Authorize Only" then it=
 MUST respond with a CoA-NAK; an Error-Cause<BR>&nbsp;&nbsp; value of 405 (=
Unsupported Service) SHOULD be included.<BR><BR>&nbsp;&nbsp; A CoA-Request =
containing a Service-Type Attribute with value<BR>&nbsp;&nbsp; "Authorize O=
nly" MUST in addition contain only NAS or session<BR>&nbsp;&nbsp; identific=
ation attributes, as well as a State Attribute.&nbsp; If other<BR>&nbsp;&nb=
sp; attributes are included in such a CoA-Request, a CoA-NAK MUST be<BR>&nb=
sp;&nbsp; sent; an Error-Cause Attribute with value 401 (Unsupported Attrib=
ute)<BR>&nbsp;&nbsp; SHOULD be included.<BR><BR>&nbsp;&nbsp; If a CoA-Reque=
st packet including a Service-Type value of "Authorize<BR>&nbsp;&nbsp; Only=
" is successfully processed, the NAS MUST respond with a CoA-NAK<BR>&nbsp;&=
nbsp; containing a Service-Type Attribute with value "Authorize Only", and<=
BR>&nbsp;&nbsp; an Error-Cause Attribute with value 507 (Request Initiated)=
.&nbsp; The NAS<BR>&nbsp;&nbsp; then MUST send an Access-Request to the RAD=
IUS server including a<BR>&nbsp;&nbsp; Service-Type Attribute with value "A=
uthorize Only".&nbsp; This Access-<BR>&nbsp;&nbsp; Request SHOULD contain t=
he NAS identification attributes from the<BR>&nbsp;&nbsp; CoA-Request, as w=
ell as the session identification attributes from<BR>&nbsp;&nbsp; the CoA-R=
equest legal for inclusion in an Access-Request as specified<BR>&nbsp;&nbsp=
; in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].&nbsp; As noted in<BR>&n=
bsp;&nbsp; [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD=
 be<BR>&nbsp;&nbsp; included in an Access-Request that does not contain a U=
ser-Password,<BR>&nbsp;&nbsp; CHAP-Password, ARAP-Password or EAP-Message A=
ttribute.&nbsp; The RADIUS<BR>&nbsp;&nbsp; server then will respond to the =
Access-Request with an Access-Accept<BR>&nbsp;&nbsp; to (re-)authorize the =
session or an Access-Reject to refuse to<BR>&nbsp;&nbsp; (re-)authorize it.=
<BR><BR>3.3.&nbsp; State<BR><BR>&nbsp;&nbsp; The State Attribute is availab=
le to be sent by the RADIUS server to<BR>&nbsp;&nbsp; the NAS in a CoA-Requ=
est packet and MUST be sent unmodified from the<BR>&nbsp;&nbsp; NAS to the =
RADIUS server in a subsequent ACK or NAK packet.<BR><BR>&nbsp;&nbsp; [RFC28=
65] Section 5.44 states:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An Access-Re=
quest MUST contain either a User-Password or a CHAP-<BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; Password or State.&nbsp; An Access-Request MUST NOT contain bot=
h a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password and a CHAP-Password.&nb=
sp; If future extensions allow<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other kind=
s of authentication information to be conveyed, the<BR>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; attribute for that can be used in an Access-Request instead of<B=
R>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password or CHAP-Password.<BR><BR>&nb=
sp;&nbsp; In order to satisfy the requirements of [RFC2865] Section 5.44, a=
n<BR>&nbsp;&nbsp; Access-Request with Service-Type=3D"Authorize-Only" MUST =
contain a<BR>&nbsp;&nbsp; State attribute.<BR><BR>&nbsp;&nbsp; In order to =
provide a State attribute to the NAS, a server sending a<BR>&nbsp;&nbsp; Co=
A-Request with a Service-Type value of "Authorize-Only" MUST<BR>&nbsp;&nbsp=
; include a State Attribute, and the NAS MUST send the State Attribute<BR>&=
nbsp;&nbsp; unmodified to the RADIUS server in the resulting Access-Request=
, if<BR>&nbsp;&nbsp; any.&nbsp; A NAS receiving a CoA-Request containing a =
Service-Type value<BR>&nbsp;&nbsp; of "Authorize-Only" but lacking a State =
attribute MUST send a CoA-NAK<BR>&nbsp;&nbsp; and SHOULD include an Error-C=
ause attribute with value 402 (Missing<BR>&nbsp;&nbsp; Attribute).<BR><BR>&=
nbsp;&nbsp; The State Attribute is also available to be sent by the RADIUS =
server<BR>&nbsp;&nbsp; to the NAS in a CoA-Request that also includes a Ter=
mination-Action<BR>&nbsp;&nbsp; Attribute with the value of RADIUS-Request.=
&nbsp; If the client performs<BR>&nbsp;&nbsp; the Termination-Action by sen=
ding a new Access-Request upon<BR>&nbsp;&nbsp; termination of the current s=
ession, it MUST include the State<BR>&nbsp;&nbsp; Attribute unchanged in th=
at Access-Request.&nbsp; In either usage, the<BR>&nbsp;&nbsp; client MUST N=
OT interpret the Attribute locally.&nbsp; A CoA-Request<BR>&nbsp;&nbsp; pac=
ket must have only zero or one State Attribute.&nbsp; Usage of the<BR>&nbsp=
;&nbsp; State Attribute is implementation dependent.<BR>
&nbsp;<BR>
3.6.&nbsp; Table of Attributes<BR><BR>&nbsp;&nbsp; The following table prov=
ides a guide to which attributes may be found<BR>&nbsp;&nbsp; in which pack=
ets, and in what quantity.<BR><BR>&nbsp;&nbsp; Change-of-Authorization Mess=
ages<BR><BR>&nbsp;&nbsp; Request&nbsp;&nbsp; ACK&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; NAK&nbsp;&nbsp; #&nbsp;&nbsp; Attribute<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp=
;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; User-Name [Note 1]<BR>&nbsp;&nbsp; 0-1&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp; NAS-IP-Address [Note 1]<BR>&nbsp=
;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp; NAS-Port [Note 1]<=
BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp; 6&nbsp;&nbsp; Service-Type<BR>&nbs=
p;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 7&nbsp;&nbsp; Framed-Protocol [=
Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp; Fr=
amed-IP-Address [Note 6]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;=
 9&nbsp;&nbsp; Framed-IP-Netmask [Note 6]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&=
nbsp;&nbsp; 10&nbsp;&nbsp; Framed-Routing [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; 0&nbsp;&nbsp;&nbsp; 11&nbsp;&nbsp; Filter-ID [Note 3]<BR>&nbsp;&nbsp;=
 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp; Framed-MTU [Note 3]<BR>&nbsp;&=
nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 13&nbsp;&nbsp; Framed-Compression [=
Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 14&nbsp;&nbsp; Lo=
gin-IP-Host [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 15&nbsp;&=
nbsp; Login-Service [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 1=
6&nbsp;&nbsp; Login-TCP-Port [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp; 18&nbsp;&nbsp; Reply-Message [Note 2]<BR>&nbsp;&nbsp; 0-1&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp; 19&nbsp;&nbsp; Callback-Number [Note 3]<BR>&nbsp;&nbsp=
; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 20&nbsp;&nbsp; Callback-Id [Note 3]<BR>&nbsp=
;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 22&nbsp;&nbsp; Framed-Route [Note=
 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 23&nbsp;&nbsp; Framed-IPX-=
Network [Note 6]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-=
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp; 24&nbsp;&nbsp; State<BR>&nbsp;&nb=
sp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 25&nbsp;&nbsp; Class [Note 3]<BR>&nbs=
p;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 26&nbsp;&nbsp; Vendor-Specific [=
Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 27&nbsp;&nbsp; Session=
-Timeout [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 28&nbsp;&nbs=
p; Idle-Timeout [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 29&nb=
sp;&nbsp; Termination-Action [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp=
;&nbsp; 30&nbsp;&nbsp; Called-Station-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp; 31&nbsp;&nbsp; Calling-Station-Id [Note 1]<BR>&nbsp;&nb=
sp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 32&nbsp;&nbsp; NAS-Identifier [Note 1]<BR>=
&nbsp;&nbsp; Request&nbsp;&nbsp; ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAK&nbsp=
;&nbsp; #&nbsp;&nbsp; Attribute<BR><BR>&nbsp;&nbsp; Request&nbsp;&nbsp; ACK=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAK&nbsp;&nbsp; #&nbsp;&nbsp; Attribute<BR>&=
nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp; 33&nbsp;&nbsp; Proxy-State<BR>&nbsp;&nb=
sp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 34&nbsp;&nbsp; Login-LAT-Service [Note 3]<=
BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 35&nbsp;&nbsp; Login-LAT-Node =
[Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 36&nbsp;&nbsp; Login-=
LAT-Group [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 37&nbsp;&nb=
sp; Framed-AppleTalk-Link [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nb=
sp;&nbsp; 38&nbsp;&nbsp; Framed-AppleTalk-Network [Note 3]<BR>&nbsp;&nbsp; =
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0&nbsp;&nbsp;&nbsp; 39&nbsp;&nbsp; Framed-AppleTalk-Zone [Note 3]<=
BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 44&nbsp;&nbsp; Acct-Session-Id=
 [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 50&nbsp;&nbsp; Acct-=
Multi-Session-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp; 55&nbsp;&nbsp; Event-Tim=
estamp<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 56&nbsp;&nbsp; Egr=
ess-VLANID [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 57&nbsp;&n=
bsp; Ingress-Filters [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&n=
bsp; 58&nbsp;&nbsp; Egress-VLAN-Name [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nb=
sp;&nbsp;&nbsp; 59&nbsp;&nbsp; User-Priority-Table [Note 3]<BR>&nbsp;&nbsp;=
 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp; 61&nbsp;&nbsp; NAS-Port-Type [Note 3]<BR>&nbs=
p;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 62&nbsp;&nbsp; Port-Limit [Note 3]<BR=
>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 63&nbsp;&nbsp; Login-LAT-Port [N=
ote 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 64&nbsp;&nbsp; Tun=
nel-Type [Note 5]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 65&nbsp=
;&nbsp; Tunnel-Medium-Type [Note 5]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&n=
bsp;&nbsp; 66&nbsp;&nbsp; Tunnel-Client-Endpoint [Note 5]<BR>&nbsp;&nbsp; 0=
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 67&nbsp;&nbsp; Tunnel-Server-Endpoint [Not=
e 5]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 69&nbsp;&nbsp; Tunne=
l-Password [Note 5]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 71&nbsp;&n=
bsp; ARAP-Features [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 72=
&nbsp;&nbsp; ARAP-Zone-Access [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp=
;&nbsp;&nbsp; 78&nbsp;&nbsp; Configuration-Token [Note 3]<BR>&nbsp;&nbsp; 0=
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0&nbsp;&nbsp;&nbsp; 79&nbsp;&nbsp; EAP-Message [Note 2]<BR>&nbsp;&nbsp; =
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0=
-1&nbsp; 80&nbsp;&nbsp; Message-Authenticator<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp; 81&nbsp;&nbsp; Tunnel-Private-Group-ID [Note 5]<BR>&nb=
sp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 82&nbsp;&nbsp; Tunnel-Assignmen=
t-ID [Note 5]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 83&nbsp;&nb=
sp; Tunnel-Preference [Note 5]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;=
 85&nbsp;&nbsp; Acct-Interim-Interval [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&n=
bsp;&nbsp;&nbsp; 87&nbsp;&nbsp; NAS-Port-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0&nbsp;&nbsp;&nbsp; 88&nbsp;&nbsp; Framed-Pool [Note 6]<BR>&nbsp;&nbsp; =
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0&nbsp;&nbsp;&nbsp; 89&nbsp;&nbsp; Chargeable-User-Identity [Note =
1]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 90&nbsp;&nbsp; Tunnel-=
Client-Auth-ID [Note 5]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 9=
1&nbsp;&nbsp; Tunnel-Server-Auth-ID [Note 5]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbs=
p;&nbsp;&nbsp; 92&nbsp;&nbsp; NAS-Filter-Rule [Note 3]<BR>&nbsp;&nbsp; 0&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 94&nbsp;&nbsp; Originating-Line-Info<BR>=
&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 95&nbsp;&nbsp; NAS-IPv6-Address [=
Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 96&nbsp;&nbsp; Framed-=
Interface-Id [Note 6]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 97&=
nbsp;&nbsp; Framed-IPv6-Prefix [Note 6]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbs=
p;&nbsp;&nbsp; 98&nbsp;&nbsp; Login-IPv6-Host [Note 3]<BR>&nbsp;&nbsp; 0+&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp; 99&nbsp;&nbsp; Framed-IPv6-Route [Note 3]<BR>=
&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; 100&nbsp;&nbsp; Framed-IPv6-Pool [Note =
6]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp; 101&nbsp;&nbsp; Error-Cause<=
BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; 123&nbsp;&nbsp; Delegated-IPv6-=
Prefix [Note 6]<BR>&nbsp;&nbsp; Request&nbsp;&nbsp; ACK&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; NAK&nbsp;&nbsp; #&nbsp;&nbsp; Attribute<BR><BR>&nbsp;&nbsp; Disc=
onnect Messages<BR><BR>&nbsp;&nbsp; Request&nbsp;&nbsp; ACK&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; NAK&nbsp;&nbsp; #&nbsp;&nbsp; Attribute<BR>&nbsp;&nbsp; 0-1&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; User-Name [Note 1]<BR>&nbsp;&n=
bsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp; NAS-IP-Address [Note =
1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp; NAS-Por=
t [Note 1]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 6&n=
bsp;&nbsp; Service-Type<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nb=
sp;&nbsp; 8&nbsp;&nbsp; Framed-IP-Address [Note 6]<BR>&nbsp;&nbsp; 0+&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; 0&nbsp;&nbsp;&nbsp; 18&nbsp;&nbsp; Reply-Message [Note 2]<BR>&nbsp;&n=
bsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 24&nbsp;&nbsp; State<BR>&nbsp;&=
nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 25&nbsp;&nbsp; Class [Note 4]<BR>&n=
bsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 26&nbsp;&nbsp; Vendor-Specific=
<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 30&nbsp;&nbsp; Called-Station=
-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 31&nbsp;&nbsp; Ca=
lling-Station-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 32&n=
bsp;&nbsp; NAS-Identifier [Note 1]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp; =
33&nbsp;&nbsp; Proxy-State<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 44&=
nbsp;&nbsp; Acct-Session-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 49&=
nbsp;&nbsp; Acct-Terminate-Cause<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbs=
p; 50&nbsp;&nbsp; Acct-Multi-Session-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp; 5=
5&nbsp;&nbsp; Event-Timestamp<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nb=
sp;&nbsp; 61&nbsp;&nbsp; NAS-Port-Type<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nb=
sp; 79&nbsp;&nbsp; EAP-Message [Note 2]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp; 80&nbsp;&n=
bsp; Message-Authenticator<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 87&=
nbsp;&nbsp; NAS-Port-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbs=
p; 89&nbsp;&nbsp; Chargeable-User-Identity [Note 1]<BR>&nbsp;&nbsp; 0-1&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 0&nbsp;&nbsp;&nbsp; 95&nbsp;&nbsp; NAS-IPv6-Address [Note 1]<BR>&nbsp;&nb=
sp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 96&nbsp;&nbsp; Framed-Interface-=
Id [Note 6]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 97&nbsp;=
&nbsp; Framed-IPv6-Prefix [Note 6]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbs=
p;&nbsp; 100&nbsp;&nbsp; Framed-IPv6-Pool [Note 6]<BR>&nbsp;&nbsp; 0&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 0+&nbsp; 101&nbsp;&nbsp; Error-Cause<BR>&nbsp;&nbsp; Request&nbs=
p;&nbsp; ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAK&nbsp;&nbsp; #&nbsp;&nbsp; At=
tribute<BR><BR>&nbsp;&nbsp; The following table defines the meaning of the =
above table entries.<BR><BR>0&nbsp;&nbsp;&nbsp;&nbsp; This attribute MUST N=
OT be present in packet.<BR>0+&nbsp;&nbsp;&nbsp; Zero or more instances of =
this attribute MAY be present in packet.<BR>0-1&nbsp;&nbsp; Zero or one ins=
tance of this attribute MAY be present in packet.<BR>1&nbsp;&nbsp;&nbsp;&nb=
sp; Exactly one instance of this attribute MUST be present in packet.<BR><B=
R>&nbsp;&nbsp; [Note 1] Where NAS or session identification attributes are =
included<BR>&nbsp;&nbsp; in Disconnect-Request or CoA-Request packets, they=
 are used for<BR>&nbsp;&nbsp; identification purposes only.&nbsp; These att=
ributes MUST NOT be used for<BR>&nbsp;&nbsp; purposes other than identifica=
tion (e.g. within CoA-Request packets<BR>&nbsp;&nbsp; to request authorizat=
ion changes).<BR><BR>&nbsp;&nbsp; [Note 2] The Reply-Message Attribute is u=
sed to present a displayable<BR>&nbsp;&nbsp; message to the user.&nbsp; The=
 message is only displayed as a result of a<BR>&nbsp;&nbsp; successful Disc=
onnect-Request or CoA-Request (where a Disconnect-ACK<BR>&nbsp;&nbsp; or Co=
A-ACK is subsequently sent).&nbsp; Where EAP is used for<BR>&nbsp;&nbsp; au=
thentication, an EAP-Message/Notification-Request Attribute is sent<BR>&nbs=
p;&nbsp; instead, and Disconnect-ACK or CoA-ACK packets contain an EAP-<BR>=
&nbsp;&nbsp; Message/Notification-Response Attribute.<BR><BR>&nbsp;&nbsp; [=
Note 3] When included within a CoA-Request, these attributes<BR>&nbsp;&nbsp=
; represent an authorization change request.&nbsp; When one of these<BR>&nb=
sp;&nbsp; attributes is omitted from a CoA-Request, the NAS assumes that th=
e<BR>&nbsp;&nbsp; attribute value is to remain unchanged.&nbsp; Attributes =
included in a<BR>&nbsp;&nbsp; CoA-Request replace all existing value(s) of =
the same attribute(s).<BR><BR>&nbsp;&nbsp; [Note 4] When included within a =
successful Disconnect-Request (where<BR>&nbsp;&nbsp; a Disconnect-ACK is su=
bsequently sent), the Class Attribute SHOULD be<BR>&nbsp;&nbsp; sent unmodi=
fied by the client to the accounting server in the<BR>&nbsp;&nbsp; Accounti=
ng Stop packet.&nbsp; If the Disconnect-Request is unsuccessful,<BR>&nbsp;&=
nbsp; then the Class Attribute is not processed.<BR><BR>&nbsp;&nbsp; [Note =
5] When included within a CoA-Request, these attributes<BR>&nbsp;&nbsp; rep=
resent an authorization change request.&nbsp; Where tunnel attribute(s)<BR>=
&nbsp;&nbsp; are included within a successful CoA-Request, all existing tun=
nel<BR>&nbsp;&nbsp; attributes are removed and replaced by the new attribut=
e(s).<BR><BR>&nbsp;&nbsp; [Note 6] Where included within a CoA-Request, the=
se attributes<BR>&nbsp;&nbsp; represent a renumbering request.&nbsp; Since =
these attributes are not used<BR>&nbsp;&nbsp; for session identification, t=
hey MUST NOT be included within a<BR>&nbsp;&nbsp; Disconnect-Request.&nbsp;=
 Note that renumbering may not be possible in all<BR>&nbsp;&nbsp; situation=
s.&nbsp; For example, in order to change an IP address on receipt<BR>&nbsp;=
&nbsp; of a changed&nbsp; Framed-IP-Address address, IPCP re-negotiation co=
uld be<BR>&nbsp;&nbsp; required, which is not supported by all PPP implemen=
tations.<BR>
&nbsp;<BR>
Appendix A - Changes from RFC 3576<BR><BR>&nbsp;&nbsp; This Appendix lists =
the major changes between [RFC3576] and this<BR>&nbsp;&nbsp; document.&nbsp=
; Minor changes, including style, grammar, spelling, and<BR>&nbsp;&nbsp; ed=
itorial changes are not mentioned here.<BR><BR>&nbsp;&nbsp; o Added require=
ment for duplicate detection on the RADIUS client<BR>&nbsp;&nbsp; (Section =
2.3).<BR><BR>&nbsp;&nbsp; o Added Chargeable-User-Identity as a session ide=
ntification<BR>&nbsp;&nbsp; attribute.&nbsp; Removed Framed-IP-Address, Fra=
med-IPv6-Prefix, Framed-<BR>&nbsp;&nbsp; Interface-Id and NAS-Port-Type att=
ributes as session identification<BR>&nbsp;&nbsp; attributes (Section 3).<B=
R><BR>&nbsp;&nbsp; o Added details relating to handling of the Proxy-State =
Attribute<BR>&nbsp;&nbsp; (Section 3.1).<BR><BR>&nbsp;&nbsp; o Added statem=
ent that support for "Authorize Only" Service-Type is<BR>&nbsp;&nbsp; optio=
nal (Section 3.2).<BR><BR>&nbsp;&nbsp; o Added requirements for inclusion o=
f the State Attribute in CoA-<BR>&nbsp;&nbsp; Request packets with a Servic=
e-Type of "Authorize Only" (Section<BR>&nbsp;&nbsp; 3.3).<BR><BR>&nbsp;&nbs=
p; o Added clarification on the calculation of the Message-Authenticator<BR=
>&nbsp;&nbsp; Attribute (Section 3.4).<BR><BR>&nbsp;&nbsp; o An additional =
Error-Cause Attribute value (407) is allocated for<BR>&nbsp;&nbsp; Invalid =
Attribute Value (Sections 3.5, 4).<BR><BR>&nbsp;&nbsp; o Updated CoA-Reques=
t Attribute Table to include Filter-Rule,<BR>&nbsp;&nbsp; Delegated-IPv6-Pr=
efix, Egress-VLANID, Ingress-Filters, Egress-VLAN-<BR>&nbsp;&nbsp; Name and=
 User-Priority attributes (Section 3.6).<BR><BR>&nbsp;&nbsp; o Added the Ch=
argeable-User-Identity Attribute to both the CoA-<BR>&nbsp;&nbsp; Request a=
nd Disconnect-Request Attribute table (Section 3.6).<BR><BR>&nbsp;&nbsp; o =
Added note on the use of the CoA-Request for renumbering (Section<BR>&nbsp;=
&nbsp; 3.6).<BR><BR>&nbsp;&nbsp; o Use of Service-Type Attribute within a D=
isconnect-Request is<BR>&nbsp;&nbsp; prohibited (Sections 3.2, 3.6, 4).<BR>=
<BR>&nbsp;&nbsp; o Added Diameter Considerations (Section 4).<BR><BR>&nbsp;=
&nbsp; o Changed the text to indicate that the Event-Timestamp Attribute<BR=
>&nbsp;&nbsp; should not be recalculated on retransmission.&nbsp; The impli=
cations for<BR>&nbsp;&nbsp; replay and duplicate detection are discussed (S=
ection 6.4).<BR><BR><BR></body>
</html>=

--_620ce6a7-56f2-442e-8219-cf050028ab68_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 23 May 2007 19:51:13 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-05.txt 
Date: Wed, 23 May 2007 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: M. Chiba, et al.
	Filename	: draft-ietf-radext-rfc3576bis-05.txt
	Pages		: 34
	Date		: 2007-5-23
	
This document describes a currently deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, allowing
   dynamic changes to a user session, as implemented by network access
   server products.  This includes support for disconnecting users and
   changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-rfc3576bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 22:00:53 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 22 May 2007 15:00:29 -0700

--_8078362c-927b-4f13-8362-7639f3c405d6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Here is the proposed new text of Sections 3, 3.1, 3.2 and 3.5 as well as Ap=
pendix A:
=20
"3.  Attributes   In Disconnect-Request and CoA-Request packets, certain at=
tributes are   used to uniquely identify the NAS as well as a user session =
on the   NAS.  All NAS identification attributes included in a Request pack=
et   MUST match in order for a Disconnect-Request or CoA-Request to be   su=
ccessful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.   For sessi=
on identification attributes, the User-Name and Acct-   Session-Id Attribut=
es, if included, MUST match in order for a   Disconnect-Request or CoA-Requ=
est to be successful; other session   identification attributes SHOULD matc=
h.  Where a mismatch of session   identification attributes is detected, a =
Disconnect-NAK or CoA-NAK   SHOULD  be sent.   The ability to use NAS or se=
ssion identification attributes to map to   unique/multiple sessions is bey=
ond the scope of this document.   Identification attributes include NAS and=
 session identification   attributes, as described below.     NAS identific=
ation attributes     Attribute             #    Reference  Description     =
---------            ---   ---------  -----------     NAS-IP-Address       =
 4    [RFC2865]  The IPv4 address of the NAS.     NAS-Identifier       32  =
  [RFC2865]  String identifying the NAS.     NAS-IPv6-Address     95    [RF=
C3162]  The IPv6 address of the NAS.     Session identification attributes =
    Attribute              #   Reference  Description     ---------        =
     ---  ---------  -----------     User-Name              1   [RFC2865]  =
The name of the user                                           associated w=
ith the session.     NAS-Port               5   [RFC2865]  The port on whic=
h the                                           session is terminated.     =
Attribute              #   Reference  Description     ---------            =
 ---  ---------  -----------     Called-Station-Id     30   [RFC2865]  The =
link address to which                                           the session=
 is connected.     Calling-Station-Id    31   [RFC2865]  The link address f=
rom which                                           the session is connecte=
d.     Acct-Session-Id       44   [RFC2866]  The identifier uniquely       =
                                    identifying the session                =
                           on the NAS.     Acct-Multi-Session-Id 50   [RFC2=
866]  The identifier uniquely                                           ide=
ntifying related sessions.     NAS-Port-Id           87   [RFC2869]  String=
 identifying the port                                           where the s=
ession is.     Chargeable-User-      89   [RFC4372]  The CUI associated wit=
h the     Identity                              session.  Needed where a   =
                                        privacy NAI is used, because       =
                                    the User-Name may not be               =
                            unique (e.g. "anonymous").   To address securit=
y concerns described in Section 6.1, either the   User-Name or Chargeable-U=
ser-Identity attribute SHOULD be present in   Disconnect-Request and CoA-Re=
quest packets.   Where a Diameter client utilizes the same Session-Id for b=
oth   authorization and accounting, inclusion of an Acct-Session-Id   Attri=
bute in a Disconnect-Request or CoA-Request can assist with   Diameter/RADI=
US translation, since Diameter RAR and ASR commands   include a Session-Id =
AVP.  An Acct-Session-Id attribute SHOULD be   included in Disconnect-Reque=
st and CoA-Request packets.   Where the Acct-Session-Id or Acct-Multi-Sessi=
on-Id attributes are not   present in a CoA-Request or Disconnect-Request, =
it is possible that   the User-Name or Chargeable-User-Identity attributes =
will not be   sufficient to uniquely identify the session (e.g. if the same=
 user   has multiple sessions on the NAS, or the privacy NAI is used).  As =
a   result, the Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-   =
Port-Id attributes MAY be used as additional session identification.   To a=
ddress security concerns described in Section 6.2, one or more of   the NAS=
-IP-Address or NAS-IPv6-Address Attributes SHOULD be present   in Disconnec=
t-Request and CoA-Request packets; the NAS-Identifier   Attribute MAY be pr=
esent.   If one or more authorization changes specified in a CoA-Request   =
cannot be carried out, or if one or more attributes or attribute-   values =
is unsupported, a CoA-NAK MUST be sent.  Similarly, if there   are one or m=
ore unsupported attributes or attribute values in a   Disconnect-Request, a=
 Disconnect-NAK MUST be sent.
   A Disconnect-Request MUST contain only NAS and session identification   =
attributes (see Section 3).  If other attributes are included in a   Discon=
nect-Request, implementations MUST send a Disconnect-NAK; an   Error-Cause =
Attribute with value "Unsupported Attribute" MAY be   included.3.1.  Author=
ize Only   Support for a CoA-Request including a Service-Type Attribute wit=
h   value "Authorize Only" is OPTIONAL on the NAS and RADIUS server.  A   S=
ervice-Type Attribute MUST NOT be included within a Disconnect-   Request. =
  A NAS MUST respond to a CoA-Request including a Service-Type   Attribute =
with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST   NOT be sent.  =
If the NAS does not support a Service-Type value of   "Authorize Only" then=
 it MUST respond with a CoA-NAK; an Error-Cause   value of 405 (Unsupported=
 Service) SHOULD be included.   A CoA-Request containing a Service-Type Att=
ribute with value   "Authorize Only" MUST in addition contain only NAS or s=
ession   identification attributes, as well as a State Attribute.  If other=
   attributes are included in such a CoA-Request, a CoA-NAK MUST be   sent;=
 an Error-Cause Attribute with value 401 (Unsupported Attribute)   SHOULD b=
e included.   If a CoA-Request packet including a Service-Type value of "Au=
thorize   Only" is successfully processed, the NAS MUST respond with a CoA-=
NAK   containing a Service-Type Attribute with value "Authorize Only", and =
  an Error-Cause Attribute with value 507 (Request Initiated).  The NAS   t=
hen MUST send an Access-Request to the RADIUS server including a   Service-=
Type Attribute with value "Authorize Only".  This Access-   Request SHOULD =
contain the NAS identification attributes from the   CoA-Request, as well a=
s the session identification attributes from   the CoA-Request legal for in=
clusion in an Access-Request as specified   in [RFC2865], [RFC2868], [RFC28=
69] and [RFC3162].  As noted in   [RFC2869] Section 5.19, a Message-Authent=
icator attribute SHOULD be   included in an Access-Request that does not co=
ntain a User-Password,   CHAP-Password, ARAP-Password or EAP-Message Attrib=
ute.  The RADIUS   server then will respond to the Access-Request with an A=
ccess-Accept   to (re-)authorize the session or an Access-Reject to refuse =
to   (re-)authorize it.3.2.  State   The State Attribute is available to be=
 sent by the RADIUS server to   the NAS in a CoA-Request packet and MUST be=
 sent unmodified from the   NAS to the RADIUS server in a subsequent ACK or=
 NAK packet.   [RFC2865] Section 5.44 states:      An Access-Request MUST c=
ontain either a User-Password or a CHAP-      Password or State.  An Access=
-Request MUST NOT contain both a      User-Password and a CHAP-Password.  I=
f future extensions allow      other kinds of authentication information to=
 be conveyed, the      attribute for that can be used in an Access-Request =
instead of      User-Password or CHAP-Password.   In order to satisfy the r=
equirements of [RFC2865] Section 5.44, an   Access-Request with Service-Typ=
e=3D"Authorize-Only" MUST contain a   State attribute.   In order to provid=
e a State attribute to the NAS, a server sending a   CoA-Request with a Ser=
vice-Type value of "Authorize-Only" MUST   include a State Attribute, and t=
he NAS MUST send the State Attribute   unmodified to the RADIUS server in t=
he resulting Access-Request, if   any.  A NAS receiving a CoA-Request conta=
ining a Service-Type value   of "Authorize-Only" but lacking a State attrib=
ute MUST send a CoA-NAK   and SHOULD include an Error-Cause attribute with =
value 402 (Missing   Attribute).   The State Attribute is also available to=
 be sent by the RADIUS server   to the NAS in a CoA-Request that also inclu=
des a Termination-Action   Attribute with the value of RADIUS-Request.  If =
the client performs   the Termination-Action by sending a new Access-Reques=
t upon   termination of the current session, it MUST include the State   At=
tribute unchanged in that Access-Request.  In either usage, the   client MU=
ST NOT interpret the Attribute locally.  A CoA-Request   packet must have o=
nly zero or one State Attribute.  Usage of the   State Attribute is impleme=
ntation dependent.
3.5.  Table of Attributes   The following table provides a guide to which a=
ttributes may be found   in which packets, and in what quantity.   Change-o=
f-Authorization Messages   Request   ACK      NAK   #   Attribute   0-1    =
   0        0     1   User-Name [Note 1]   0-1       0        0     4   NAS=
-IP-Address [Note 1]   0-1       0        0     5   NAS-Port [Note 1]   0-1=
       0        0-1   6   Service-Type   0-1       0        0     7   Frame=
d-Protocol [Note 3]   0-1       0        0     8   Framed-IP-Address [Note =
6]   0-1       0        0     9   Framed-IP-Netmask [Note 6]   0-1       0 =
       0    10   Framed-Routing [Note 3]   0+        0        0    11   Fil=
ter-ID [Note 3]   0-1       0        0    12   Framed-MTU [Note 3]   0+    =
    0        0    13   Framed-Compression [Note 3]   0+        0        0  =
  14   Login-IP-Host [Note 3]   0-1       0        0    15   Login-Service =
[Note 3]   0-1       0        0    16   Login-TCP-Port [Note 3]   0+       =
 0        0    18   Reply-Message [Note 2]   0-1       0        0    19   C=
allback-Number [Note 3]   0-1       0        0    20   Callback-Id [Note 3]=
   0+        0        0    22   Framed-Route [Note 3]   0-1       0        =
0    23   Framed-IPX-Network [Note 6]   0-1       0-1      0-1  24   State =
  0+        0        0    25   Class [Note 3]   0+        0        0    26 =
  Vendor-Specific [Note 3]   0-1       0        0    27   Session-Timeout [=
Note 3]   0-1       0        0    28   Idle-Timeout [Note 3]   0-1       0 =
       0    29   Termination-Action [Note 3]   0-1       0        0    30  =
 Called-Station-Id [Note 1]   0-1       0        0    31   Calling-Station-=
Id [Note 1]   0-1       0        0    32   NAS-Identifier [Note 1]   Reques=
t   ACK      NAK   #   Attribute   Request   ACK      NAK   #   Attribute  =
 0+        0+       0+   33   Proxy-State   0-1       0        0    34   Lo=
gin-LAT-Service [Note 3]   0-1       0        0    35   Login-LAT-Node [Not=
e 3]   0-1       0        0    36   Login-LAT-Group [Note 3]   0-1       0 =
       0    37   Framed-AppleTalk-Link [Note 3]   0+        0        0    3=
8   Framed-AppleTalk-Network [Note 3]   0-1       0        0    39   Framed=
-AppleTalk-Zone [Note 3]   0-1       0        0    44   Acct-Session-Id [No=
te 1]   0-1       0        0    50   Acct-Multi-Session-Id [Note 1]   0-1  =
     0-1      0-1  55   Event-Timestamp   0+        0        0    56   Egre=
ss-VLANID [Note 3]   0-1       0        0    57   Ingress-Filters [Note 3] =
  0+        0        0    58   Egress-VLAN-Name [Note 3]   0-1       0     =
   0    59   User-Priority-Table [Note 3]   0-1       0        0    61   NA=
S-Port-Type [Note 3]   0-1       0        0    62   Port-Limit [Note 3]   0=
-1       0        0    63   Login-LAT-Port [Note 3]   0+        0        0 =
   64   Tunnel-Type [Note 5]   0+        0        0    65   Tunnel-Medium-T=
ype [Note 5]   0+        0        0    66   Tunnel-Client-Endpoint [Note 5]=
   0+        0        0    67   Tunnel-Server-Endpoint [Note 5]   0+       =
 0        0    69   Tunnel-Password [Note 5]   0-1       0        0    71  =
 ARAP-Features [Note 3]   0-1       0        0    72   ARAP-Zone-Access [No=
te 3]   0+        0        0    78   Configuration-Token [Note 3]   0+     =
   0-1      0    79   EAP-Message [Note 2]   0-1       0-1      0-1  80   M=
essage-Authenticator   0+        0        0    81   Tunnel-Private-Group-ID=
 [Note 5]   0+        0        0    82   Tunnel-Assignment-ID [Note 5]   0+=
        0        0    83   Tunnel-Preference [Note 5]   0-1       0        =
0    85   Acct-Interim-Interval [Note 3]   0-1       0        0    87   NAS=
-Port-Id [Note 1]   0-1       0        0    88   Framed-Pool [Note 6]   0-1=
       0        0    89   Chargeable-User-Identity [Note 1]   0+        0  =
      0    90   Tunnel-Client-Auth-ID [Note 5]   0+        0        0    91=
   Tunnel-Server-Auth-ID [Note 5]   0-1       0        0    92   NAS-Filter=
-Rule [Note 3]   0         0        0    94   Originating-Line-Info   0-1  =
     0        0    95   NAS-IPv6-Address [Note 1]   0-1       0        0   =
 96   Framed-Interface-Id [Note 6]   0+        0        0    97   Framed-IP=
v6-Prefix [Note 6]   0+        0        0    98   Login-IPv6-Host [Note 3] =
  0+        0        0    99   Framed-IPv6-Route [Note 3]   0-1       0    =
    0   100   Framed-IPv6-Pool [Note 6]   0         0        0+  101   Erro=
r-Cause   0+        0        0   123   Delegated-IPv6-Prefix [Note 6]   Req=
uest   ACK      NAK   #   Attribute   Disconnect Messages   Request   ACK  =
    NAK   #   Attribute   0-1       0        0     1   User-Name [Note 1]  =
 0-1       0        0     4   NAS-IP-Address [Note 1]   0-1       0        =
0     5   NAS-Port [Note 1]   0         0        0     6   Service-Type   0=
         0        0     8   Framed-IP-Address [Note 6]   0+        0       =
 0    18   Reply-Message [Note 2]   0         0        0    24   State   0+=
        0        0    25   Class [Note 4]   0+        0        0    26   Ve=
ndor-Specific   0-1       0        0    30   Called-Station-Id [Note 1]   0=
-1       0        0    31   Calling-Station-Id [Note 1]   0-1       0      =
  0    32   NAS-Identifier [Note 1]   0+        0+       0+   33   Proxy-St=
ate   0-1       0        0    44   Acct-Session-Id [Note 1]   0-1       0-1=
      0    49   Acct-Terminate-Cause   0-1       0        0    50   Acct-Mu=
lti-Session-Id [Note 1]   0-1       0-1      0-1  55   Event-Timestamp   0 =
        0        0    61   NAS-Port-Type   0+        0-1      0    79   EAP=
-Message [Note 2]   0-1       0-1      0-1  80   Message-Authenticator   0-=
1       0        0    87   NAS-Port-Id [Note 1]   0-1       0        0    8=
9   Chargeable-User-Identity [Note 1]   0-1       0        0    95   NAS-IP=
v6-Address [Note 1]   0         0        0    96   Framed-Interface-Id [Not=
e 6]   0         0        0    97   Framed-IPv6-Prefix [Note 6]   0        =
 0        0   100   Framed-IPv6-Pool [Note 6]   0         0        0+  101 =
  Error-Cause   Request   ACK      NAK   #   Attribute   The following tabl=
e defines the meaning of the above table entries.0     This attribute MUST =
NOT be present in packet.0+    Zero or more instances of this attribute MAY=
 be present in packet.0-1   Zero or one instance of this attribute MAY be p=
resent in packet.1     Exactly one instance of this attribute MUST be prese=
nt in packet.   [Note 1] Where NAS or session identification attributes are=
 included   in Disconnect-Request or CoA-Request packets, they are used for=
   identification purposes only.  These attributes MUST NOT be used for   p=
urposes other than identification (e.g. within CoA-Request packets   to req=
uest authorization changes).   [Note 2] The Reply-Message Attribute is used=
 to present a displayable   message to the user.  The message is only displ=
ayed as a result of a   successful Disconnect-Request or CoA-Request (where=
 a Disconnect-ACK   or CoA-ACK is subsequently sent).  Where EAP is used fo=
r   authentication, an EAP-Message/Notification-Request Attribute is sent  =
 instead, and Disconnect-ACK or CoA-ACK packets contain an EAP-   Message/N=
otification-Response Attribute.   [Note 3] When included within a CoA-Reque=
st, these attributes   represent an authorization change request.  When one=
 of these   attributes is omitted from a CoA-Request, the NAS assumes that =
the   attribute value is to remain unchanged.  Attributes included in a   C=
oA-Request replace all existing value(s) of the same attribute(s).   [Note =
4] When included within a successful Disconnect-Request (where   a Disconne=
ct-ACK is subsequently sent), the Class Attribute SHOULD be   sent unmodifi=
ed by the client to the accounting server in the   Accounting Stop packet. =
 If the Disconnect-Request is unsuccessful,   then the Class Attribute is n=
ot processed.   [Note 5] When included within a CoA-Request, these attribut=
es   represent an authorization change request.  Where tunnel attribute(s) =
  are included within a successful CoA-Request, all existing tunnel   attri=
butes are removed and replaced by the new attribute(s).   [Note 6] Where in=
cluded within a CoA-Request, these attributes   represent a renumbering req=
uest.  Since these attributes are not used   for session identification, th=
ey MUST NOT be included within a   Disconnect-Request.  Note that renumberi=
ng may not be possible in all   situations.  For example, in order to chang=
e an IP address on receipt   of a changed  Framed-IP-Address address, IPCP =
re-negotiation could be   required, which is not supported by all PPP imple=
mentations.
=20
Appendix A - Changes from RFC 3576     This Appendix lists the major change=
s between [RFC3576] and this    document.  Minor changes, including style, =
grammar, spelling, and    editorial changes are not mentioned here.     o A=
dded details relating to handling of the Proxy-State Attribute.    Added re=
quirement for duplicate detection on the RADIUS client    (Section 2.3).   =
  o Added Chargeable-User-Identity as a session identification    attribute=
.  Removed Framed-IP-Address, Framed-IPv6-Prefix, Framed-    Interface-Id a=
nd NAS-Port-Type attributes as session identification    attributes (Sectio=
n 3).     o Added requirements for inclusion of the State Attribute in CoA-=
    Request packets with a Service-Type of "Authorize Only" (Section    3.2=
).     o Added clarification on the calculation of the Message-Authenticato=
r    Attribute (Section 3.3).     o Added statement that support for "Autho=
rize Only" Service-Type is    optional (Section 3.5).     o Updated CoA-Req=
uest Attribute Table to include Filter-Rule,    Delegated-IPv6-Prefix, Egre=
ss-VLANID, Ingress-Filters, Egress-VLAN-    Name and User-Priority attribut=
es (Section 3.5).     o Added the Chargeable-User-Identity Attribute to bot=
h the CoA-    Request and Disconnect-Request Attribute table (Section 3.5).=
     o Added note on the use of the CoA-Request for renumbering (Section   =
 3.5).     o Use of Service-Type and Error-Cause attributes within a Discon=
nect-    Request is prohibited (Sections 3.5).     o Added Diameter Conside=
rations (Section 4).     o Changed the text to indicate that the Event-Time=
stamp Attribute    should not be recalculated on retransmission.  The impli=
cations for    replay and duplicate detection are discussed (Section 6.4)."=

--_8078362c-927b-4f13-8362-7639f3c405d6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<FONT face=3D"Courier New" size=3D2>Here is the proposed new text of Sectio=
ns 3, 3.1, 3.2 and 3.5 as well as Appendix A:</FONT><BR>
<FONT face=3D"Courier New" size=3D2></FONT>&nbsp;<BR>
<FONT face=3D"Courier New" size=3D2>"3.&nbsp; Attributes<BR><BR>&nbsp;&nbsp=
; In Disconnect-Request and CoA-Request packets, certain attributes are<BR>=
&nbsp;&nbsp; used to uniquely identify the NAS as well as a user session on=
 the<BR>&nbsp;&nbsp; NAS.&nbsp; All NAS identification attributes included =
in a Request packet<BR>&nbsp;&nbsp; MUST match in order for a Disconnect-Re=
quest or CoA-Request to be<BR>&nbsp;&nbsp; successful; otherwise a Disconne=
ct-NAK or CoA-NAK SHOULD be sent.<BR>&nbsp;&nbsp; For session identificatio=
n attributes, the User-Name and Acct-<BR>&nbsp;&nbsp; Session-Id Attributes=
, if included, MUST match in order for a<BR>&nbsp;&nbsp; Disconnect-Request=
 or CoA-Request to be successful; other session<BR>&nbsp;&nbsp; identificat=
ion attributes SHOULD match.&nbsp; Where a mismatch of session<BR>&nbsp;&nb=
sp; identification attributes is detected, a Disconnect-NAK or CoA-NAK<BR>&=
nbsp;&nbsp; SHOULD&nbsp; be sent.<BR><BR>&nbsp;&nbsp; The ability to use NA=
S or session identification attributes to map to<BR>&nbsp;&nbsp; unique/mul=
tiple sessions is beyond the scope of this document.<BR>&nbsp;&nbsp; Identi=
fication attributes include NAS and session identification<BR>&nbsp;&nbsp; =
attributes, as described below.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS identif=
ication attributes<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; Attribute&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbs=
p; Reference&nbsp; Description<BR>&nbsp;&nbsp;&nbsp;&nbsp; ---------&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---&nbsp;&nbsp;=
 ---------&nbsp; -----------<BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS-IP-Address&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp; [RFC2865]&nbsp; =
The IPv4 address of the NAS.<BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS-Identifier&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32&nbsp;&nbsp;&nbsp; [RFC2865]&nbsp; Strin=
g identifying the NAS.<BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS-IPv6-Address&nbsp;&n=
bsp;&nbsp;&nbsp; 95&nbsp;&nbsp;&nbsp; [RFC3162]&nbsp; The IPv6 address of t=
he NAS.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; Session identification attributes<B=
R><BR>&nbsp;&nbsp;&nbsp;&nbsp; Attribute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp; Reference&nbsp; D=
escription<BR>&nbsp;&nbsp;&nbsp;&nbsp; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---&nbsp; ---------&nbsp; ---=
--------<BR>&nbsp;&nbsp;&nbsp;&nbsp; User-Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; [RFC2865]&n=
bsp; The name of the user<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; associated with th=
e session.<BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS-Port&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp; [RFC=
2865]&nbsp; The port on which the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session is=
 terminated.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; Attribute&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp; Ref=
erence&nbsp; Description<BR>&nbsp;&nbsp;&nbsp;&nbsp; ---------&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---&nbsp; -----=
----&nbsp; -----------<BR>&nbsp;&nbsp;&nbsp;&nbsp; Called-Station-Id&nbsp;&=
nbsp;&nbsp;&nbsp; 30&nbsp;&nbsp; [RFC2865]&nbsp; The link address to which<=
BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the session is connected.<BR>&nbsp;&nbsp;&nb=
sp;&nbsp; Calling-Station-Id&nbsp;&nbsp;&nbsp; 31&nbsp;&nbsp; [RFC2865]&nbs=
p; The link address from which<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the session i=
s connected.<BR>&nbsp;&nbsp;&nbsp;&nbsp; Acct-Session-Id&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 44&nbsp;&nbsp; [RFC2866]&nbsp; The identifier uniquely<BR=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; identifying the session<BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; on the NAS.<BR>&nbsp;&nbsp;&nbsp;&nbsp; Acct-Multi-Session-Id 50&n=
bsp;&nbsp; [RFC2866]&nbsp; The identifier uniquely<BR>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; identifying related sessions.<BR>&nbsp;&nbsp;&nbsp;&nbsp; NAS-Port-I=
d&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 87&nbsp;&nbsp=
; [RFC2869]&nbsp; String identifying the port<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; where the session is.<BR>&nbsp;&nbsp;&nbsp;&nbsp; Chargeable-User-&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 89&nbsp;&nbsp; [RFC4372]&nbsp; The CUI associated w=
ith the<BR>&nbsp;&nbsp;&nbsp;&nbsp; Identity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sessio=
n.&nbsp; Needed where a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; privacy NAI is used,=
 because<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the User-Name may not be<BR>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; unique (e.g. "anonymous").<BR><BR>&nbsp;&nbsp; To addr=
ess security concerns described in Section 6.1, either the<BR>&nbsp;&nbsp; =
User-Name or Chargeable-User-Identity attribute SHOULD be present in<BR>&nb=
sp;&nbsp; Disconnect-Request and CoA-Request packets.<BR><BR>&nbsp;&nbsp; W=
here a Diameter client utilizes the same Session-Id for both<BR>&nbsp;&nbsp=
; authorization and accounting, inclusion of an Acct-Session-Id<BR>&nbsp;&n=
bsp; Attribute in a Disconnect-Request or CoA-Request can assist with<BR>&n=
bsp;&nbsp; Diameter/RADIUS translation, since Diameter RAR and ASR commands=
<BR>&nbsp;&nbsp; include a Session-Id AVP.&nbsp; An Acct-Session-Id attribu=
te SHOULD be<BR>&nbsp;&nbsp; included in Disconnect-Request and CoA-Request=
 packets.<BR><BR>&nbsp;&nbsp; Where the Acct-Session-Id or Acct-Multi-Sessi=
on-Id attributes are not<BR>&nbsp;&nbsp; present in a CoA-Request or Discon=
nect-Request, it is possible that<BR>&nbsp;&nbsp; the User-Name or Chargeab=
le-User-Identity attributes will not be<BR>&nbsp;&nbsp; sufficient to uniqu=
ely identify the session (e.g. if the same user<BR>&nbsp;&nbsp; has multipl=
e sessions on the NAS, or the privacy NAI is used).&nbsp; As a<BR>&nbsp;&nb=
sp; result, the Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-<BR=
>&nbsp;&nbsp; Port-Id attributes MAY be used as additional session identifi=
cation.<BR><BR>&nbsp;&nbsp; To address security concerns described in Secti=
on 6.2, one or more of<BR>&nbsp;&nbsp; the NAS-IP-Address or NAS-IPv6-Addre=
ss Attributes SHOULD be present<BR>&nbsp;&nbsp; in Disconnect-Request and C=
oA-Request packets; the NAS-Identifier<BR>&nbsp;&nbsp; Attribute MAY be pre=
sent.<BR><BR>&nbsp;&nbsp; If one or more authorization changes specified in=
 a CoA-Request<BR>&nbsp;&nbsp; cannot be carried out, or if one or more att=
ributes or attribute-<BR>&nbsp;&nbsp; values is unsupported, a CoA-NAK MUST=
 be sent.&nbsp; Similarly, if there<BR>&nbsp;&nbsp; are one or more unsuppo=
rted attributes or attribute values in a<BR>&nbsp;&nbsp; Disconnect-Request=
, a Disconnect-NAK MUST be sent.</FONT><BR>
<FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; A Disconnect-Request MUST =
contain only NAS and session identification<BR>&nbsp;&nbsp; attributes (see=
 Section 3).&nbsp; If other attributes are included in a<BR>&nbsp;&nbsp; Di=
sconnect-Request, implementations MUST send a Disconnect-NAK; an<BR>&nbsp;&=
nbsp; Error-Cause Attribute with value "Unsupported Attribute" MAY be<BR>&n=
bsp;&nbsp; included.<BR><BR>3.1.&nbsp; Authorize Only<BR><BR>&nbsp;&nbsp; S=
upport for a CoA-Request including a Service-Type Attribute with<BR>&nbsp;&=
nbsp; value "Authorize Only" is OPTIONAL on the NAS and RADIUS server.&nbsp=
; A<BR>&nbsp;&nbsp; Service-Type Attribute MUST NOT be included within a Di=
sconnect-<BR>&nbsp;&nbsp; Request.<BR><BR>&nbsp;&nbsp; A NAS MUST respond t=
o a CoA-Request including a Service-Type<BR>&nbsp;&nbsp; Attribute with val=
ue "Authorize Only" with a CoA-NAK; a CoA-ACK MUST<BR>&nbsp;&nbsp; NOT be s=
ent.&nbsp; If the NAS does not support a Service-Type value of<BR>&nbsp;&nb=
sp; "Authorize Only" then it MUST respond with a CoA-NAK; an Error-Cause<BR=
>&nbsp;&nbsp; value of 405 (Unsupported Service) SHOULD be included.<BR><BR=
>&nbsp;&nbsp; A CoA-Request containing a Service-Type Attribute with value<=
BR>&nbsp;&nbsp; "Authorize Only" MUST in addition contain only NAS or sessi=
on<BR>&nbsp;&nbsp; identification attributes, as well as a State Attribute.=
&nbsp; If other<BR>&nbsp;&nbsp; attributes are included in such a CoA-Reque=
st, a CoA-NAK MUST be<BR>&nbsp;&nbsp; sent; an Error-Cause Attribute with v=
alue 401 (Unsupported Attribute)<BR>&nbsp;&nbsp; SHOULD be included.<BR><BR=
>&nbsp;&nbsp; If a CoA-Request packet including a Service-Type value of "Au=
thorize<BR>&nbsp;&nbsp; Only" is successfully processed, the NAS MUST respo=
nd with a CoA-NAK<BR>&nbsp;&nbsp; containing a Service-Type Attribute with =
value "Authorize Only", and<BR>&nbsp;&nbsp; an Error-Cause Attribute with v=
alue 507 (Request Initiated).&nbsp; The NAS<BR>&nbsp;&nbsp; then MUST send =
an Access-Request to the RADIUS server including a<BR>&nbsp;&nbsp; Service-=
Type Attribute with value "Authorize Only".&nbsp; This Access-<BR>&nbsp;&nb=
sp; Request SHOULD contain the NAS identification attributes from the<BR>&n=
bsp;&nbsp; CoA-Request, as well as the session identification attributes fr=
om<BR>&nbsp;&nbsp; the CoA-Request legal for inclusion in an Access-Request=
 as specified<BR>&nbsp;&nbsp; in [RFC2865], [RFC2868], [RFC2869] and [RFC31=
62].&nbsp; As noted in<BR>&nbsp;&nbsp; [RFC2869] Section 5.19, a Message-Au=
thenticator attribute SHOULD be<BR>&nbsp;&nbsp; included in an Access-Reque=
st that does not contain a User-Password,<BR>&nbsp;&nbsp; CHAP-Password, AR=
AP-Password or EAP-Message Attribute.&nbsp; The RADIUS<BR>&nbsp;&nbsp; serv=
er then will respond to the Access-Request with an Access-Accept<BR>&nbsp;&=
nbsp; to (re-)authorize the session or an Access-Reject to refuse to<BR>&nb=
sp;&nbsp; (re-)authorize it.<BR><BR>3.2.&nbsp; State<BR><BR>&nbsp;&nbsp; Th=
e State Attribute is available to be sent by the RADIUS server to<BR>&nbsp;=
&nbsp; the NAS in a CoA-Request packet and MUST be sent unmodified from the=
<BR>&nbsp;&nbsp; NAS to the RADIUS server in a subsequent ACK or NAK packet=
.<BR>&nbsp;&nbsp; [RFC2865] Section 5.44 states:<BR><BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; An Access-Request MUST contain either a User-Password or a CHAP=
-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Password or State.&nbsp; An Access-Requ=
est MUST NOT contain both a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password=
 and a CHAP-Password.&nbsp; If future extensions allow<BR>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; other kinds of authentication information to be conveyed, the=
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute for that can be used in an Acc=
ess-Request instead of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password or C=
HAP-Password.<BR><BR>&nbsp;&nbsp; In order to satisfy the requirements of [=
RFC2865] Section 5.44, an<BR>&nbsp;&nbsp; Access-Request with Service-Type=
=3D"Authorize-Only" MUST contain a<BR>&nbsp;&nbsp; State attribute.<BR><BR>=
&nbsp;&nbsp; In order to provide a State attribute to the NAS, a server sen=
ding a<BR>&nbsp;&nbsp; CoA-Request with a Service-Type value of "Authorize-=
Only" MUST<BR>&nbsp;&nbsp; include a State Attribute, and the NAS MUST send=
 the State Attribute<BR>&nbsp;&nbsp; unmodified to the RADIUS server in the=
 resulting Access-Request, if<BR>&nbsp;&nbsp; any.&nbsp; A NAS receiving a =
CoA-Request containing a Service-Type value<BR>&nbsp;&nbsp; of "Authorize-O=
nly" but lacking a State attribute MUST send a CoA-NAK<BR>&nbsp;&nbsp; and =
SHOULD include an Error-Cause attribute with value 402 (Missing<BR>&nbsp;&n=
bsp; Attribute).<BR><BR>&nbsp;&nbsp; The State Attribute is also available =
to be sent by the RADIUS server<BR>&nbsp;&nbsp; to the NAS in a CoA-Request=
 that also includes a Termination-Action<BR>&nbsp;&nbsp; Attribute with the=
 value of RADIUS-Request.&nbsp; If the client performs<BR>&nbsp;&nbsp; the =
Termination-Action by sending a new Access-Request upon<BR>&nbsp;&nbsp; ter=
mination of the current session, it MUST include the State<BR>&nbsp;&nbsp; =
Attribute unchanged in that Access-Request.&nbsp; In either usage, the<BR>&=
nbsp;&nbsp; client MUST NOT interpret the Attribute locally.&nbsp; A CoA-Re=
quest<BR>&nbsp;&nbsp; packet must have only zero or one State Attribute.&nb=
sp; Usage of the<BR>&nbsp;&nbsp; State Attribute is implementation dependen=
t.</FONT><BR>
<FONT face=3D"Courier New" size=3D2>3.5.&nbsp; Table of Attributes<BR><BR>&=
nbsp;&nbsp; The following table provides a guide to which attributes may be=
 found<BR>&nbsp;&nbsp; in which packets, and in what quantity.<BR><BR>&nbsp=
;&nbsp; Change-of-Authorization Messages<BR><BR>&nbsp;&nbsp; Request&nbsp;&=
nbsp; ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAK&nbsp;&nbsp; #&nbsp;&nbsp; Attri=
bute<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; User-=
Name [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nb=
sp; NAS-IP-Address [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nb=
sp; 5&nbsp;&nbsp; NAS-Port [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp=
; 6&nbsp;&nbsp; Service-Type<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&n=
bsp; 7&nbsp;&nbsp; Framed-Protocol [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp=
;&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp; Framed-IP-Address [Note 6]<BR>&nbsp;&nbsp=
; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 9&nbsp;&nbsp; Framed-IP-Netmask [Note =
6]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 10&nbsp;&nbsp; Framed-Routi=
ng [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 11&nbsp;&nbsp=
; Filter-ID [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 12&nbsp;&=
nbsp; Framed-MTU [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;=
 13&nbsp;&nbsp; Framed-Compression [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0=
&nbsp;&nbsp;&nbsp; 14&nbsp;&nbsp; Login-IP-Host [Note 3]<BR>&nbsp;&nbsp; 0-=
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; 0&nbsp;&nbsp;&nbsp; 15&nbsp;&nbsp; Login-Service [Note 3]<BR>&nbsp;&=
nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 16&nbsp;&nbsp; Login-TCP-Port [Note 3]<B=
R>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 18&nbsp;&nbsp; Reply-Messa=
ge [Note 2]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 19&nbsp;&nbsp; Cal=
lback-Number [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 20&nbsp;=
&nbsp; Callback-Id [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbs=
p; 22&nbsp;&nbsp; Framed-Route [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nb=
sp;&nbsp; 23&nbsp;&nbsp; Framed-IPX-Network [Note 6]<BR>&nbsp;&nbsp; 0-1&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbs=
p; 24&nbsp;&nbsp; State<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 2=
5&nbsp;&nbsp; Class [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nb=
sp; 26&nbsp;&nbsp; Vendor-Specific [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp=
;&nbsp;&nbsp; 27&nbsp;&nbsp; Session-Timeout [Note 3]<BR>&nbsp;&nbsp; 0-1&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 0&nbsp;&nbsp;&nbsp; 28&nbsp;&nbsp; Idle-Timeout [Note 3]<BR>&nbsp;&nbsp=
; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 29&nbsp;&nbsp; Termination-Action [Note 3]<B=
R>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 30&nbsp;&nbsp; Called-Station-I=
d [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 31&nbsp;&nbsp; Call=
ing-Station-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 32&nbs=
p;&nbsp; NAS-Identifier [Note 1]<BR>&nbsp;&nbsp; Request&nbsp;&nbsp; ACK&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; NAK&nbsp;&nbsp; #&nbsp;&nbsp; Attribute<BR><BR>=
<BR>&nbsp;&nbsp; Request&nbsp;&nbsp; ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAK&=
nbsp;&nbsp; #&nbsp;&nbsp; Attribute<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;=
 33&nbsp;&nbsp; Proxy-State<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 34=
&nbsp;&nbsp; Login-LAT-Service [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nb=
sp;&nbsp; 35&nbsp;&nbsp; Login-LAT-Node [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0=
&nbsp;&nbsp;&nbsp; 36&nbsp;&nbsp; Login-LAT-Group [Note 3]<BR>&nbsp;&nbsp; =
0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0&nbsp;&nbsp;&nbsp; 37&nbsp;&nbsp; Framed-AppleTalk-Link [Note 3]<=
BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 38&nbsp;&nbsp; Framed-App=
leTalk-Network [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 39&nbs=
p;&nbsp; Framed-AppleTalk-Zone [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nb=
sp;&nbsp; 44&nbsp;&nbsp; Acct-Session-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp; 50&nbsp;&nbsp; Acct-Multi-Session-Id [Note 1]<BR>&nbsp;=
&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; 0-1&nbsp; 55&nbsp;&nbsp; Event-Timestamp<BR>&nbsp;&nbsp; 0+&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 0&nbsp;&nbsp;&nbsp; 56&nbsp;&nbsp; Egress-VLANID [Note 3]<BR>&nbsp;&nbsp;=
 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp; 57&nbsp;&nbsp; Ingress-Filters [Note 3]<BR>&n=
bsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 58&nbsp;&nbsp; Egress-VLAN-Nam=
e [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 59&nbsp;&nbsp; User=
-Priority-Table [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 61&nb=
sp;&nbsp; NAS-Port-Type [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbs=
p; 62&nbsp;&nbsp; Port-Limit [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp=
;&nbsp; 63&nbsp;&nbsp; Login-LAT-Port [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 0&nbsp;&nbsp;&nbsp; 64&nbsp;&nbsp; Tunnel-Type [Note 5]<BR>&nbsp;&nbsp; 0=
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 65&nbsp;&nbsp; Tunnel-Medium-Type [Note 5]=
<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 66&nbsp;&nbsp; Tunnel-Cl=
ient-Endpoint [Note 5]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 67=
&nbsp;&nbsp; Tunnel-Server-Endpoint [Note 5]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp; 69&nbsp;&nbsp; Tunnel-Password [Note 5]<BR>&nbsp;&nbsp;=
 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp; 71&nbsp;&nbsp; ARAP-Features [Note 3]<BR>&nbs=
p;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 72&nbsp;&nbsp; ARAP-Zone-Access [Note=
 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 78&nbsp;&nbsp; Config=
uration-Token [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 79&nbsp;&nbs=
p; EAP-Message [Note 2]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp; 80&nbsp;&nbsp; Message-Aut=
henticator<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 81&nbsp;&nbsp;=
 Tunnel-Private-Group-ID [Note 5]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbs=
p;&nbsp; 82&nbsp;&nbsp; Tunnel-Assignment-ID [Note 5]<BR>&nbsp;&nbsp; 0+&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 0&nbsp;&nbsp;&nbsp; 83&nbsp;&nbsp; Tunnel-Preference [Note 5]<BR>&=
nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 85&nbsp;&nbsp; Acct-Interim-Interv=
al [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 87&nbsp;&nbsp; NAS=
-Port-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 88&nbsp;&nbs=
p; Framed-Pool [Note 6]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 89&nbs=
p;&nbsp; Chargeable-User-Identity [Note 1]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&=
nbsp;&nbsp;&nbsp; 90&nbsp;&nbsp; Tunnel-Client-Auth-ID [Note 5]<BR>&nbsp;&n=
bsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 91&nbsp;&nbsp; Tunnel-Server-Auth-ID=
 [Note 5]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 92&nbsp;&nbsp; NAS-F=
ilter-Rule [Note 3]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; =
94&nbsp;&nbsp; Originating-Line-Info<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;=
&nbsp; 95&nbsp;&nbsp; NAS-IPv6-Address [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&=
nbsp;&nbsp;&nbsp; 96&nbsp;&nbsp; Framed-Interface-Id [Note 6]<BR>&nbsp;&nbs=
p; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 97&nbsp;&nbsp; Framed-IPv6-Prefix [Not=
e 6]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 98&nbsp;&nbsp; Login=
-IPv6-Host [Note 3]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 99&nb=
sp;&nbsp; Framed-IPv6-Route [Note 3]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;=
 100&nbsp;&nbsp; Framed-IPv6-Pool [Note 6]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0+&nbsp; 101&nbsp;&nbsp; Error-Cause<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbs=
p;&nbsp; 123&nbsp;&nbsp; Delegated-IPv6-Prefix [Note 6]<BR>&nbsp;&nbsp; Req=
uest&nbsp;&nbsp; ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAK&nbsp;&nbsp; #&nbsp;&=
nbsp; Attribute<BR><BR>&nbsp;&nbsp; Disconnect Messages<BR><BR>&nbsp;&nbsp;=
 Request&nbsp;&nbsp; ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAK&nbsp;&nbsp; #&nb=
sp;&nbsp; Attribute<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 1&nb=
sp;&nbsp; User-Name [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&n=
bsp; 4&nbsp;&nbsp; NAS-IP-Address [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp; NAS-Port [Note 1]<BR>&nbsp;&nbsp; 0&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp;&nbsp; Service-Type<BR>&nbsp;&n=
bsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp; Framed-IP-A=
ddress [Note 6]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 18&nbsp;&=
nbsp; Reply-Message [Note 2]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbs=
p;&nbsp; 24&nbsp;&nbsp; State<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&n=
bsp; 25&nbsp;&nbsp; Class [Note 4]<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nb=
sp;&nbsp; 26&nbsp;&nbsp; Vendor-Specific<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&n=
bsp;&nbsp; 30&nbsp;&nbsp; Called-Station-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0&nbsp;&nbsp;&nbsp; 31&nbsp;&nbsp; Calling-Station-Id [Note 1]<BR>&nbsp;=
&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 32&nbsp;&nbsp; NAS-Identifier [Note 1]<=
BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp;&nbsp; 33&nbsp;&nbsp; Proxy-State<BR>&nbsp=
;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 44&nbsp;&nbsp; Acct-Session-Id [Note 1=
]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 49&nbsp;&nbsp; Acct-Terminate-Cause<BR=
>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 50&nbsp;&nbsp; Acct-Multi-Sessio=
n-Id [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp; 55&nbsp;&nbsp; Event-Timestamp<BR>&n=
bsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 61&nbsp;&nbsp; NAS-Port-T=
ype<BR>&nbsp;&nbsp; 0+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 79&nbsp;&nbsp; EAP-Message [Not=
e 2]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; 0-1&nbsp; 80&nbsp;&nbsp; Message-Authenticator<BR>&nbsp=
;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 87&nbsp;&nbsp; NAS-Port-Id [Note 1]<BR=
>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 89&nbsp;&nbsp; Chargeable-User-I=
dentity [Note 1]<BR>&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 95&nbsp;&nbsp=
; NAS-IPv6-Address [Note 1]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp=
;&nbsp; 96&nbsp;&nbsp; Framed-Interface-Id [Note 6]<BR>&nbsp;&nbsp; 0&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 97&nbsp;&nbsp; Framed-IPv6-Prefix [Note 6]<=
BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; 100&nbsp;&nbsp; Framed-IPv=
6-Pool [Note 6]<BR>&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0+&nbsp; 101&nbsp;&nbsp;=
 Error-Cause<BR>&nbsp;&nbsp; Request&nbsp;&nbsp; ACK&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; NAK&nbsp;&nbsp; #&nbsp;&nbsp; Attribute<BR><BR>&nbsp;&nbsp; The fol=
lowing table defines the meaning of the above table entries.<BR><BR>0&nbsp;=
&nbsp;&nbsp;&nbsp; This attribute MUST NOT be present in packet.<BR>0+&nbsp=
;&nbsp;&nbsp; Zero or more instances of this attribute MAY be present in pa=
cket.<BR>0-1&nbsp;&nbsp; Zero or one instance of this attribute MAY be pres=
ent in packet.<BR>1&nbsp;&nbsp;&nbsp;&nbsp; Exactly one instance of this at=
tribute MUST be present in packet.<BR><BR>&nbsp;&nbsp; [Note 1] Where NAS o=
r session identification attributes are included<BR>&nbsp;&nbsp; in Disconn=
ect-Request or CoA-Request packets, they are used for<BR>&nbsp;&nbsp; ident=
ification purposes only.&nbsp; These attributes MUST NOT be used for<BR>&nb=
sp;&nbsp; purposes other than identification (e.g. within CoA-Request packe=
ts<BR>&nbsp;&nbsp; to request authorization changes).<BR><BR>&nbsp;&nbsp; [=
Note 2] The Reply-Message Attribute is used to present a displayable<BR>&nb=
sp;&nbsp; message to the user.&nbsp; The message is only displayed as a res=
ult of a<BR>&nbsp;&nbsp; successful Disconnect-Request or CoA-Request (wher=
e a Disconnect-ACK<BR>&nbsp;&nbsp; or CoA-ACK is subsequently sent).&nbsp; =
Where EAP is used for<BR>&nbsp;&nbsp; authentication, an EAP-Message/Notifi=
cation-Request Attribute is sent<BR>&nbsp;&nbsp; instead, and Disconnect-AC=
K or CoA-ACK packets contain an EAP-<BR>&nbsp;&nbsp; Message/Notification-R=
esponse Attribute.<BR><BR>&nbsp;&nbsp; [Note 3] When included within a CoA-=
Request, these attributes<BR>&nbsp;&nbsp; represent an authorization change=
 request.&nbsp; When one of these<BR>&nbsp;&nbsp; attributes is omitted fro=
m a CoA-Request, the NAS assumes that the<BR>&nbsp;&nbsp; attribute value i=
s to remain unchanged.&nbsp; Attributes included in a<BR>&nbsp;&nbsp; CoA-R=
equest replace all existing value(s) of the same attribute(s).<BR><BR>&nbsp=
;&nbsp; [Note 4] When included within a successful Disconnect-Request (wher=
e<BR>&nbsp;&nbsp; a Disconnect-ACK is subsequently sent), the Class Attribu=
te SHOULD be<BR>&nbsp;&nbsp; sent unmodified by the client to the accountin=
g server in the<BR>&nbsp;&nbsp; Accounting Stop packet.&nbsp; If the Discon=
nect-Request is unsuccessful,<BR>&nbsp;&nbsp; then the Class Attribute is n=
ot processed.<BR><BR>&nbsp;&nbsp; [Note 5] When included within a CoA-Reque=
st, these attributes<BR>&nbsp;&nbsp; represent an authorization change requ=
est.&nbsp; Where tunnel attribute(s)<BR>&nbsp;&nbsp; are included within a =
successful CoA-Request, all existing tunnel<BR>&nbsp;&nbsp; attributes are =
removed and replaced by the new attribute(s).<BR><BR>&nbsp;&nbsp; [Note 6] =
Where included within a CoA-Request, these attributes<BR>&nbsp;&nbsp; repre=
sent a renumbering request.&nbsp; Since these attributes are not used<BR>&n=
bsp;&nbsp; for session identification, they MUST NOT be included within a<B=
R>&nbsp;&nbsp; Disconnect-Request.&nbsp; Note that renumbering may not be p=
ossible in all<BR>&nbsp;&nbsp; situations.&nbsp; For example, in order to c=
hange an IP address on receipt<BR>&nbsp;&nbsp; of a changed&nbsp; Framed-IP=
-Address address, IPCP re-negotiation could be<BR>&nbsp;&nbsp; required, wh=
ich is not supported by all PPP implementations.</FONT><BR>
<FONT face=3D"Courier New"></FONT>&nbsp;<BR>
<FONT face=3D"Courier New">Appendix A - Changes from RFC 3576<BR>&nbsp;<BR>=
&nbsp;&nbsp;&nbsp; This Appendix lists the major changes between [RFC3576] =
and this<BR>&nbsp;&nbsp;&nbsp; document.&nbsp; Minor changes, including sty=
le, grammar, spelling, and<BR>&nbsp;&nbsp;&nbsp; editorial changes are not =
mentioned here.<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; o Added details relating to=
 handling of the Proxy-State Attribute.<BR>&nbsp;&nbsp;&nbsp; Added require=
ment for duplicate detection on the RADIUS client<BR>&nbsp;&nbsp;&nbsp; (Se=
ction 2.3).<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; o Added Chargeable-User-Identit=
y as a session identification<BR>&nbsp;&nbsp;&nbsp; attribute.&nbsp; Remove=
d Framed-IP-Address, Framed-IPv6-Prefix, Framed-<BR>&nbsp;&nbsp;&nbsp; Inte=
rface-Id and NAS-Port-Type attributes as session identification<BR>&nbsp;&n=
bsp;&nbsp; attributes (Section 3).<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; o Added =
requirements for inclusion of the State Attribute in CoA-<BR>&nbsp;&nbsp;&n=
bsp; Request packets with a Service-Type of "Authorize Only" (Section<BR>&n=
bsp;&nbsp;&nbsp; 3.2).<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; o Added clarificatio=
n on the calculation of the Message-Authenticator<BR>&nbsp;&nbsp;&nbsp; Att=
ribute (Section 3.3).<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; o Added statement tha=
t support for "Authorize Only" Service-Type is<BR>&nbsp;&nbsp;&nbsp; option=
al (Section 3.5).<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; o Updated CoA-Request Att=
ribute Table to include Filter-Rule,<BR>&nbsp;&nbsp;&nbsp; Delegated-IPv6-P=
refix, Egress-VLANID, Ingress-Filters, Egress-VLAN-<BR>&nbsp;&nbsp;&nbsp; N=
ame and User-Priority attributes (Section 3.5).<BR>&nbsp;<BR>&nbsp;&nbsp;&n=
bsp; o Added the Chargeable-User-Identity Attribute to both the CoA-<BR>&nb=
sp;&nbsp;&nbsp; Request and Disconnect-Request Attribute table (Section 3.5=
).<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; o Added note on the use of the CoA-Reque=
st for renumbering (Section<BR>&nbsp;&nbsp;&nbsp; 3.5).<BR>&nbsp;<BR>&nbsp;=
&nbsp;&nbsp; o Use of Service-Type and Error-Cause attributes within a Disc=
onnect-<BR>&nbsp;&nbsp;&nbsp; Request is prohibited (Sections 3.5).<BR>&nbs=
p;<BR>&nbsp;&nbsp;&nbsp; o Added Diameter Considerations (Section 4).<BR>&n=
bsp;<BR>&nbsp;&nbsp;&nbsp; o Changed the text to indicate that the Event-Ti=
mestamp Attribute<BR>&nbsp;&nbsp;&nbsp; should not be recalculated on retra=
nsmission.&nbsp; The implications for<BR>&nbsp;&nbsp;&nbsp; replay and dupl=
icate detection are discussed (Section 6.4)."</FONT><BR></body>
</html>=

--_8078362c-927b-4f13-8362-7639f3c405d6_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 21:37:09 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 22 May 2007 14:36:32 -0700

--_7900dde4-cd6f-47aa-a163-f31f7d523d97_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I've never implemented RFC 3576, so please excuse me if I ask silly> ques=
tions. If the RADIUS Server / Dynamic Access Client receives a CoA-NAK,> in=
 response to a CoA-Request, it means that Service-Type of "Authorize-Only">=
 is not supported by the RADIUS Client / Dynamic Access Server, whether not=
> the Error-Cause attribute is present?
A CoA-NAK is always sent in response to a CoA-Request with a Service-Type o=
f "Authorize Only" regardless of whether the NAS supports this Service-type=
 value or not.   A CoA-ACK is never sent in response.=20
=20
So only the Error-Cause Attribute distinguishes a successful response from =
an unsuccessful one.  An Error-Cause Attribute is required in the case of a=
 successful response; it was a MAY in RFC 3576 for an unsuccessful one.  Gi=
ven this, a RADIUS server would have to interpret the absence of an Error-C=
ause attribute in a CoA-NAK as an indication of failure, but it would not k=
now *why* it failed.=20
> Are there other cases when Error-Cause is absent and it means something> =
else?
=20
Where the Service-Type Attribute is not present or the value is not "Author=
ize Only" it is possible to send a CoA-NAK or Disconnect-NAK and not includ=
e an Error-Cause attribute.   But in such a case, a CoA-NAK/Disconnect-NAK =
always indicates a failure.=20
=20
 =

--_7900dde4-cd6f-47aa-a163-f31f7d523d97_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&gt; I've never implemented RFC 3576, so please excuse me if I ask silly<BR=
>&gt; questions. If the RADIUS Server / Dynamic Access Client receives a Co=
A-NAK,<BR>&gt; in response to a CoA-Request, it means that Service-Type of =
"Authorize-Only"<BR>&gt; is not supported by the RADIUS Client / Dynamic Ac=
cess Server, whether not<BR>&gt; the Error-Cause attribute is present?<BR><=
BR>
A CoA-NAK is always sent in response to a CoA-Request with a Service-Type o=
f "Authorize Only" regardless of whether the NAS supports this Service-type=
 value or not.&nbsp;&nbsp; A CoA-ACK is never sent in response. <BR>
&nbsp;<BR>
So only the Error-Cause Attribute distinguishes a successful response from =
an unsuccessful one.&nbsp; An Error-Cause Attribute is required in the case=
 of a successful response; it was a MAY in RFC 3576 for an unsuccessful one=
.&nbsp; Given this, a RADIUS server would have to interpret the absence of =
an Error-Cause attribute in a CoA-NAK as an indication of failure, but it w=
ould not know *why* it failed. <BR>
<BR>&gt; Are there other cases when Error-Cause is absent and it means some=
thing<BR>&gt; else?<BR>
&nbsp;<BR>
Where the Service-Type Attribute is not present or the value is not "Author=
ize Only" it is possible to send a CoA-NAK or Disconnect-NAK and not includ=
e an Error-Cause attribute.&nbsp;&nbsp; But in such a case, a CoA-NAK/Disco=
nnect-NAK always indicates a failure. <BR>
&nbsp;<BR>
&nbsp;<BR></body>
</html>=

--_7900dde4-cd6f-47aa-a163-f31f7d523d97_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 20:27:50 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 22 May 2007 16:25:38 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

=A0=A0 A NAS MUST respond to a CoA-Request including a Service-Type
=A0=A0 Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK =
MUST
=A0=A0 NOT be sent.=A0 If the NAS does not support a Service-Type value =
of
=A0=A0 "Authorize Only" then it MUST respond with a CoA-NAK; an =
Error-Cause
=A0=A0 value of 405 (Unsupported Service) SHOULD be included.

=A0=A0 A CoA-Request containing a Service-Type Attribute with value
=A0=A0 "Authorize Only" MUST in addition contain only NAS or session
=A0=A0 identification attributes, as well as a State Attribute.=A0 If =
other
=A0=A0 attributes are included in such a CoA-Request, a CoA-NAK MUST be
=A0=A0 sent; an Error-Cause Attribute with value 401 (Unsupported =
Attribute)
=A0=A0 SHOULD be included.

I've never implemented RFC 3576, so please excuse me if I ask silly
questions.  If the RADIUS Server / Dynamic Access Client receives a =
CoA-NAK,
in response to a CoA-Request, it means that Service-Type of =
"Authorize-Only"
is not supported by the RADIUS Client / Dynamic Access Server, whether =
not
the Error-Cause attribute is present?

Are there other cases when Error-Cause is absent and it means something
else?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 20:13:34 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 22 May 2007 13:13:12 -0700

--_b57c3125-28d5-40eb-bcf0-70767f7b63bc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On re-reading Section 3.1, I think it could be made more clear that the las=
t paragraph refers only to successfully processed CoA-Requests.  Also, incl=
usion of an Error-Cause Attribute is upgraded to a SHOULD in case of an err=
or.  Here is the updated text:3.1.  Authorize Only   Support for a CoA-Requ=
est including a Service-Type Attribute with   value "Authorize Only" is OPT=
IONAL on the NAS and RADIUS server.  A   Service-Type Attribute MUST NOT be=
 included within a Disconnect-   Request.   A NAS MUST respond to a CoA-Req=
uest including a Service-Type   Attribute with value "Authorize Only" with =
a CoA-NAK; a CoA-ACK MUST   NOT be sent.  If the NAS does not support a Ser=
vice-Type value of   "Authorize Only" then it MUST respond with a CoA-NAK; =
an Error-Cause   value of 405 (Unsupported Service) SHOULD be included.   A=
 CoA-Request containing a Service-Type Attribute with value   "Authorize On=
ly" MUST in addition contain only NAS or session   identification attribute=
s, as well as a State Attribute.  If other   attributes are included in suc=
h a CoA-Request, a CoA-NAK MUST be   sent; an Error-Cause Attribute with va=
lue 401 (Unsupported Attribute)   SHOULD be included.   If a CoA-Request pa=
cket including a Service-Type value of "Authorize   Only" is successfully p=
rocessed, the NAS MUST respond with a CoA-NAK   containing a Service-Type A=
ttribute with value "Authorize Only", and   an Error-Cause Attribute with v=
alue 507 (Request Initiated).  The NAS   then MUST send an Access-Request t=
o the RADIUS server including a   Service-Type Attribute with value "Author=
ize Only".  This Access-   Request SHOULD contain the NAS identification at=
tributes from the   CoA-Request, as well as the session identification attr=
ibutes from   the CoA-Request legal for inclusion in an Access-Request as s=
pecified   in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].  As noted in  =
 [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be   incl=
uded in an Access-Request that does not contain a User-Password,   CHAP-Pas=
sword, ARAP-Password or EAP-Message Attribute.  The RADIUS   server then wi=
ll respond to the Access-Request with an Access-Accept   to (re-)authorize =
the session or an Access-Reject to refuse to   (re-)authorize it.From: bern=
[email-masked]: [email-masked]; [email-masked]=
Subject: RE: Issue 226:  RFC 3576bis and RenumberingDate: Tue, 22 May 2007 =
12:43:24 -0700

> It strikes me that the large number and substantial nature of these notes=
> suggests that they be incorporated elsewhere in the normative text of the=
> document, rather as footnotes to the Table of Attributes. I think it woul=
d> substantially enhance readability of the document. =20
I have consolidated Note 6 into Section 3.2 (State), and Note 7 as well as =
other "Authorize Only" text into a new Section 3.1 (Authorize Only).  Here =
is the new text:
=20
3.1.  Authorize Only   Support for a CoA-Request including a Service-Type A=
ttribute with   value "Authorize Only" is OPTIONAL on the NAS and RADIUS se=
rver.  A   Service-Type Attribute MUST NOT be included within a Disconnect-=
   Request.   A NAS MUST respond to a CoA-Request including a Service-Type =
  Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST   NO=
T be sent.  If the NAS does not support a Service-Type value of   "Authoriz=
e Only" then it MUST respond with a CoA-NAK; an Error-Cause   value of 405 =
(Unsupported Service) SHOULD be included.   A CoA-Request containing a Serv=
ice-Type Attribute with value   "Authorize Only" MUST in addition contain o=
nly NAS or session   identification attributes, as well as a State Attribut=
e.  If other   attributes are included in such a CoA-Request, a CoA-NAK MUS=
T be   sent; an Error-Cause Attribute with value 401 (Unsupported Attribute=
)   SHOULD be included.   A NAS supporting a Service-Type value of "Authori=
ze Only" within a   CoA-Request packet MUST respond with a CoA-NAK containi=
ng a Service-   Type Attribute with value "Authorize Only", and an Error-Ca=
use   Attribute with value "Request Initiated".  The NAS then sends an   Ac=
cess-Request to the RADIUS server including a Service-Type   Attribute with=
 value "Authorize Only".  This Access-Request SHOULD   contain the NAS iden=
tification attributes from the CoA-Request, as   well as the session identi=
fication attributes from the CoA-Request   legal for inclusion in an Access=
-Request as specified in [RFC2865],   [RFC2868], [RFC2869] and [RFC3162].  =
As noted in [RFC2869] Section   5.19, a Message-Authenticator attribute SHO=
ULD be included in an   Access-Request that does not contain a User-Passwor=
d, CHAP-Password,   ARAP-Password or EAP-Message Attribute.  The RADIUS ser=
ver should   send back an Access-Accept to (re-)authorize the session or an=
   Access-Reject to refuse to (re-)authorize it.3.2.  State   The State Att=
ribute is available to be sent by the RADIUS server to   the NAS in a CoA-R=
equest packet and MUST be sent unmodified from the   NAS to the RADIUS serv=
er in a subsequent CoA-ACK or CoA-NAK packet.   [RFC2865] Section 5.44 stat=
es:      An Access-Request MUST contain either a User-Password or a CHAP-  =
    Password or State.  An Access-Request MUST NOT contain both a      User=
-Password and a CHAP-Password.  If future extensions allow      other kinds=
 of authentication information to be conveyed, the      attribute for that =
can be used in an Access-Request instead of      User-Password or CHAP-Pass=
word.   In order to satisfy the requirements of [RFC2865] Section 5.44, an =
  Access-Request with Service-Type=3D"Authorize-Only" MUST contain a   Stat=
e attribute.   In order to provide a State attribute to the NAS, a server s=
ending a   CoA-Request with a Service-Type value of "Authorize-Only" MUST  =
 include a State Attribute, and the NAS MUST send the State Attribute   unm=
odified to the RADIUS server in the resulting Access-Request, if   any.  A =
NAS receiving a CoA-Request containing a Service-Type value   of "Authorize=
-Only" but lacking a State attribute MUST send a CoA-NAK   and SHOULD inclu=
de an Error-Cause attribute with value 402 (Missing   Attribute).   The Sta=
te Attribute is also available to be sent by the RADIUS server   to the NAS=
 in a CoA-Request that also includes a Termination-Action   Attribute with =
the value of RADIUS-Request.  If the client performs   the Termination-Acti=
on by sending a new Access-Request upon   termination of the current sessio=
n, it MUST include the State   Attribute unchanged in that Access-Request. =
 In either usage, the   client MUST NOT interpret the Attribute locally.  A=
 CoA-Request   packet must have only zero or one State Attribute.  Usage of=
 the   State Attribute is implementation dependent.

--_b57c3125-28d5-40eb-bcf0-70767f7b63bc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
On re-reading Section 3.1, I think it could be made more clear that the las=
t paragraph refers only to successfully processed CoA-Requests.&nbsp; Also,=
 inclusion of an Error-Cause Attribute is upgraded to a SHOULD in case of a=
n error.&nbsp; Here is the updated text:<br><br>3.1.&nbsp; Authorize Only<b=
r><br>&nbsp;&nbsp; Support for a CoA-Request including a Service-Type Attri=
bute with<br>&nbsp;&nbsp; value "Authorize Only" is OPTIONAL on the NAS and=
 RADIUS server.&nbsp; A<br>&nbsp;&nbsp; Service-Type Attribute MUST NOT be =
included within a Disconnect-<br>&nbsp;&nbsp; Request.<br><br>&nbsp;&nbsp; =
A NAS MUST respond to a CoA-Request including a Service-Type<br>&nbsp;&nbsp=
; Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST<br>&=
nbsp;&nbsp; NOT be sent.&nbsp; If the NAS does not support a Service-Type v=
alue of<br>&nbsp;&nbsp; "Authorize Only" then it MUST respond with a CoA-NA=
K; an Error-Cause<br>&nbsp;&nbsp; value of 405 (Unsupported Service) SHOULD=
 be included.<br><br>&nbsp;&nbsp; A CoA-Request containing a Service-Type A=
ttribute with value<br>&nbsp;&nbsp; "Authorize Only" MUST in addition conta=
in only NAS or session<br>&nbsp;&nbsp; identification attributes, as well a=
s a State Attribute.&nbsp; If other<br>&nbsp;&nbsp; attributes are included=
 in such a CoA-Request, a CoA-NAK MUST be<br>&nbsp;&nbsp; sent; an Error-Ca=
use Attribute with value 401 (Unsupported Attribute)<br>&nbsp;&nbsp; SHOULD=
 be included.<br><br>&nbsp;&nbsp; If a CoA-Request packet including a Servi=
ce-Type value of "Authorize<br>&nbsp;&nbsp; Only" is successfully processed=
, the NAS MUST respond with a CoA-NAK<br>&nbsp;&nbsp; containing a Service-=
Type Attribute with value "Authorize Only", and<br>&nbsp;&nbsp; an Error-Ca=
use Attribute with value 507 (Request Initiated).&nbsp; The NAS<br>&nbsp;&n=
bsp; then MUST send an Access-Request to the RADIUS server including a<br>&=
nbsp;&nbsp; Service-Type Attribute with value "Authorize Only".&nbsp; This =
Access-<br>&nbsp;&nbsp; Request SHOULD contain the NAS identification attri=
butes from the<br>&nbsp;&nbsp; CoA-Request, as well as the session identifi=
cation attributes from<br>&nbsp;&nbsp; the CoA-Request legal for inclusion =
in an Access-Request as specified<br>&nbsp;&nbsp; in [RFC2865], [RFC2868], =
[RFC2869] and [RFC3162].&nbsp; As noted in<br>&nbsp;&nbsp; [RFC2869] Sectio=
n 5.19, a Message-Authenticator attribute SHOULD be<br>&nbsp;&nbsp; include=
d in an Access-Request that does not contain a User-Password,<br>&nbsp;&nbs=
p; CHAP-Password, ARAP-Password or EAP-Message Attribute.&nbsp; The RADIUS<=
br>&nbsp;&nbsp; server then will respond to the Access-Request with an Acce=
ss-Accept<br>&nbsp;&nbsp; to (re-)authorize the session or an Access-Reject=
 to refuse to<br>&nbsp;&nbsp; (re-)authorize it.<br><br><blockquote><hr>Fro=
m: [email-masked]<br>To: [email-masked]; radiusext@o=
ps.ietf.org<br>Subject: RE: Issue 226:  RFC 3576bis and Renumbering<br>Date=
: Tue, 22 May 2007 12:43:24 -0700<br><br>

<blockquote>
&gt; It strikes me that the large number and substantial nature of these no=
tes<br>&gt; suggests that they be incorporated elsewhere in the normative t=
ext of the<br>&gt; document, rather as footnotes to the Table of Attributes=
. I think it would<br>&gt; substantially enhance readability of the documen=
t.&nbsp;<br>&nbsp;<br>
I have consolidated Note 6 into Section 3.2 (State), and Note 7 as well as =
other "Authorize Only" text into a new Section 3.1 (Authorize Only).&nbsp; =
Here is the new text:<br>
&nbsp;<br>
3.1.&nbsp; Authorize Only<br><br>&nbsp;&nbsp; Support for a CoA-Request inc=
luding a Service-Type Attribute with<br>&nbsp;&nbsp; value "Authorize Only"=
 is OPTIONAL on the NAS and RADIUS server.&nbsp; A<br>&nbsp;&nbsp; Service-=
Type Attribute MUST NOT be included within a Disconnect-<br>&nbsp;&nbsp; Re=
quest.<br><br>&nbsp;&nbsp; A NAS MUST respond to a CoA-Request including a =
Service-Type<br>&nbsp;&nbsp; Attribute with value "Authorize Only" with a C=
oA-NAK; a CoA-ACK MUST<br>&nbsp;&nbsp; NOT be sent.&nbsp; If the NAS does n=
ot support a Service-Type value of<br>&nbsp;&nbsp; "Authorize Only" then it=
 MUST respond with a CoA-NAK; an Error-Cause<br>&nbsp;&nbsp; value of 405 (=
Unsupported Service) SHOULD be included.<br><br>&nbsp;&nbsp; A CoA-Request =
containing a Service-Type Attribute with value<br>&nbsp;&nbsp; "Authorize O=
nly" MUST in addition contain only NAS or session<br>&nbsp;&nbsp; identific=
ation attributes, as well as a State Attribute.&nbsp; If other<br>&nbsp;&nb=
sp; attributes are included in such a CoA-Request, a CoA-NAK MUST be<br>&nb=
sp;&nbsp; sent; an Error-Cause Attribute with value 401 (Unsupported Attrib=
ute)<br>&nbsp;&nbsp; SHOULD be included.<br><br>&nbsp;&nbsp; A NAS supporti=
ng a Service-Type value of "Authorize Only" within a<br>&nbsp;&nbsp; CoA-Re=
quest packet MUST respond with a CoA-NAK containing a Service-<br>&nbsp;&nb=
sp; Type Attribute with value "Authorize Only", and an Error-Cause<br>&nbsp=
;&nbsp; Attribute with value "Request Initiated".&nbsp; The NAS then sends =
an<br>&nbsp;&nbsp; Access-Request to the RADIUS server including a Service-=
Type<br>&nbsp;&nbsp; Attribute with value "Authorize Only".&nbsp; This Acce=
ss-Request SHOULD<br>&nbsp;&nbsp; contain the NAS identification attributes=
 from the CoA-Request, as<br>&nbsp;&nbsp; well as the session identificatio=
n attributes from the CoA-Request<br>&nbsp;&nbsp; legal for inclusion in an=
 Access-Request as specified in [RFC2865],<br>&nbsp;&nbsp; [RFC2868], [RFC2=
869] and [RFC3162].&nbsp; As noted in [RFC2869] Section<br>&nbsp;&nbsp; 5.1=
9, a Message-Authenticator attribute SHOULD be included in an<br>&nbsp;&nbs=
p; Access-Request that does not contain a User-Password, CHAP-Password,<br>=
&nbsp;&nbsp; ARAP-Password or EAP-Message Attribute.&nbsp; The RADIUS serve=
r should<br>&nbsp;&nbsp; send back an Access-Accept to (re-)authorize the s=
ession or an<br>&nbsp;&nbsp; Access-Reject to refuse to (re-)authorize it.<=
br><br>3.2.&nbsp; State<br><br>&nbsp;&nbsp; The State Attribute is availabl=
e to be sent by the RADIUS server to<br>&nbsp;&nbsp; the NAS in a CoA-Reque=
st packet and MUST be sent unmodified from the<br>&nbsp;&nbsp; NAS to the R=
ADIUS server in a subsequent CoA-ACK or CoA-NAK packet.<br><br>&nbsp;&nbsp;=
 [RFC2865] Section 5.44 states:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An Ac=
cess-Request MUST contain either a User-Password or a CHAP-<br>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; Password or State.&nbsp; An Access-Request MUST NOT cont=
ain both a<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password and a CHAP-Passw=
ord.&nbsp; If future extensions allow<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; oth=
er kinds of authentication information to be conveyed, the<br>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; attribute for that can be used in an Access-Request inste=
ad of<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password or CHAP-Password.<br>=
<br>&nbsp;&nbsp; In order to satisfy the requirements of [RFC2865] Section =
5.44, an<br>&nbsp;&nbsp; Access-Request with Service-Type=3D"Authorize-Only=
" MUST contain a<br>&nbsp;&nbsp; State attribute.<br><br>&nbsp;&nbsp; In or=
der to provide a State attribute to the NAS, a server sending a<br>&nbsp;&n=
bsp; CoA-Request with a Service-Type value of "Authorize-Only" MUST<br>&nbs=
p;&nbsp; include a State Attribute, and the NAS MUST send the State Attribu=
te<br>&nbsp;&nbsp; unmodified to the RADIUS server in the resulting Access-=
Request, if<br>&nbsp;&nbsp; any.&nbsp; A NAS receiving a CoA-Request contai=
ning a Service-Type value<br>&nbsp;&nbsp; of "Authorize-Only" but lacking a=
 State attribute MUST send a CoA-NAK<br>&nbsp;&nbsp; and SHOULD include an =
Error-Cause attribute with value 402 (Missing<br>&nbsp;&nbsp; Attribute).<b=
r><br>&nbsp;&nbsp; The State Attribute is also available to be sent by the =
RADIUS server<br>&nbsp;&nbsp; to the NAS in a CoA-Request that also include=
s a Termination-Action<br>&nbsp;&nbsp; Attribute with the value of RADIUS-R=
equest.&nbsp; If the client performs<br>&nbsp;&nbsp; the Termination-Action=
 by sending a new Access-Request upon<br>&nbsp;&nbsp; termination of the cu=
rrent session, it MUST include the State<br>&nbsp;&nbsp; Attribute unchange=
d in that Access-Request.&nbsp; In either usage, the<br>&nbsp;&nbsp; client=
 MUST NOT interpret the Attribute locally.&nbsp; A CoA-Request<br>&nbsp;&nb=
sp; packet must have only zero or one State Attribute.&nbsp; Usage of the<b=
r>&nbsp;&nbsp; State Attribute is implementation dependent.<br><br></blockq=
uote>
</blockquote></body>
</html>=

--_b57c3125-28d5-40eb-bcf0-70767f7b63bc_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 19:57:31 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue:  Error-Cause Attribute in Disconnect-ACK?
Date: Tue, 22 May 2007 12:57:11 -0700

--_753c6a07-f3ba-4255-8dcd-514d3bffed85_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I also noticed another oddity in usage of the Error-Cause Attribute.=20
=20
It is stated that a CoA-NAK MUST always be sent in response to a CoA-Reques=
t including a Service-Type Attribute with value "Authorize Only".  If the C=
oA-Request can be processed, then sending an Error-Cause Attribute with val=
ue 507 (Request Initiated) is required.  However, if the CoA-Request cannot=
 be processed, sending an Error-Cause attribute is optional.  Given that NA=
S implementations supporting a Service-Type attribute with value "Authorize=
 Only" have to be able to send the Error-Cause Attribute in the event that =
the Request can be processed, why isn't sending an Error-Cause attribute a =
SHOULD in the event of an error? =20
=20
> From: [email-masked]> To: [email-masked]> Subject: Iss=
ue: Error-Cause Attribute in Disconnect-ACK?> Date: Tue, 22 May 2007 10:31:=
40 -0700> > > Issue: Error-Cause Attribute in Disconnect-ACK?> Submitter na=
me: Bernard Aboba> Submitter email address: [email-masked]> Date first=
 submitted: May 22, 2007> Reference: > Document: RFC3576bis-05> Comment typ=
e: Technical> Priority: S> Section: 3.4> Rationale/Explanation of issue:> >=
 In the process of editing the attribute table to address Issue 226, I noti=
ced an oddity. > > RFC 3576 Section 3.1 states the following:> > It is poss=
ible that the NAS cannot honor Disconnect-Request or> CoA-Request messages =
for some reason. The Error-Cause Attribute> provides more detail on the cau=
se of the problem. It MAY be> included within Disconnect-ACK, Disconnect-NA=
K and CoA-NAK> messages.> > Why would an Error-Cause Attribute be included =
in a Disconnect-ACK? It is not allowed in a CoA-ACK, for example. > --> to =
unsubscribe send a message to [email-masked] with> the word=
 'unsubscribe' in a single line as the message text body.> archive: <http:/=
/psg.com/lists/radiusext/>=

--_753c6a07-f3ba-4255-8dcd-514d3bffed85_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
I also noticed another oddity in usage of the Error-Cause Attribute. <BR>
&nbsp;<BR>
It&nbsp;is stated that a CoA-NAK MUST always be sent in response to a CoA-R=
equest&nbsp;including a Service-Type Attribute with value "Authorize Only".=
&nbsp; If the CoA-Request can be processed, then sending an Error-Cause Att=
ribute with value 507 (Request Initiated) is required.&nbsp; However, if th=
e CoA-Request cannot be processed, sending an Error-Cause attribute is opti=
onal.&nbsp; Given that NAS implementations supporting a Service-Type attrib=
ute with value "Authorize Only" have to be able to send the Error-Cause Att=
ribute in the event that the Request can be processed, why isn't sending an=
 Error-Cause attribute a SHOULD in the event of an error? &nbsp;<BR>
&nbsp;<BR>
<BR><BR>&gt; From: [email-masked]<BR>&gt; To: [email-masked]=
.org<BR>&gt; Subject: Issue: Error-Cause Attribute in Disconnect-ACK?<BR>&g=
t; Date: Tue, 22 May 2007 10:31:40 -0700<BR>&gt; <BR>&gt; <BR>&gt; Issue: E=
rror-Cause Attribute in Disconnect-ACK?<BR>&gt; Submitter name: Bernard Abo=
ba<BR>&gt; Submitter email address: [email-masked]<BR>&gt; Date first =
submitted: May 22, 2007<BR>&gt; Reference: <BR>&gt; Document: RFC3576bis-05=
<BR>&gt; Comment type: Technical<BR>&gt; Priority: S<BR>&gt; Section: 3.4<B=
R>&gt; Rationale/Explanation of issue:<BR>&gt; <BR>&gt; In the process of e=
diting the attribute table to address Issue 226, I noticed an oddity. <BR>&=
gt; <BR>&gt; RFC 3576 Section 3.1 states the following:<BR>&gt; <BR>&gt; It=
 is possible that the NAS cannot honor Disconnect-Request or<BR>&gt; CoA-Re=
quest messages for some reason. The Error-Cause Attribute<BR>&gt; provides =
more detail on the cause of the problem. It MAY be<BR>&gt; included within =
Disconnect-ACK, Disconnect-NAK and CoA-NAK<BR>&gt; messages.<BR>&gt; <BR>&g=
t; Why would an Error-Cause Attribute be included in a Disconnect-ACK? It i=
s not allowed in a CoA-ACK, for example. <BR>&gt; --<BR>&gt; to unsubscribe=
 send a message to [email-masked] with<BR>&gt; the word 'un=
subscribe' in a single line as the message text body.<BR>&gt; archive: &lt;=
http://psg.com/lists/radiusext/&gt;<BR><BR></body>
</html>=

--_753c6a07-f3ba-4255-8dcd-514d3bffed85_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 19:44:01 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 22 May 2007 12:43:24 -0700

--_37557d2c-6f82-4fe1-8c8a-ec622610f7b4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> It strikes me that the large number and substantial nature of these notes=
> suggests that they be incorporated elsewhere in the normative text of the=
> document, rather as footnotes to the Table of Attributes. I think it woul=
d> substantially enhance readability of the document. =20
I have consolidated Note 6 into Section 3.2 (State), and Note 7 as well as =
other "Authorize Only" text into a new Section 3.1 (Authorize Only).  Here =
is the new text:
=20
3.1.  Authorize Only   Support for a CoA-Request including a Service-Type A=
ttribute with   value "Authorize Only" is OPTIONAL on the NAS and RADIUS se=
rver.  A   Service-Type Attribute MUST NOT be included within a Disconnect-=
   Request.   A NAS MUST respond to a CoA-Request including a Service-Type =
  Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST   NO=
T be sent.  If the NAS does not support a Service-Type value of   "Authoriz=
e Only" then it MUST respond with a CoA-NAK; an Error-Cause   value of 405 =
(Unsupported Service) SHOULD be included.   A CoA-Request containing a Serv=
ice-Type Attribute with value   "Authorize Only" MUST in addition contain o=
nly NAS or session   identification attributes, as well as a State Attribut=
e.  If other   attributes are included in such a CoA-Request, a CoA-NAK MUS=
T be   sent; an Error-Cause Attribute with value 401 (Unsupported Attribute=
)   SHOULD be included.   A NAS supporting a Service-Type value of "Authori=
ze Only" within a   CoA-Request packet MUST respond with a CoA-NAK containi=
ng a Service-   Type Attribute with value "Authorize Only", and an Error-Ca=
use   Attribute with value "Request Initiated".  The NAS then sends an   Ac=
cess-Request to the RADIUS server including a Service-Type   Attribute with=
 value "Authorize Only".  This Access-Request SHOULD   contain the NAS iden=
tification attributes from the CoA-Request, as   well as the session identi=
fication attributes from the CoA-Request   legal for inclusion in an Access=
-Request as specified in [RFC2865],   [RFC2868], [RFC2869] and [RFC3162].  =
As noted in [RFC2869] Section   5.19, a Message-Authenticator attribute SHO=
ULD be included in an   Access-Request that does not contain a User-Passwor=
d, CHAP-Password,   ARAP-Password or EAP-Message Attribute.  The RADIUS ser=
ver should   send back an Access-Accept to (re-)authorize the session or an=
   Access-Reject to refuse to (re-)authorize it.3.2.  State   The State Att=
ribute is available to be sent by the RADIUS server to   the NAS in a CoA-R=
equest packet and MUST be sent unmodified from the   NAS to the RADIUS serv=
er in a subsequent CoA-ACK or CoA-NAK packet.   [RFC2865] Section 5.44 stat=
es:      An Access-Request MUST contain either a User-Password or a CHAP-  =
    Password or State.  An Access-Request MUST NOT contain both a      User=
-Password and a CHAP-Password.  If future extensions allow      other kinds=
 of authentication information to be conveyed, the      attribute for that =
can be used in an Access-Request instead of      User-Password or CHAP-Pass=
word.   In order to satisfy the requirements of [RFC2865] Section 5.44, an =
  Access-Request with Service-Type=3D"Authorize-Only" MUST contain a   Stat=
e attribute.   In order to provide a State attribute to the NAS, a server s=
ending a   CoA-Request with a Service-Type value of "Authorize-Only" MUST  =
 include a State Attribute, and the NAS MUST send the State Attribute   unm=
odified to the RADIUS server in the resulting Access-Request, if   any.  A =
NAS receiving a CoA-Request containing a Service-Type value   of "Authorize=
-Only" but lacking a State attribute MUST send a CoA-NAK   and SHOULD inclu=
de an Error-Cause attribute with value 402 (Missing   Attribute).   The Sta=
te Attribute is also available to be sent by the RADIUS server   to the NAS=
 in a CoA-Request that also includes a Termination-Action   Attribute with =
the value of RADIUS-Request.  If the client performs   the Termination-Acti=
on by sending a new Access-Request upon   termination of the current sessio=
n, it MUST include the State   Attribute unchanged in that Access-Request. =
 In either usage, the   client MUST NOT interpret the Attribute locally.  A=
 CoA-Request   packet must have only zero or one State Attribute.  Usage of=
 the   State Attribute is implementation dependent.=

--_37557d2c-6f82-4fe1-8c8a-ec622610f7b4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<BLOCKQUOTE>
&gt; It strikes me that the large number and substantial nature of these no=
tes<BR>&gt; suggests that they be incorporated elsewhere in the normative t=
ext of the<BR>&gt; document, rather as footnotes to the Table of Attributes=
. I think it would<BR>&gt; substantially enhance readability of the documen=
t.&nbsp;<BR>&nbsp;<BR>
I have consolidated Note 6 into Section 3.2 (State), and Note 7 as well as =
other "Authorize Only" text into a new Section 3.1 (Authorize Only).&nbsp; =
Here is the new text:<BR>
&nbsp;<BR>
3.1.&nbsp; Authorize Only<BR><BR>&nbsp;&nbsp; Support for a CoA-Request inc=
luding a Service-Type Attribute with<BR>&nbsp;&nbsp; value "Authorize Only"=
 is OPTIONAL on the NAS and RADIUS server.&nbsp; A<BR>&nbsp;&nbsp; Service-=
Type Attribute MUST NOT be included within a Disconnect-<BR>&nbsp;&nbsp; Re=
quest.<BR><BR>&nbsp;&nbsp; A NAS MUST respond to a CoA-Request including a =
Service-Type<BR>&nbsp;&nbsp; Attribute with value "Authorize Only" with a C=
oA-NAK; a CoA-ACK MUST<BR>&nbsp;&nbsp; NOT be sent.&nbsp; If the NAS does n=
ot support a Service-Type value of<BR>&nbsp;&nbsp; "Authorize Only" then it=
 MUST respond with a CoA-NAK; an Error-Cause<BR>&nbsp;&nbsp; value of 405 (=
Unsupported Service) SHOULD be included.<BR><BR>&nbsp;&nbsp; A CoA-Request =
containing a Service-Type Attribute with value<BR>&nbsp;&nbsp; "Authorize O=
nly" MUST in addition contain only NAS or session<BR>&nbsp;&nbsp; identific=
ation attributes, as well as a State Attribute.&nbsp; If other<BR>&nbsp;&nb=
sp; attributes are included in such a CoA-Request, a CoA-NAK MUST be<BR>&nb=
sp;&nbsp; sent; an Error-Cause Attribute with value 401 (Unsupported Attrib=
ute)<BR>&nbsp;&nbsp; SHOULD be included.<BR><BR>&nbsp;&nbsp; A NAS supporti=
ng a Service-Type value of "Authorize Only" within a<BR>&nbsp;&nbsp; CoA-Re=
quest packet MUST respond with a CoA-NAK containing a Service-<BR>&nbsp;&nb=
sp; Type Attribute with value "Authorize Only", and an Error-Cause<BR>&nbsp=
;&nbsp; Attribute with value "Request Initiated".&nbsp; The NAS then sends =
an<BR>&nbsp;&nbsp; Access-Request to the RADIUS server including a Service-=
Type<BR>&nbsp;&nbsp; Attribute with value "Authorize Only".&nbsp; This Acce=
ss-Request SHOULD<BR>&nbsp;&nbsp; contain the NAS identification attributes=
 from the CoA-Request, as<BR>&nbsp;&nbsp; well as the session identificatio=
n attributes from the CoA-Request<BR>&nbsp;&nbsp; legal for inclusion in an=
 Access-Request as specified in [RFC2865],<BR>&nbsp;&nbsp; [RFC2868], [RFC2=
869] and [RFC3162].&nbsp; As noted in [RFC2869] Section<BR>&nbsp;&nbsp; 5.1=
9, a Message-Authenticator attribute SHOULD be included in an<BR>&nbsp;&nbs=
p; Access-Request that does not contain a User-Password, CHAP-Password,<BR>=
&nbsp;&nbsp; ARAP-Password or EAP-Message Attribute.&nbsp; The RADIUS serve=
r should<BR>&nbsp;&nbsp; send back an Access-Accept to (re-)authorize the s=
ession or an<BR>&nbsp;&nbsp; Access-Reject to refuse to (re-)authorize it.<=
BR><BR>3.2.&nbsp; State<BR><BR>&nbsp;&nbsp; The State Attribute is availabl=
e to be sent by the RADIUS server to<BR>&nbsp;&nbsp; the NAS in a CoA-Reque=
st packet and MUST be sent unmodified from the<BR>&nbsp;&nbsp; NAS to the R=
ADIUS server in a subsequent CoA-ACK or CoA-NAK packet.<BR><BR>&nbsp;&nbsp;=
 [RFC2865] Section 5.44 states:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An Ac=
cess-Request MUST contain either a User-Password or a CHAP-<BR>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; Password or State.&nbsp; An Access-Request MUST NOT cont=
ain both a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password and a CHAP-Passw=
ord.&nbsp; If future extensions allow<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; oth=
er kinds of authentication information to be conveyed, the<BR>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; attribute for that can be used in an Access-Request inste=
ad of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Password or CHAP-Password.<BR>=
<BR>&nbsp;&nbsp; In order to satisfy the requirements of [RFC2865] Section =
5.44, an<BR>&nbsp;&nbsp; Access-Request with Service-Type=3D"Authorize-Only=
" MUST contain a<BR>&nbsp;&nbsp; State attribute.<BR><BR>&nbsp;&nbsp; In or=
der to provide a State attribute to the NAS, a server sending a<BR>&nbsp;&n=
bsp; CoA-Request with a Service-Type value of "Authorize-Only" MUST<BR>&nbs=
p;&nbsp; include a State Attribute, and the NAS MUST send the State Attribu=
te<BR>&nbsp;&nbsp; unmodified to the RADIUS server in the resulting Access-=
Request, if<BR>&nbsp;&nbsp; any.&nbsp; A NAS receiving a CoA-Request contai=
ning a Service-Type value<BR>&nbsp;&nbsp; of "Authorize-Only" but lacking a=
 State attribute MUST send a CoA-NAK<BR>&nbsp;&nbsp; and SHOULD include an =
Error-Cause attribute with value 402 (Missing<BR>&nbsp;&nbsp; Attribute).<B=
R><BR>&nbsp;&nbsp; The State Attribute is also available to be sent by the =
RADIUS server<BR>&nbsp;&nbsp; to the NAS in a CoA-Request that also include=
s a Termination-Action<BR>&nbsp;&nbsp; Attribute with the value of RADIUS-R=
equest.&nbsp; If the client performs<BR>&nbsp;&nbsp; the Termination-Action=
 by sending a new Access-Request upon<BR>&nbsp;&nbsp; termination of the cu=
rrent session, it MUST include the State<BR>&nbsp;&nbsp; Attribute unchange=
d in that Access-Request.&nbsp; In either usage, the<BR>&nbsp;&nbsp; client=
 MUST NOT interpret the Attribute locally.&nbsp; A CoA-Request<BR>&nbsp;&nb=
sp; packet must have only zero or one State Attribute.&nbsp; Usage of the<B=
R>&nbsp;&nbsp; State Attribute is implementation dependent.<BR><BR></BLOCKQ=
UOTE></body>
</html>=

--_37557d2c-6f82-4fe1-8c8a-ec622610f7b4_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 18:55:12 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 22 May 2007 11:54:43 -0700

--_2536ed29-6ee9-422d-bc0e-b6afeba1fc08_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> s/so that the User-Name may not be/because the User-Name may not be/
Got it.=20
 > > Where the Acct-Session-Id attribute is not present in a CoA-Request> >=
 or Disconnect-Request, it is possible that the User-Name or> > Chargeable-=
User-Identity attributes will not be sufficient to> > uniquely identify the=
 session (e.g. if the same user has multiple> > sessions on the NAS). As a =
result, the Called-Station-Id, Calling-> > Station-Id, NAS-Port, NAS-Port-I=
d and Acct-Multi-Session-Id> > attributes MAY be used for session identific=
ation in addition.> > s/MAY be used for session identification in addition.=
/MAY be used as> additional session identification./
=20
Here is a rewritten paragraph:
=20
Where the Acct-Session-Id or Acct-Multi-Session-Id attributes are not prese=
nt in  a CoA-Request or Disconnect-Request, it is possible that the User-Na=
me or Chargeable-User-Identity attributes will not be sufficient to uniquel=
y identify the session (e.g. if the sameuser has multiple sessions on the N=
AS, or the privacy NAI is used). As a result, the Called-Station-Id, Callin=
g-Station-Id, NAS-Port and NAS-Port-Id attributes MAY be used as additional=
 session identification. > > [Note 6] Support for the Service-Type of "Auth=
orize Only" is OPTIONAL> > on the NAS and RADIUS server. A NAS supporting t=
he "Authorize Only"> > Service-Type value within a CoA-Request packet MUST =
respond with a> > CoA-NAK containing a Service-Type Attribute with value "A=
uthorize> > Only", and an Error-Cause Attribute with value "Request Initiat=
ed".> > The NAS then sends an Access-Request to the RADIUS server with a> >=
 Service-Type Attribute with value "Authorize Only". This Access-> > Reques=
t SHOULD contain the NAS attributes from the CoA-Request, as> > well as the=
 session attributes from the CoA-Request legal for> > inclusion in an Acces=
s-Request as specified in [RFC2865], [RFC2868], > > [RFC2869] and [RFC3162]=
. As noted in [RFC2869] Section 5.19, a> > Message-Authenticator attribute =
SHOULD be included in an Access-> > Request that does not contain a User-Pa=
ssword, CHAP-Password, ARAP-> > Password or EAP-Message Attribute. The RADI=
US server should send> > back an Access-Accept to (re-)authorize the sessio=
n or an Access-> > Reject to refuse to (re-)authorize it.> > > > A NAS that=
 does not support the Service-Type Attribute with the value> > "Authorize O=
nly" within a CoA-Request MUST respond with a CoA-NAK> > including no Servi=
ce-Type Attribute; an Error-Cause Attribute with> > value "Unsupported Serv=
ice" MAY be included.> > > > [Note 7] The State Attribute is available to b=
e sent by the RADIUS> > server to the NAS in a CoA-Request packet and MUST =
be sent unmodified> > from the NAS to the RADIUS server in a subsequent ACK=
 or NAK packet.> > If a Service-Type Attribute with value "Authorize Only" =
is included> > in a CoA-Request then a State Attribute MUST be present, and=
 MUST be> > sent unmodified from the NAS to the RADIUS server in the result=
ing> > Access-Request sent to the RADIUS server, if any. The State> > Attri=
bute is also available to be sent by the RADIUS server to the> > NAS in a C=
oA-Request that also includes a Termination-Action> > Attribute with the va=
lue of RADIUS-Request. If the client performs> > the Termination-Action by =
sending a new Access-Request upon> > termination of the current session, it=
 MUST include the State> > Attribute unchanged in that Access-Request. In e=
ither usage, the> > client MUST NOT interpret the Attribute locally. A CoA-=
Request> > packet must have only zero or one State Attribute. Usage of the>=
 > State Attribute is implementation dependent.> > > > [Note 8] Where inclu=
ded within a CoA-Request, these attributes> > represent a renumbering reque=
st. Since these attributes are not used> > for session identification, they=
 MUST NOT be included within a> > Disconnect-Request. Note that renumbering=
 may not be possible in all> > situations. For example, in order to change =
an IP address on receipt> > of a changed Framed-IP-Address address, IPCP re=
-negotiation could be> > required, which is not supported by all PPP implem=
entations.> > It strikes me that the large number and substantial nature of=
 these notes> suggests that they be incorporated elsewhere in the normative=
 text of the> document, rather as footnotes to the Table of Attributes. I t=
hink it would> substantially enhance readability of the document.=20
=20
I will move Notes 6 and 7 into the main text. =

--_2536ed29-6ee9-422d-bc0e-b6afeba1fc08_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&gt; s/so that the User-Name may not be/because the User-Name may not be/<B=
R><BR>
Got it. <BR>
&nbsp;<BR>&gt; &gt; Where the Acct-Session-Id attribute is not present in a=
 CoA-Request<BR>&gt; &gt; or Disconnect-Request, it is possible that the Us=
er-Name or<BR>&gt; &gt; Chargeable-User-Identity attributes will not be suf=
ficient to<BR>&gt; &gt; uniquely identify the session (e.g. if the same use=
r has multiple<BR>&gt; &gt; sessions on the NAS). As a result, the Called-S=
tation-Id, Calling-<BR>&gt; &gt; Station-Id, NAS-Port, NAS-Port-Id and Acct=
-Multi-Session-Id<BR>&gt; &gt; attributes MAY be used for session identific=
ation in addition.<BR>&gt; <BR>&gt; s/MAY be used for session identificatio=
n in addition./MAY be used as<BR>&gt; additional session identification./<B=
R>
&nbsp;<BR>
Here is a rewritten paragraph:<BR>
&nbsp;<BR>
Where the Acct-Session-Id or Acct-Multi-Session-Id attributes are not prese=
nt in&nbsp; a CoA-Request or Disconnect-Request, it is possible that the Us=
er-Name or Chargeable-User-Identity attributes will not be sufficient to un=
iquely identify the session (e.g. if the same<BR>user has multiple sessions=
 on the NAS, or the privacy NAI is used). As a result, the Called-Station-I=
d, Calling-Station-Id, NAS-Port and NAS-Port-Id attributes MAY be used as a=
dditional session identification.<BR>&nbsp;<BR>&gt; &gt; [Note 6] Support f=
or the Service-Type of "Authorize Only" is OPTIONAL<BR>&gt; &gt; on the NAS=
 and RADIUS server. A NAS supporting the "Authorize Only"<BR>&gt; &gt; Serv=
ice-Type value within a CoA-Request packet MUST respond with a<BR>&gt; &gt;=
 CoA-NAK containing a Service-Type Attribute with value "Authorize<BR>&gt; =
&gt; Only", and an Error-Cause Attribute with value "Request Initiated".<BR=
>&gt; &gt; The NAS then sends an Access-Request to the RADIUS server with a=
<BR>&gt; &gt; Service-Type Attribute with value "Authorize Only". This Acce=
ss-<BR>&gt; &gt; Request SHOULD contain the NAS attributes from the CoA-Req=
uest, as<BR>&gt; &gt; well as the session attributes from the CoA-Request l=
egal for<BR>&gt; &gt; inclusion in an Access-Request as specified in [RFC28=
65], [RFC2868],&nbsp;<BR>&gt; &gt; [RFC2869] and [RFC3162]. As noted in [RF=
C2869] Section 5.19, a<BR>&gt; &gt; Message-Authenticator attribute SHOULD =
be included in an Access-<BR>&gt; &gt; Request that does not contain a User=
-Password, CHAP-Password, ARAP-<BR>&gt; &gt; Password or EAP-Message Attrib=
ute. The RADIUS server should send<BR>&gt; &gt; back an Access-Accept to (r=
e-)authorize the session or an Access-<BR>&gt; &gt; Reject to refuse to (re=
-)authorize it.<BR>&gt; &gt; <BR>&gt; &gt; A NAS that does not support the =
Service-Type Attribute with the value<BR>&gt; &gt; "Authorize Only" within =
a CoA-Request MUST respond with a CoA-NAK<BR>&gt; &gt; including no Service=
-Type Attribute; an Error-Cause Attribute with<BR>&gt; &gt; value "Unsuppor=
ted Service" MAY be included.<BR>&gt; &gt; <BR>&gt; &gt; [Note 7] The State=
 Attribute is available to be sent by the RADIUS<BR>&gt; &gt; server to the=
 NAS in a CoA-Request packet and MUST be sent unmodified<BR>&gt; &gt; from =
the NAS to the RADIUS server in a subsequent ACK or NAK packet.<BR>&gt; &gt=
; If a Service-Type Attribute with value "Authorize Only" is included<BR>&g=
t; &gt; in a CoA-Request then a State Attribute MUST be present, and MUST b=
e<BR>&gt; &gt; sent unmodified from the NAS to the RADIUS server in the res=
ulting<BR>&gt; &gt; Access-Request sent to the RADIUS server, if any. The S=
tate<BR>&gt; &gt; Attribute is also available to be sent by the RADIUS serv=
er to the<BR>&gt; &gt; NAS in a CoA-Request that also includes a Terminatio=
n-Action<BR>&gt; &gt; Attribute with the value of RADIUS-Request. If the cl=
ient performs<BR>&gt; &gt; the Termination-Action by sending a new Access-R=
equest upon<BR>&gt; &gt; termination of the current session, it MUST includ=
e the State<BR>&gt; &gt; Attribute unchanged in that Access-Request. In eit=
her usage, the<BR>&gt; &gt; client MUST NOT interpret the Attribute locally=
. A CoA-Request<BR>&gt; &gt; packet must have only zero or one State Attrib=
ute. Usage of the<BR>&gt; &gt; State Attribute is implementation dependent.=
<BR>&gt; &gt; <BR>&gt; &gt; [Note 8] Where included within a CoA-Request, t=
hese attributes<BR>&gt; &gt; represent a renumbering request. Since these a=
ttributes are not used<BR>&gt; &gt; for session identification, they MUST N=
OT be included within a<BR>&gt; &gt; Disconnect-Request. Note that renumber=
ing may not be possible in all<BR>&gt; &gt; situations. For example, in ord=
er to change an IP address on receipt<BR>&gt; &gt; of a changed Framed-IP-A=
ddress address, IPCP re-negotiation could be<BR>&gt; &gt; required, which i=
s not supported by all PPP implementations.<BR>&gt; <BR>&gt; It strikes me =
that the large number and substantial nature of these notes<BR>&gt; suggest=
s that they be incorporated elsewhere in the normative text of the<BR>&gt; =
document, rather as footnotes to the Table of Attributes. I think it would<=
BR>&gt; substantially enhance readability of the document. <BR>
&nbsp;<BR>
I will move Notes 6 and 7 into the main text. <BR></body>
</html>=

--_2536ed29-6ee9-422d-bc0e-b6afeba1fc08_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 17:45:18 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 22 May 2007 13:43:32 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

>      Session identification attributes
>      Chargeable-User-      89   [RFC4372]  The CUI associated with the
>      Identity                              session.  Needed where a
>                                            privacy NAI is used, so that
>                                            the User-Name may not be
>                                            unique (e.g. "anonymous").

s/so that the User-Name may not be/because the User-Name may not be/
 
>    Where the Acct-Session-Id attribute is not present in a CoA-Request
>    or Disconnect-Request, it is possible that the User-Name or
>    Chargeable-User-Identity attributes will not be sufficient to
>    uniquely identify the session (e.g. if the same user has multiple
>    sessions on the NAS).  As a result, the Called-Station-Id, Calling-
>    Station-Id, NAS-Port, NAS-Port-Id and Acct-Multi-Session-Id
>    attributes MAY be used for session identification in addition.

s/MAY be used for session identification in addition./MAY be used as
additional session identification./

>    [Note 1] Where NAS or session identification attributes are included
>    in Disconnect-Request or CoA-Request packets, they are used for
>    identification purposes only.  These attributes MUST NOT be used for
>    purposes other than identification (e.g. within CoA-Request packets
>    to request authorization changes).
> 
>    [Note 2] The Reply-Message Attribute is used to present a displayable
>    message to the user.  The message is only displayed as a result of a
>    successful Disconnect-Request or CoA-Request (where a Disconnect-ACK
>    or CoA-ACK is subsequently sent).  Where EAP is used for
>    authentication, an EAP-Message/Notification-Request Attribute is sent
>    instead, and Disconnect-ACK or CoA-ACK packets contain an EAP-
>    Message/Notification-Response Attribute.
> 
>    [Note 3] When included within a CoA-Request, these attributes
>    represent an authorization change request.  When one of these
>    attributes is omitted from a CoA-Request, the NAS assumes that the
>    attribute value is to remain unchanged.  Attributes included in a
>    CoA-Request replace all existing value(s) of the same attribute(s).
> 
>    [Note 4] When included within a successful Disconnect-Request (where
>    a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
>    sent unmodified by the client to the accounting server in the
>    Accounting Stop packet.  If the Disconnect-Request is unsuccessful,
>    then the Class Attribute is not processed.
> 
>    [Note 5] When included within a CoA-Request, these attributes
>    represent an authorization change request.  Where tunnel attribute(s)
>    are included within a successful CoA-Request, all existing tunnel
>    attributes are removed and replaced by the new attribute(s).
> 
>    [Note 6] Support for the Service-Type of "Authorize Only" is OPTIONAL
>    on the NAS and RADIUS server.  A NAS supporting the "Authorize Only"
>    Service-Type value within a CoA-Request packet MUST respond with a
>    CoA-NAK containing a Service-Type Attribute with value "Authorize
>    Only", and an Error-Cause Attribute with value "Request Initiated".
>    The NAS then sends an Access-Request to the RADIUS server with a
>    Service-Type Attribute with value "Authorize Only".  This Access-
>    Request SHOULD contain the NAS attributes from the CoA-Request, as
>    well as the session attributes from the CoA-Request legal for
>    inclusion in an Access-Request as specified in [RFC2865], [RFC2868],
> 
>    [RFC2869] and [RFC3162].  As noted in [RFC2869] Section 5.19, a
>    Message-Authenticator attribute SHOULD be included in an Access-
>    Request that does not contain a User-Password, CHAP-Password, ARAP-
>    Password or EAP-Message Attribute.  The RADIUS server should send
>    back an Access-Accept to (re-)authorize the session or an Access-
>    Reject to refuse to (re-)authorize it.
> 
>    A NAS that does not support the Service-Type Attribute with the value
>    "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
>    including no Service-Type Attribute; an Error-Cause Attribute with
>    value "Unsupported Service" MAY be included.
> 
>    [Note 7] The State Attribute is available to be sent by the RADIUS
>    server to the NAS in a CoA-Request packet and MUST be sent unmodified
>    from the NAS to the RADIUS server in a subsequent ACK or NAK packet.
>    If a Service-Type Attribute with value "Authorize Only" is included
>    in a CoA-Request then a State Attribute MUST be present, and MUST be
>    sent unmodified from the NAS to the RADIUS server in the resulting
>    Access-Request sent to the RADIUS server, if any.  The State
>    Attribute is also available to be sent by the RADIUS server to the
>    NAS in a CoA-Request that also includes a Termination-Action
>    Attribute with the value of RADIUS-Request.  If the client performs
>    the Termination-Action by sending a new Access-Request upon
>    termination of the current session, it MUST include the State
>    Attribute unchanged in that Access-Request.  In either usage, the
>    client MUST NOT interpret the Attribute locally.  A CoA-Request
>    packet must have only zero or one State Attribute.  Usage of the
>    State Attribute is implementation dependent.
> 
>    [Note 8] Where included within a CoA-Request, these attributes
>    represent a renumbering request.  Since these attributes are not used
>    for session identification, they MUST NOT be included within a
>    Disconnect-Request.  Note that renumbering may not be possible in all
>    situations.  For example, in order to change an IP address on receipt
>    of a changed  Framed-IP-Address address, IPCP re-negotiation could be
>    required, which is not supported by all PPP implementations.

It strikes me that the large number and substantial nature of these notes
suggests that they be incorporated elsewhere in the normative text of the
document, rather as footnotes to the Table of Attributes.  I think it would
substantially enhance readability of the document. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 17:31:53 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Issue:  Error-Cause Attribute in Disconnect-ACK?
Date: Tue, 22 May 2007 10:31:40 -0700

Issue:  Error-Cause Attribute in Disconnect-ACK?
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: May 22, 2007
Reference:=20
Document: RFC3576bis-05
Comment type: Technical
Priority: S
Section: 3.4
Rationale/Explanation of issue:

In the process of editing the attribute table to address Issue 226, I notic=
ed an oddity.=20

RFC 3576 Section 3.1 states the following:

      It is possible that the NAS cannot honor Disconnect-Request or
      CoA-Request messages for some reason.  The Error-Cause Attribute
      provides more detail on the cause of the problem.  It MAY be
      included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
      messages.

Why would an Error-Cause Attribute be included in a Disconnect-ACK?  It is =
not allowed in a CoA-ACK, for example. =

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 17:21:36 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Tue, 22 May 2007 10:21:19 -0700

In looking at this, it is not clear to me why Framed-IP-Address, Framed-IPv=
6-Prefix, Framed-Interface-Id, Originating-Line-Info or NAS-Port-Type are l=
isted as identification attributes.  As noted earlier,  if only an Access-R=
equest is available, then User-Name and either NAS-Port/NAS-Port-Id or Call=
ed/Calling-Station-Id should be sufficient;  if an Accounting-Request is re=
ceived, then Acct-Session-Id or maybe Acct-Multi-Session-Id should be suffi=
cient. =20

As a result, I'd propose that Sections 3 and 3.4 be rewritten as below.=20

3.  Attributes

   In Disconnect-Request and CoA-Request packets, certain attributes are
   used to uniquely identify the NAS as well as a user session on the
   NAS.  All NAS identification attributes included in a Request packet
   MUST match in order for a Disconnect-Request or CoA-Request to be
   successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
   For session identification attributes, the User-Name and Acct-
   Session-Id Attributes, if included, MUST match in order for a
   Disconnect-Request or CoA-Request to be successful; other session
   identification attributes SHOULD match.  Where a mismatch of session
   identification attributes is detected, a Disconnect-NAK or CoA-NAK
   SHOULD  be sent.

   The ability to use NAS or session identification attributes to map to
   unique/multiple sessions is beyond the scope of this document.
   Identification attributes include NAS and session identification
   attributes, as described below.

     NAS identification attributes

     Attribute             #    Reference  Description
     ---------            ---   ---------  -----------
     NAS-IP-Address        4    [RFC2865]  The IPv4 address of the NAS.
     NAS-Identifier       32    [RFC2865]  String identifying the NAS.
     NAS-IPv6-Address     95    [RFC3162]  The IPv6 address of the NAS.

     Session identification attributes

     Attribute              #   Reference  Description
     ---------             ---  ---------  -----------
     User-Name              1   [RFC2865]  The name of the user
                                           associated with the session.
     NAS-Port               5   [RFC2865]  The port on which the
                                           session is terminated

     Attribute              #   Reference  Description
     ---------             ---  ---------  -----------
     Called-Station-Id     30   [RFC2865]  The link address to which
                                           the session is connected.
     Calling-Station-Id    31   [RFC2865]  The link address from which
                                           the session is connected.
     Acct-Session-Id       44   [RFC2866]  The identifier uniquely
                                           identifying the session
                                           on the NAS.
     Acct-Multi-Session-Id 50   [RFC2866]  The identifier uniquely
                                           identifying related sessions.
     NAS-Port-Id           87   [RFC2869]  String identifying the port
                                           where the session is.
     Chargeable-User-      89   [RFC4372]  The CUI associated with the
     Identity                              session.  Needed where a
                                           privacy NAI is used, so that
                                           the User-Name may not be
                                           unique (e.g. "anonymous").

   To address security concerns described in Section 6.1, either the
   User-Name or Chargeable-User-Identity attribute SHOULD be present in
   Disconnect-Request and CoA-Request packets.

   Where a Diameter client utilizes the same Session-Id for both
   authorization and accounting, inclusion of an Acct-Session-Id
   Attribute in a Disconnect-Request or CoA-Request can assist with
   Diameter/RADIUS translation, since Diameter RAR and ASR commands
   include a Session-Id AVP.  An Acct-Session-Id attribute SHOULD be
   included in Disconnect-Request and CoA-Request packets.

   Where the Acct-Session-Id attribute is not present in a CoA-Request
   or Disconnect-Request, it is possible that the User-Name or
   Chargeable-User-Identity attributes will not be sufficient to
   uniquely identify the session (e.g. if the same user has multiple
   sessions on the NAS).  As a result, the Called-Station-Id, Calling-
   Station-Id, NAS-Port, NAS-Port-Id and Acct-Multi-Session-Id
   attributes MAY be used for session identification in addition.

   To address security concerns described in Section 6.2, one or more of
   the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present
   in Disconnect-Request and CoA-Request packets; the NAS-Identifier
   Attribute MAY be present.

   If one or more authorization changes specified in a CoA-Request
   cannot be carried out, or if one or more attributes or attribute-
   values is unsupported, a CoA-NAK MUST be sent.  Similarly, if there
   are one or more unsupported attributes or attribute values in a
   Disconnect-Request, a Disconnect-NAK MUST be sent.

   A CoA-Request containing a Service-Type Attribute with value
   "Authorize Only" MUST contain only NAS or session identification
   attributes, as well as Service-Type and State attributes.  If other
   attributes are included in such a CoA-Request, implementations MUST
   send a CoA-NAK; an Error-Cause Attribute with value "Unsupported
   Attribute" MAY be included.

   A Disconnect-Request MUST contain only NAS and session identification
   attributes (see Section 3).  If other attributes are included in a
   Disconnect-Request, implementations MUST send a Disconnect-NAK; an
   Error-Cause Attribute with value "Unsupported Attribute" MAY be
   included.

3.4.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which packets, and in what quantity.

   Change-of-Authorization Messages

   Request   ACK      NAK   #   Attribute
   0-1       0        0     1   User-Name [Note 1]
   0-1       0        0     4   NAS-IP-Address [Note 1]
   0-1       0        0     5   NAS-Port [Note 1]
   0-1       0        0-1   6   Service-Type [Note 6]
   0-1       0        0     7   Framed-Protocol [Note 3]
   0-1       0        0     8   Framed-IP-Address [Note 8]
   0-1       0        0     9   Framed-IP-Netmask [Note 8]
   0-1       0        0    10   Framed-Routing [Note 3]
   0+        0        0    11   Filter-ID [Note 3]
   0-1       0        0    12   Framed-MTU [Note 3]
   0+        0        0    13   Framed-Compression [Note 3]
   0+        0        0    14   Login-IP-Host [Note 3]
   0-1       0        0    15   Login-Service [Note 3]
   0-1       0        0    16   Login-TCP-Port [Note 3]
   0+        0        0    18   Reply-Message [Note 2]
   Request   ACK      NAK   #   Attribute

   Request   ACK      NAK   #   Attribute
   0-1       0        0    19   Callback-Number [Note 3]
   0-1       0        0    20   Callback-Id [Note 3]
   0+        0        0    22   Framed-Route [Note 3]
   0-1       0        0    23   Framed-IPX-Network [Note 8]
   0-1       0-1      0-1  24   State [Note 7]
   0+        0        0    25   Class [Note 3]
   0+        0        0    26   Vendor-Specific [Note 3]
   0-1       0        0    27   Session-Timeout [Note 3]
   0-1       0        0    28   Idle-Timeout [Note 3]
   0-1       0        0    29   Termination-Action [Note 3]
   0-1       0        0    30   Called-Station-Id [Note 1]
   0-1       0        0    31   Calling-Station-Id [Note 1]
   0-1       0        0    32   NAS-Identifier [Note 1]
   0+        0+       0+   33   Proxy-State
   0-1       0        0    34   Login-LAT-Service [Note 3]
   0-1       0        0    35   Login-LAT-Node [Note 3]
   0-1       0        0    36   Login-LAT-Group [Note 3]
   0-1       0        0    37   Framed-AppleTalk-Link [Note 3]
   0+        0        0    38   Framed-AppleTalk-Network [Note 3]
   0-1       0        0    39   Framed-AppleTalk-Zone [Note 3]
   0-1       0        0    44   Acct-Session-Id [Note 1]
   0-1       0        0    50   Acct-Multi-Session-Id [Note 1]
   0-1       0-1      0-1  55   Event-Timestamp
   0+        0        0    56   Egress-VLANID [Note 3]
   0-1       0        0    57   Ingress-Filters [Note 3]
   0+        0        0    58   Egress-VLAN-Name [Note 3]
   0-1       0        0    59   User-Priority-Table [Note 3]
   0-1       0        0    61   NAS-Port-Type [Note 3]
   0-1       0        0    62   Port-Limit [Note 3]
   0-1       0        0    63   Login-LAT-Port [Note 3]
   0+        0        0    64   Tunnel-Type [Note 5]
   0+        0        0    65   Tunnel-Medium-Type [Note 5]
   0+        0        0    66   Tunnel-Client-Endpoint [Note 5]
   0+        0        0    67   Tunnel-Server-Endpoint [Note 5]
   0+        0        0    69   Tunnel-Password [Note 5]
   0-1       0        0    71   ARAP-Features [Note 3]
   0-1       0        0    72   ARAP-Zone-Access [Note 3]
   0+        0        0    78   Configuration-Token [Note 3]
   0+        0-1      0    79   EAP-Message [Note 2]
   0-1       0-1      0-1  80   Message-Authenticator
   0+        0        0    81   Tunnel-Private-Group-ID [Note 5]
   0+        0        0    82   Tunnel-Assignment-ID [Note 5]
   0+        0        0    83   Tunnel-Preference [Note 5]
   0-1       0        0    85   Acct-Interim-Interval [Note 3]
   0-1       0        0    87   NAS-Port-Id [Note 1]
   0-1       0        0    88   Framed-Pool [Note 8]
   Request   ACK      NAK   #   Attribute

   Request   ACK      NAK   #   Attribute
   0-1       0        0    89   Chargeable-User-Identity [Note 1]
   0+        0        0    90   Tunnel-Client-Auth-ID [Note 5]
   0+        0        0    91   Tunnel-Server-Auth-ID [Note 5]
   0-1       0        0    92   NAS-Filter-Rule [Note 3]
   0         0        0    94   Originating-Line-Info
   0-1       0        0    95   NAS-IPv6-Address [Note 1]
   0-1       0        0    96   Framed-Interface-Id [Note 8]
   0+        0        0    97   Framed-IPv6-Prefix [Note 8]
   0+        0        0    98   Login-IPv6-Host [Note 3]
   0+        0        0    99   Framed-IPv6-Route [Note 3]
   0-1       0        0   100   Framed-IPv6-Pool [Note 8]
   0         0        0+  101   Error-Cause
   0+        0        0   123   Delegated-IPv6-Prefix [Note 8]
   Request   ACK      NAK   #   Attribute

   Disconnect Messages

   Request   ACK      NAK   #   Attribute
   0-1       0        0     1   User-Name [Note 1]
   0-1       0        0     4   NAS-IP-Address [Note 1]
   0-1       0        0     5   NAS-Port [Note 1]
   0         0        0     6   Service-Type
   0         0        0     8   Framed-IP-Address [Note 8]
   0+        0        0    18   Reply-Message [Note 2]
   0         0        0    24   State
   0+        0        0    25   Class [Note 4]
   0+        0        0    26   Vendor-Specific
   0-1       0        0    30   Called-Station-Id [Note 1]
   0-1       0        0    31   Calling-Station-Id [Note 1]
   0-1       0        0    32   NAS-Identifier [Note 1]
   0+        0+       0+   33   Proxy-State
   0-1       0        0    44   Acct-Session-Id [Note 1]
   0-1       0-1      0    49   Acct-Terminate-Cause
   0-1       0        0    50   Acct-Multi-Session-Id [Note 1]
   0-1       0-1      0-1  55   Event-Timestamp
   0         0        0    61   NAS-Port-Type
   0+        0-1      0    79   EAP-Message [Note 2]
   0-1       0-1      0-1  80   Message-Authenticator
   0-1       0        0    87   NAS-Port-Id [Note 1]
   0-1       0        0    89   Chargeable-User-Identity [Note 1]
   0-1       0        0    95   NAS-IPv6-Address [Note 1]
   0         0        0    96   Framed-Interface-Id [Note 8]
   0         0        0    97   Framed-IPv6-Prefix [Note 8]
   0         0        0   100   Framed-IPv6-Pool [Note 8]
   0         0        0+  101   Error-Cause
   Request   ACK      NAK   #   Attribute

   The following table defines the meaning of the above table entries.

0     This attribute MUST NOT be present in packet.
0+    Zero or more instances of this attribute MAY be present in packet.
0-1   Zero or one instance of this attribute MAY be present in packet.
1     Exactly one instance of this attribute MUST be present in packet.

   [Note 1] Where NAS or session identification attributes are included
   in Disconnect-Request or CoA-Request packets, they are used for
   identification purposes only.  These attributes MUST NOT be used for
   purposes other than identification (e.g. within CoA-Request packets
   to request authorization changes).

   [Note 2] The Reply-Message Attribute is used to present a displayable
   message to the user.  The message is only displayed as a result of a
   successful Disconnect-Request or CoA-Request (where a Disconnect-ACK
   or CoA-ACK is subsequently sent).  Where EAP is used for
   authentication, an EAP-Message/Notification-Request Attribute is sent
   instead, and Disconnect-ACK or CoA-ACK packets contain an EAP-
   Message/Notification-Response Attribute.

   [Note 3] When included within a CoA-Request, these attributes
   represent an authorization change request.  When one of these
   attributes is omitted from a CoA-Request, the NAS assumes that the
   attribute value is to remain unchanged.  Attributes included in a
   CoA-Request replace all existing value(s) of the same attribute(s).

   [Note 4] When included within a successful Disconnect-Request (where
   a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
   sent unmodified by the client to the accounting server in the
   Accounting Stop packet.  If the Disconnect-Request is unsuccessful,
   then the Class Attribute is not processed.

   [Note 5] When included within a CoA-Request, these attributes
   represent an authorization change request.  Where tunnel attribute(s)
   are included within a successful CoA-Request, all existing tunnel
   attributes are removed and replaced by the new attribute(s).

   [Note 6] Support for the Service-Type of "Authorize Only" is OPTIONAL
   on the NAS and RADIUS server.  A NAS supporting the "Authorize Only"
   Service-Type value within a CoA-Request packet MUST respond with a
   CoA-NAK containing a Service-Type Attribute with value "Authorize
   Only", and an Error-Cause Attribute with value "Request Initiated".
   The NAS then sends an Access-Request to the RADIUS server with a
   Service-Type Attribute with value "Authorize Only".  This Access-
   Request SHOULD contain the NAS attributes from the CoA-Request, as
   well as the session attributes from the CoA-Request legal for
   inclusion in an Access-Request as specified in [RFC2865], [RFC2868],

   [RFC2869] and [RFC3162].  As noted in [RFC2869] Section 5.19, a
   Message-Authenticator attribute SHOULD be included in an Access-
   Request that does not contain a User-Password, CHAP-Password, ARAP-
   Password or EAP-Message Attribute.  The RADIUS server should send
   back an Access-Accept to (re-)authorize the session or an Access-
   Reject to refuse to (re-)authorize it.

   A NAS that does not support the Service-Type Attribute with the value
   "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
   including no Service-Type Attribute; an Error-Cause Attribute with
   value "Unsupported Service" MAY be included.

   [Note 7] The State Attribute is available to be sent by the RADIUS
   server to the NAS in a CoA-Request packet and MUST be sent unmodified
   from the NAS to the RADIUS server in a subsequent ACK or NAK packet.
   If a Service-Type Attribute with value "Authorize Only" is included
   in a CoA-Request then a State Attribute MUST be present, and MUST be
   sent unmodified from the NAS to the RADIUS server in the resulting
   Access-Request sent to the RADIUS server, if any.  The State
   Attribute is also available to be sent by the RADIUS server to the
   NAS in a CoA-Request that also includes a Termination-Action
   Attribute with the value of RADIUS-Request.  If the client performs
   the Termination-Action by sending a new Access-Request upon
   termination of the current session, it MUST include the State
   Attribute unchanged in that Access-Request.  In either usage, the
   client MUST NOT interpret the Attribute locally.  A CoA-Request
   packet must have only zero or one State Attribute.  Usage of the
   State Attribute is implementation dependent.

   [Note 8] Where included within a CoA-Request, these attributes
   represent a renumbering request.  Since these attributes are not used
   for session identification, they MUST NOT be included within a
   Disconnect-Request.  Note that renumbering may not be possible in all
   situations.  For example, in order to change an IP address on receipt
   of a changed  Framed-IP-Address address, IPCP re-negotiation could be
   required, which is not supported by all PPP implementations.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 17:12:15 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: FW: draft-ietf-radext-fixes-03 LC comments
Date: Tue, 22 May 2007 10:12:01 -0700

=20
> > -----Original Message-----
> > From: Alfred H=CEnes [mailto:[email-masked]]
> > Sent: Sunday, May 20, 2007 2:54 PM
> > To: [email-masked]; [email-masked]
> > Subject: draft-ietf-radext-fixes-03 LC comments
> >=20
> > Hello,
> > after studying the Internet-Draft in IETF LC authored by you,
> >    draft-ietf-radext-fixes-03 ,
> > I'd like to submit a few comment pointing out a few out textual
> > issues, and a procedural issue I found with that document.
> >=20
> >=20
> > (1)  meta-data / procedural issue
> >=20
> > The heading of the draft says:
> >   Updates: 2865, 2866, 2869, 3579
> > and the draft is intended for the IETF Standards Track.
> >=20
> > Now although RFC 2865 currently is a Draft Standard,
> > unfortunately the other three memos, RFC 2866, RFC 2869,
> > and RFC 3579 have benn published as Informational RFCs
> > and never been advanced onto the Standards Track.
> >=20
> > I am in serious doubt whether is conforms with the
> > established IETF Standards Track procedures to have a
> > document on the Standards Track update documents not on
> > the Standards Track.
> > Perhaps, the problem is not with the draft, but with the
> > three Informational RFCs which usually are seen as a part
> > of "the" RADIUS specification; it might be advantageous,
> > after all the implementation experience at large, to bring
> > these documents to Proposed Standard level - before or
> > together with the publication of this draft as an RFC.
> >=20
> >=20
> > (2)  Section 2.2.2 -- typo
> >=20
> > At the end of the first paragraph of Section 2.2.2, please
> > change:
> >          "suys"   -->   "says" .
> >=20
> >=20
> > (3)  Section 2.2.2 -- grammar
> >=20
> > The 2nd sentence in the third-to-last paragraph of Section 2.2.2
> > says:
> >=20
> >    Implementations MUST also cache the Responses (Access-Accept, Access=
-
> >    Challenge, or Access-Reject) that is sends for those Access-Request
> >    packets.
> >=20
> > To correct the grammar, it should better say either:
> >=20
> >    vvvv
> > |  An implementation MUST also cache the Responses (Access-Accept,
> > |  Access-Challenge, or Access-Reject) that it sends for those Access-
> >    Request packets.
> >                                            ^^^^
> > or:
> >=20
> >    Implementations MUST also cache the Responses (Access-Accept, Access=
-
> > |  Challenge, or Access-Reject) they send for those Access-Request
> >    packets.
> >                                ^^^^^^^^^^^
> > or:
> >=20
> >    Implementations MUST also cache the Responses (Access-Accept, Access=
-
> > |  Challenge, or Access-Reject) sent for those Access-Request packets.
> >                                ^^^^^^
> >=20
> > (4)  Section 2.9 -- textual improvement
> >=20
> > In the last paragraph of Section 2.9, please change:
> >=20
> >                     v                                    vvv
> >    "... either omit a User-Name attribute ... or include the Calling-
> >     Station-Id ..."
> >=20
> > I suggest to improve the language to say:
> >=20
> >                     vvv                                    vvv
> > |  "... either omit the User-Name attribute ... or include the Calling-
> >     Station-Id ..."
> >=20
> >=20
> > (5)  outdated Reference, and Section 6
> >=20
> > Hint: [PREFIX] has been published as RFC 4818, in the meantime.
> >=20
> > Hence, the replacements mentioned in Section 6 can be performed
> > immediately, and Section 6 be dropped from the draft.
> >=20
> >=20
> > Kind regards,
> >   Alfred H=CEnes.
> >=20
> > --
> >=20
> > +------------------------+--------------------------------------------+
> > | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> > | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
> > | D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
> > +------------------------+--------------------------------------------+
>=20
>=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 17:00:37 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: FW: Gen-art review of draft-ietf-radext-rfc4590bis-01.txt
Date: Tue, 22 May 2007 09:59:48 -0700

----------------------------------------
> Date: Tue, 22 May 2007 13:57:19 +0300
> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]; dwilli@cisc=
o.com; [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]; =
[email-masked]; [email-masked]
> Subject: Gen-art review of draft-ietf-radext-rfc4590bis-01.txt
>=20
> Hi,
>=20
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>=20
> Please resolve these comments along with any other Last Call comments
> you may receive.
>=20
>=20
> Draft: draft-ietf-radext-rfc4590bis-01.txt
> Reviewer: Gonzalo Camarillo=20
> Review Date: 22 May 2006
>=20
> Summary:
>=20
> This draft is ready for publication as a PS RFC.
>=20
>=20
> Comments:
>=20
> RFC 3579, which appears in the References, is an Informational RFC
> (i.e., it is a down reference).
>=20
> Section 2.1 explains that information sent over a TLS connection to the
> RADIUS client may be sent in cleartext to the RADIUS server, but does
> not give any recommendation on what to do in that case. A further
> explanation or a recommendation would be useful.
>=20
>=20
> Thanks,
>=20
> Gonzalo
>=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 05:08:34 +0000
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, <[email-masked]>
CC: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Mon, 21 May 2007 22:08:23 -0700

--_db874d93-09b7-43b6-a903-0721a420ef40_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Glen Zorn said: So, basically, what you are=20
saying seems to be that=20

 =20
  deploying RADIUS accounting is mandatory=20
  AND
 =20
  an undefined but incestuous relationship between separate RADIUS=20
  and RADIUS Accounting servers is also mandatory OR
 =20
  the RADIUS and RADIUS Accounting servers must be one and the=20
  same
None of those seem like very good ideas to me.This makes sense to me.It is =
possible for a "Dynamic Authorization Client" to send a CoA-Request or Disc=
onnect-Request identifying the NAS and session based purely on information =
present in the Access-Request.  In such a situation, it would seem that a U=
ser-Name attribute, NAS-Port/NAS-Port-Id and a NAS identification attribute=
 (e.g. NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier) should be sufficie=
nt to identify the session.  If the session was never
started, or the user is no longer there, a
CoA/Disconnect-NAK will be sent along with an Error-Cause attribute. It is =
also possible for a "Dynamic Authorization Client" to send a CoA-Request or=
 Disconnect-Request based on an Accounting-Request.  In this case, the Acct=
-Session-Id attribute would be used to identify the session.  The question =
is this:  under what circumstances would other attributes (Called/Calling-S=
tation-Id, NAS-Port-Type, Framed-IP-Address/Framed-IPv6-Prefix/Framed-Ident=
ifer, etc.) ever be needed in order to identify a session?  It seems that C=
alled/Calling-Station-Id would only be needed if NAS-Port/NAS-Port-Id were =
not present (e.g. where the same user was logged on to multiple ports). =20

--_db874d93-09b7-43b6-a903-0721a420ef40_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Glen Zorn said: <blockquote><div dir=3D"ltr" align=3D"left"><span class=3D"=
EC_919101123-21052007"><font color=3D"#0000ff" face=3D"Arial">So, basically=
, what you are=20
saying seems to be that </font></span></div>
<ol dir=3D"ltr">
  <li>
  <div align=3D"left"><span class=3D"EC_919101123-21052007"><font color=3D"=
#0000ff" face=3D"Arial">deploying RADIUS accounting is mandatory=20
  AND</font></span></div></li>
  <li>
  <div align=3D"left"><span class=3D"EC_919101123-21052007"><font color=3D"=
#0000ff" face=3D"Arial">an undefined but incestuous relationship between se=
parate RADIUS=20
  and RADIUS Accounting servers is also mandatory OR</font></span></div></l=
i>
  <li>
  <div align=3D"left"><span class=3D"EC_919101123-21052007"><font color=3D"=
#0000ff" face=3D"Arial">the RADIUS and RADIUS Accounting servers must be on=
e and the=20
  same</font></span></div></li></ol>
<div dir=3D"ltr" align=3D"left"><span class=3D"EC_919101123-21052007"><font=
 color=3D"#0000ff" face=3D"Arial">None of those seem like very good ideas t=
o me.<br></font></span></div></blockquote><div dir=3D"ltr" align=3D"left">T=
his makes sense to me.<br><br>It is possible for a "Dynamic Authorization C=
lient" to send a CoA-Request or Disconnect-Request identifying the NAS and =
session based purely on information present in the Access-Request.&nbsp; In=
 such a situation, it would seem that a User-Name attribute, NAS-Port/NAS-P=
ort-Id and a NAS identification attribute (e.g. NAS-IP-Address, NAS-IPv6-Ad=
dress, NAS-Identifier) should be sufficient to identify the session.&nbsp; =
If the session was never
started, or the user is no longer there, a
CoA/Disconnect-NAK will be sent along with an Error-Cause attribute. <br><b=
r>It is also possible for a "Dynamic Authorization Client" to send a CoA-Re=
quest or Disconnect-Request based on an Accounting-Request.&nbsp; In this c=
ase, the Acct-Session-Id attribute would be used to identify the session.&n=
bsp; <br><br>The question is this:&nbsp; under what circumstances would oth=
er attributes (Called/Calling-Station-Id, NAS-Port-Type, Framed-IP-Address/=
Framed-IPv6-Prefix/Framed-Identifer, etc.) ever be needed in order to ident=
ify a session?&nbsp; It seems that Called/Calling-Station-Id would only be =
needed if NAS-Port/NAS-Port-Id were not present (e.g. where the same user w=
as logged on to multiple ports).&nbsp; <br><span class=3D"EC_919101123-2105=
2007"></span><br><span class=3D"EC_919101123-21052007"></span></div><blockq=
uote><div dir=3D"ltr" align=3D"left"><br><br><span class=3D"EC_919101123-21=
052007"><font color=3D"#0000ff" face=3D"Arial"></font></span></div>
</blockquote></body>
</html>=

--_db874d93-09b7-43b6-a903-0721a420ef40_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 22 May 2007 04:57:06 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RFC 4590 IETF Last Call Comments
Date: Mon, 21 May 2007 21:56:06 -0700

--_0da860cc-de1b-4532-9cdc-035846bfa268_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

From: Frank EllermannDate: Friday, May 18, 2007Subject: Re: Last Call: draf=
t-ietf-radext-rfc4590bis (RADIUS Extension for Digest Authentication) to Pr=
oposed StandardThe IESG wrote:> The IESG has received a request from the RA=
DIUS EXTensions WG (radext)> to consider the following document:> - 'RADIUS=
 Extension for Digest Authentication '>    <draft-ietf-radext-rfc4590bis-01=
.txt> as a Proposed StandardHi, this draft might be also interesting for th=
e 2831bis (SASL) and2617bis (HTTP-AUTH) folks.  From a quick read I found t=
hat the I-Dpicked the "keep backslash as is" approach between client and pr=
oxy,trimming \\ and \" only at the RADIUS server.The other DIGEST-MD5 param=
eters are as always confusing, I don't seeanything related to SASLprep in t=
he draft (it's based on 2617).  Itmentions 2069 backwards compatibility bas=
ed on the absence of "QoP",I'm not sure if that's correct for "md5-sess" wi=
thout "QoP".The draft says that the length of NC is 10, shouldn't that be 8=
 ?The first example has no CNONCE and no NC, my script claims that thisis a=
 fatal error for qop=3Dauth, isn't it ?  RFC 2617 says that it MUSTbe sent =
for a non-empty qop.The password for the 4590 examples isn't shown, therefo=
re I'm unableto check them, even after adjusting the code to treat qop=3Dau=
th withoutCNONCE as 2069 fallback.  Should I treat CNONCE as empty and make=
 upan NC 00000001 ?Without SASLprep the draft IMO needs some "I18N consider=
ations" aboutnon-ASCII user names and passwords as mandated by BCP 18 (RFC =
2277).Frank=

--_0da860cc-de1b-4532-9cdc-035846bfa268_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
From: Frank Ellermann<br>Date: Friday, May 18, 2007<br>Subject: Re: Last Ca=
ll: draft-ietf-radext-rfc4590bis (RADIUS Extension for Digest Authenticatio=
n) to Proposed Standard<br><br>The IESG wrote:<br><br>&gt; The IESG has rec=
eived a request from the RADIUS EXTensions WG (radext)<br>&gt; to consider =
the following document:<br><br>&gt; - 'RADIUS Extension for Digest Authenti=
cation '<br>&gt;&nbsp;&nbsp;&nbsp; &lt;draft-ietf-radext-rfc4590bis-01.txt&=
gt; as a Proposed Standard<br><br>Hi, this draft might be also interesting =
for the 2831bis (SASL) and<br>2617bis (HTTP-AUTH) folks.&nbsp; From a quick=
 read I found that the I-D<br>picked the "keep backslash as is" approach be=
tween client and proxy,<br>trimming \\ and \" only at the RADIUS server.<br=
><br>The other DIGEST-MD5 parameters are as always confusing, I don't see<b=
r>anything related to SASLprep in the draft (it's based on 2617).&nbsp; It<=
br>mentions 2069 backwards compatibility based on the absence of "QoP",<br>=
I'm not sure if that's correct for "md5-sess" without "QoP".<br><br>The dra=
ft says that the length of NC is 10, shouldn't that be 8 ?<br><br>The first=
 example has no CNONCE and no NC, my script claims that this<br>is a fatal =
error for qop=3Dauth, isn't it ?&nbsp; RFC 2617 says that it MUST<br>be sen=
t for a non-empty qop.<br><br>The password for the 4590 examples isn't show=
n, therefore I'm unable<br>to check them, even after adjusting the code to =
treat qop=3Dauth without<br>CNONCE as 2069 fallback.&nbsp; Should I treat C=
NONCE as empty and make up<br>an NC 00000001 ?<br><br>Without SASLprep the =
draft IMO needs some "I18N considerations" about<br>non-ASCII user names an=
d passwords as mandated by BCP 18 (RFC 2277).<br><br>Frank<br></body>
</html>=

--_0da860cc-de1b-4532-9cdc-035846bfa268_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 21 May 2007 23:42:52 +0000
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Mon, 21 May 2007 16:42:33 -0700

--_7e72876c-bf21-4d1f-b0ec-bdb873b4b013_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> From: [email-masked]> To: [email-masked]> Subject: RE=
: Issue 226: RFC 3576bis and Renumbering> Date: Mon, 21 May 2007 14:57:52 -=
0400> > Bernard Aboba writes...> > So my inclination would be to cull the l=
ist to the following:> > > >   Attribute              #    Reference  Descr=
iption> >   ---------             ---   ---------  -----------> >   User-Na=
me              1    [RFC2865]  The name of the user> >                    =
                      associated with the session.> >   Acct-Session-Id    =
   44    [RFC2866]  The identifier uniquely> >                             =
             identifying the session> >                                    =
      on the NAS.> > Are you recommending that the others listed in RFC 357=
6 be deprecated?
If we can't come up with a reason why they should stay, and noone has imple=
mented them already, yes.=

--_7e72876c-bf21-4d1f-b0ec-bdb873b4b013_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<BR><BR>&gt; From: [email-masked]<BR>&gt; To: [email-masked]=
f.org<BR>&gt; Subject: RE: Issue 226: RFC 3576bis and Renumbering<BR>&gt; D=
ate: Mon, 21 May 2007 14:57:52 -0400<BR>&gt; <BR>&gt; Bernard Aboba writes.=
..<BR>&gt; &gt; So my inclination would be to cull the list to the followin=
g:<BR>&gt; &gt;&nbsp;<BR>&gt; &gt;&nbsp;&nbsp; Attribute&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&n=
bsp; Reference&nbsp; Description<BR>&gt; &gt;&nbsp;&nbsp; ---------&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---&nbsp;&=
nbsp; ---------&nbsp; -----------<BR>&gt; &gt;&nbsp;&nbsp; User-Name&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&n=
bsp;&nbsp;&nbsp; [RFC2865]&nbsp; The name of the user<BR>&gt; &gt;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; associated with the session.<BR>&gt; &gt;&nbsp;&nbsp; Acct-Ses=
sion-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44&nbsp;&nbsp;&nbsp; [RFC2866]&=
nbsp; The identifier uniquely<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifying=
 the session<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on the NAS.<BR>&gt; <BR>&gt;=
 Are you recommending that the others listed in RFC 3576 be deprecated?<BR>=
<BR>
If we can't come up with a reason why they should stay, and noone has imple=
mented them already, yes.<BR></body>
</html>=

--_7e72876c-bf21-4d1f-b0ec-bdb873b4b013_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 21 May 2007 23:25:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Mon, 21 May 2007 16:24:44 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C79BFF.37D7DE9A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> I think we'd be better off just making Acct-Session-Id a MUST, and
> ignoring the other attributes.

Making Acct-Session-Id a MUST would ensure Diameter compatibility.=20
User-Name probably needs to be at least a MAY for the same reason. =20
=20
There are just a few problems with this idea (in the absence of RADIUS
accounting).  The first & most obvious is that "sessions" do not exist
in RADIUS.  This is because the RADIUS server has no idea when (or if)
the session ends or, more subtly, if it actually begins.  All the RADIUS
server  knows is that it authorized a session in an Access-Accept; by
the time that message arrived at the NAS, the user might already have
left.  So, basically, what you are saying seems to be that=20

1.=09
	deploying RADIUS accounting is mandatory AND
2.=09
	an undefined but incestuous relationship between separate RADIUS
and RADIUS Accounting servers is also mandatory OR
3.=09
	the RADIUS and RADIUS Accounting servers must be one and the
same

None of those seem like very good ideas to me.  Not to belabor the
point, but all these problems have been thought through and solutions
designed in
http://www.ietf.org/internet-drafts/draft-zorn-radius-logoff-09.txt. =20
=20
 ...=20

------_=_NextPart_001_01C79BFF.37D7DE9A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3086" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>&gt; I think we'd be better off just making=20
Acct-Session-Id a MUST, and<BR>&gt; ignoring the other =
attributes.<BR><BR>Making=20
Acct-Session-Id a MUST would ensure Diameter compatibility. =
<BR>User-Name=20
probably needs to be at least a MAY&nbsp;for the same reason.&nbsp;<SPAN =

class=3D919101123-21052007><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D919101123-21052007></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D919101123-21052007><FONT =
face=3DArial=20
color=3D#0000ff>There are just a few problems with this&nbsp;idea (in =
the absence=20
of RADIUS accounting).&nbsp; The first &amp; most obvious is that =
"sessions" do=20
not exist in RADIUS.&nbsp; This is because the RADIUS server has no idea =
when=20
(or if) the session ends or, more subtly, if it actually begins.&nbsp; =
All the=20
RADIUS server </FONT>&nbsp;<FONT face=3DArial color=3D#0000ff>knows is =
that it=20
authorized a session in an Access-Accept; by the time that message =
arrived at=20
the NAS, the user might already have left.&nbsp; So, basically, what you =
are=20
saying seems to be that </FONT></SPAN></DIV>
<OL dir=3Dltr>
  <LI>
  <DIV align=3Dleft><SPAN class=3D919101123-21052007><FONT face=3DArial=20
  color=3D#0000ff>deploying RADIUS accounting is mandatory=20
  AND</FONT></SPAN></DIV></LI>
  <LI>
  <DIV align=3Dleft><SPAN class=3D919101123-21052007><FONT face=3DArial=20
  color=3D#0000ff>an undefined but incestuous relationship between =
separate RADIUS=20
  and RADIUS Accounting servers is also mandatory =
OR</FONT></SPAN></DIV></LI>
  <LI>
  <DIV align=3Dleft><SPAN class=3D919101123-21052007><FONT face=3DArial=20
  color=3D#0000ff>the RADIUS and RADIUS Accounting servers must be one =
and the=20
  same</FONT></SPAN></DIV></LI></OL>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D919101123-21052007><FONT =
face=3DArial=20
color=3D#0000ff>None of those seem like very good ideas to me.&nbsp; Not =
to=20
belabor&nbsp;the point, but all these problems have been thought through =
and=20
solutions designed in <A=20
href=3D"http://www.ietf.org/internet-drafts/draft-zorn-radius-logoff-09.t=
xt">http://www.ietf.org/internet-drafts/draft-zorn-radius-logoff-09.txt</=
A>.&nbsp;&nbsp;</FONT></SPAN><BR>&nbsp;<BR><SPAN=20
class=3D919101123-21052007><FONT face=3DArial=20
color=3D#0000ff>&nbsp;...&nbsp;</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C79BFF.37D7DE9A--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 21 May 2007 18:59:56 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Mon, 21 May 2007 14:57:52 -0400
Organization: Elbrys Networks, Inc.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 21 May 2007 15:16:36 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Mon, 21 May 2007 08:15:38 -0700

--_33d3d403-7142-437c-8559-ff3e8a63a8f7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I think we'd be better off just making Acct-Session-Id a MUST, and> ignor=
ing the other attributes.
Making Acct-Session-Id a MUST would ensure Diameter compatibility.=20
User-Name probably needs to be at least a MAY for the same reason.=20
=20
I would agree that the other attributes are of dubious utility.=20
=20
For example, where the IP address isn't assigned by the NAS=20
(e.g. L2 access device)  neither the RADIUS server nor the NAS=20
may know the IP address associated with the session.  In this case=20
it doesn't make sense to send a CoA-Request with IP address session=20
identification attributes. =20
=20
Even if the NAS does assign the IP address (e.g. PPP), PPP peers typically
cannot renegotiate IPCP in mid-stream, so that a request to change the
IP address in mid-session cannot be carried out.   About the only address
change attribute that makes sense is Framed-IPv6-Prefix, since a changed
Framed-IPv6-Prefix can result in a changed RA. =20
=20
However, in -04 this has to be done in two steps since Framed-IPv6-Prefix
and Framed-Interface-Id are reserved for session identification.
=20
So it makes sense to remove the IP address session identification attribute=
s=20
and allowing Framed-IPv6-Prefix to be included in a CoA-Request.=20
=20
Similarly, I struggle to understand the use of Called/Calling-Station-Id as
session identification attributes.  As you note, a RADIUS server would
have the mapping between Called/Calling-Station-Id and Acct-Session-Id,
so there is no need to ask the NAS to do the work itself.=20
=20
So my inclination would be to cull the list to the following:
=20
   Attribute              #    Reference  Description   ---------          =
   ---   ---------  -----------   User-Name              1    [RFC2865]  Th=
e name of the user                                          associated with=
 the session.   Acct-Session-Id       44    [RFC2866]  The identifier uniqu=
ely                                          identifying the session       =
                                   on the NAS.=

--_33d3d403-7142-437c-8559-ff3e8a63a8f7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&gt; I think we'd be better off just making Acct-Session-Id a MUST, and<BR>=
&gt; ignoring the other attributes.<BR><BR>
Making Acct-Session-Id a MUST would ensure Diameter compatibility. <BR>
User-Name probably needs to be at least a MAY&nbsp;for the same reason. <BR=
>
&nbsp;<BR>
I would agree that&nbsp;the other attributes are of dubious utility. <BR>
&nbsp;<BR>
For example, where the IP address isn't assigned by the NAS <BR>
(e.g. L2 access device)&nbsp; neither the RADIUS server nor the NAS <BR>
may know the IP address associated with the session.&nbsp; In this case <BR=
>
it doesn't make sense to send a CoA-Request with IP address session <BR>
identification attributes.&nbsp; <BR>
&nbsp;<BR>
Even if the NAS does assign the IP address (e.g. PPP), PPP peers typically<=
BR>
cannot renegotiate IPCP in mid-stream, so that a request to change the<BR>
IP address in mid-session cannot be carried out.&nbsp;&nbsp; About the only=
 address<BR>
change attribute that makes sense is Framed-IPv6-Prefix, since a changed<BR=
>
Framed-IPv6-Prefix can result in a changed RA.&nbsp; <BR>
&nbsp;<BR>
However, in -04 this has to be done in two steps since Framed-IPv6-Prefix<B=
R>
and Framed-Interface-Id are reserved for session identification.<BR>
&nbsp;<BR>
So it makes sense to remove the IP address session identification attribute=
s <BR>
and allowing Framed-IPv6-Prefix to be included in a CoA-Request. <BR>
&nbsp;<BR>
Similarly, I struggle to understand the use of Called/Calling-Station-Id as=
<BR>
session identification attributes.&nbsp; As you note, a RADIUS server would=
<BR>
have the mapping between Called/Calling-Station-Id and Acct-Session-Id,<BR>
so there is no need to ask the NAS to do the&nbsp;work itself. <BR>
&nbsp;<BR>
So my inclination would be to cull the list to the following:<BR>
&nbsp;<BR>
&nbsp;&nbsp; Attribute&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; #&nbsp;&nbsp;&nbsp; Reference&nbsp; Description<B=
R>&nbsp;&nbsp; ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; ---&nbsp;&nbsp; ---------&nbsp; -----------<BR>&nbsp;=
&nbsp; User-Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp; [RFC2865]&nbsp; The name of the use=
r<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; associated with the session.<BR>&nbsp;&nbsp; Acc=
t-Session-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44&nbsp;&nbsp;&nbsp; [RFC2=
866]&nbsp; The identifier uniquely<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifying the=
 session<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on the NAS.<BR></body>
</html>=

--_33d3d403-7142-437c-8559-ff3e8a63a8f7_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 21 May 2007 03:29:25 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Sun, 20 May 2007 20:28:36 -0700

> If the NAS is sending Acct-Session-Id, why not just use that to identify =
the session?=20

This is the approach taken by Diameter.  This suggests to me that the inclu=
sion of an Acct-Session-Id attribute should be at least recommended.=20

For example, a Diameter Abort Session Request includes a mandatory Session-=
Id and optional User-Name AVP ([RFC3588] Section 8.5.1).  Similarly, a Diam=
eter Re-Auth-Request also includes a mandatory Session-Id and optional User=
-Name AVP ([RFC3588] Section 8.3.1).

        ::=3D < Diameter Header: 274, REQ, PXY >
                 < Session-Id >
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { Destination-Host }
                 { Auth-Application-Id }
                 [ User-Name ]
                 [ Origin-State-Id ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

        ::=3D < Diameter Header: 258, REQ, PXY >
                 < Session-Id >
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { Destination-Host }
                 { Auth-Application-Id }
                 { Re-Auth-Request-Type }
                 [ User-Name ]
                 [ Origin-State-Id ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

In contrast to the simple approach taken in RFC 3588, RFC 3576 included sup=
port for a wider range of identification attributes:

   Attribute              #    Reference  Description
   ---------             ---   ---------  -----------
   User-Name              1    [RFC2865]  The name of the user
                                          associated with the session.
   NAS-Port               5    [RFC2865]  The port on which the
                                          session is terminated.
   Framed-IP-Address      8    [RFC2865]  The IPv4 address associated
                                          with the session.
   Called-Station-Id     30    [RFC2865]  The link address to which
                                          the session is connected.
   Calling-Station-Id    31    [RFC2865]  The link address from which
                                          the session is connected.
   Acct-Session-Id       44    [RFC2866]  The identifier uniquely
                                          identifying the session
                                          on the NAS.
   Acct-Multi-Session-Id 50    [RFC2866]  The identifier uniquely
                                          identifying related sessions.
   NAS-Port-Type         61    [RFC2865]  The type of port used.
   NAS-Port-Id           87    [RFC2869]  String identifying the port
                                          where the session is.
   Originating-Line-Info 94    [NASREQ]   Provides information on the
                                          characteristics of the line
                                          from which a session
                                          originated.
   Framed-Interface-Id   96    [RFC3162]  The IPv6 Interface Identifier
                                          associated with the session;
                                          always sent with
                                          Framed-IPv6-Prefix.
   Framed-IPv6-Prefix    97    [RFC3162]  The IPv6 prefix associated
                                          with the session, always sent
                                          with Framed-Interface-Id.

> If the NAS isn't sending it (or isn't sending accounting packets at all),=
 then the proposal above already suggests
> changing the NAS behavior.  Why not just require sending Acct-Session-Id =
in all Access-Requests?

If there are no accounting packets, I'm not sure how the RADIUS server can =
know that the session did in fact start.  So I think it is reasonable to as=
sume that an Accounting-Request was sent and that it contained an Acct-Sess=
ion-Id.   However, the entity sending an RFC 3576 packet may not necessaril=
y have access to either authentication or accounting data.  It could, for e=
xample, be an IDS system.   So I'm not sure we can mandate Acct-Session-Id.=
=20

Here's what RFC 3576 says about session-identification attributes:

   To address security concerns described in Section 5.1., the User-Name
   Attribute SHOULD be present in Disconnect-Request or CoA-Request
   packets; one or more additional session identification attributes MAY
   also be present.  To address security concerns described in Section
   5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address
   Attributes SHOULD be present in Disconnect-Request or CoA-Request
   packets; the NAS-Identifier Attribute MAY be present in addition.

My suggestion would be to add Acct-Session-Id to the list of SHOULDs.=20

The question in my mind is how big the list of MAYs should be.=20

In case the Acct-Session-Id is not available for some reason, then the User=
-Name attribute may not be sufficient to identify a session, so that other =
attributes might be necessary.  For example, I can see including NAS-Port/N=
AS-Port-Id to specify the port.=20

However, I'm still not sure that all of the MAY attributes are really neces=
sary.  If Session-Id is present this should be sufficient.  If this is not =
present, then User-Name and NAS-Port/NAS-Port-Id should be cover it.  It is=
 not easy for me to imagine a scenario in which these attributes would not =
be available, but the other attributes would be. =

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 20 May 2007 21:29:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Sun, 20 May 2007 14:28:50 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Alan DeKok <> allegedly scribbled on Sunday, May 20, 2007 5:53 AM:

> Bernard Aboba wrote:
>> The problem described in this issue is that a CoA-Request packet
>> cannot be used for renumbering.  This is because RFC 3576 defines the
>> Framed-IP-Address, Framed-IPv6-Prefix and Framed-Interface-Id
>> attributes as session identification attributes.
>=20
>   Looking at issues & fixes, I'm not sure why we didn't require all
> NASes to generate a unique session ID in the Access-Request packet.=20
> Once that's done, the session can be identified by that ID, rather
> than by an ad-hoc collection of network identifiers that are
> protocol-specific. =20
>=20

Me, neither: I've been advocating just that for several years now
(http://www.ietf.org/internet-drafts/draft-zorn-radius-logoff-09.txt).
The proposal has been essentially ignored, however, so I expect that
I'll be submitting it to the RFC Editor as an individual submission
shortly.

>> I'd like to put forward a potential approach to address this concern,
>> which is to introduce two new attributes, User-IPv4-Address and
>> User-IPv6-Address, in order to identify a session by IP address.=20
>> This would allow the Framed-IP-Address, Framed-IPv6-Prefix,
>> Framed-Interface-Id and Delegated-IPv6-Address attributes to be
>> included for the purpose of renumbering.
>=20
>   If the NAS is sending Acct-Session-Id, why not just use that to
> identify the session?  If the NAS isn't sending it (or isn't sending
> accounting packets at all), then the proposal above already suggests
> changing the NAS behavior.  Why not just require sending
> Acct-Session-Id in all Access-Requests?   =20
>=20
>   If that is unacceptable, then your proposal seems reasonable.  But
> I'm wary of adding duplicate attributes for niche solutions.=20
>=20
>   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 20 May 2007 12:54:37 +0000
Date: Sun, 20 May 2007 14:53:28 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue 226:  RFC 3576bis and Renumbering

Bernard Aboba wrote:
> The problem described in this issue is that a CoA-Request packet cannot
> be used for renumbering.  This is because RFC 3576 defines the
> Framed-IP-Address, Framed-IPv6-Prefix and Framed-Interface-Id attributes
> as session identification attributes.

  Looking at issues & fixes, I'm not sure why we didn't require all
NASes to generate a unique session ID in the Access-Request packet.
Once that's done, the session can be identified by that ID, rather than
by an ad-hoc collection of network identifiers that are protocol-specific.

> I'd like to put forward a potential approach to address this concern,
> which is to introduce two new attributes, User-IPv4-Address and
> User-IPv6-Address, in order to identify a session by IP address.  This
> would allow the Framed-IP-Address, Framed-IPv6-Prefix,
> Framed-Interface-Id and Delegated-IPv6-Address attributes to be included
> for the purpose of renumbering.

  If the NAS is sending Acct-Session-Id, why not just use that to
identify the session?  If the NAS isn't sending it (or isn't sending
accounting packets at all), then the proposal above already suggests
changing the NAS behavior.  Why not just require sending Acct-Session-Id
in all Access-Requests?

  If that is unacceptable, then your proposal seems reasonable.  But I'm
wary of adding duplicate attributes for niche solutions.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 20 May 2007 06:13:53 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Re: Issue 226:  RFC 3576bis and Renumbering
Date: Sat, 19 May 2007 23:12:42 -0700

--_f045cd0f-0cbd-4209-a48c-094e7e4a7e83_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The problem described in this issue is that a CoA-Request packet cannot be =
used for renumbering.  This is because RFC 3576 defines the Framed-IP-Addre=
ss, Framed-IPv6-Prefix and Framed-Interface-Id attributes as session identi=
fication attributes. RFC 3576bis-04 advocates use of the Service-Type value=
 of "Authorize-Only" in order to enable renumbering.  It has been pointed o=
ut that this is inefficient, requiring two exchanges (a CoA-Request/CoA-ACK=
 and then an Access-Request/Access-Accept) when only one should be required=
. I'd like to put forward a potential approach to address this concern, whi=
ch is to introduce two new attributes, User-IPv4-Address and User-IPv6-Addr=
ess, in order to identify a session by IP address.  This would allow the Fr=
amed-IP-Address, Framed-IPv6-Prefix, Framed-Interface-Id and Delegated-IPv6=
-Address attributes to be included for the purpose of renumbering. Comments=
? =

--_f045cd0f-0cbd-4209-a48c-094e7e4a7e83_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
The problem described in this issue is that a CoA-Request packet cannot be =
used for renumbering.&nbsp; This is because RFC 3576 defines the Framed-IP-=
Address, Framed-IPv6-Prefix and Framed-Interface-Id attributes as session i=
dentification attributes. <br><br>RFC 3576bis-04 advocates use of the Servi=
ce-Type value of "Authorize-Only" in order to enable renumbering.&nbsp; <br=
><br>It has been pointed out that this is inefficient, requiring two exchan=
ges (a CoA-Request/CoA-ACK and then an Access-Request/Access-Accept) when o=
nly one should be required. <br><br>I'd like to put forward a potential app=
roach to address this concern, which is to introduce two new attributes, Us=
er-IPv4-Address and User-IPv6-Address, in order to identify a session by IP=
 address.&nbsp; This would allow the Framed-IP-Address, Framed-IPv6-Prefix,=
 Framed-Interface-Id and Delegated-IPv6-Address attributes to be included f=
or the purpose of renumbering. <br><br>Comments? <br></body>
</html>=

--_f045cd0f-0cbd-4209-a48c-094e7e4a7e83_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 15 May 2007 22:46:38 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: RFC 3576bis Open Issues
Date: Tue, 15 May 2007 15:45:56 -0700

--_88626fcc-56eb-409e-bda8-4cb77f2a1a0e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Currently, we have two open issues on RFC 3576bis:
=20
Issue 226: RFC 3576bis and Renumbering
Issue 227: Proxy State
=20
In order to resolve these issues, we need answer to the following questions=
 from implementers of  RFC 3576:
=20
a.  Have you implemented Framed-IP-Address or Framed-IPv6-Prefix/Framed-Int=
erface-Id as a Session Identification attribute?=20
b.  Have you implemented the proxy state algorithm described below?=20
=20
    If there are any Proxy-State Attributes in a Disconnect-Request or    C=
oA-Request received from the server, the forwarding proxy or NAS    MUST in=
clude those Proxy-State Attributes in its response to the    server.    A f=
orwarding proxy or NAS MUST NOT modify existing Proxy-State,    State, or C=
lass Attributes present in the packet.  The forwarding    proxy or NAS MUST=
 treat any Proxy-State attributes already in the    packet as opaque data. =
 Its operation MUST NOT depend on the    content of Proxy-State attributes =
added by previous proxies.  The    forwarding proxy MUST NOT modify any oth=
er Proxy-State Attributes    that were in the packet; it may choose not to =
forward them, but it    MUST NOT change their contents.  If the forwarding =
proxy omits the    Proxy-State Attributes in the request, it MUST attach th=
em to the    response before sending it.    When the proxy forwards a Disco=
nnect or CoA-Request, it MAY add a    Proxy-State Attribute, but it MUST NO=
T add more than one.  If a    Proxy-State Attribute is added to a packet wh=
en forwarding the    packet, the Proxy-State Attribute MUST be added after =
any existing    Proxy-State attributes.  The forwarding proxy MUST NOT chan=
ge the    order of any attributes of the same type, including Proxy-State. =
   Other Attributes can be placed before, after or even between the    Prox=
y-State Attributes.    When the proxy receives a response to a CoA-Request =
or Disconnect-    Request, it MUST remove its own Proxy-State (the last Pro=
xy- State    in the packet) before forwarding the response.  Since Disconne=
ct    and CoA responses are authenticated on the entire packet contents,   =
 the stripping of the Proxy-State Attribute invalidates the    integrity ch=
eck - so the proxy needs to recompute it. =

--_88626fcc-56eb-409e-bda8-4cb77f2a1a0e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Currently, we have two open issues on RFC 3576bis:<BR>
&nbsp;<BR>
Issue 226: <A href=3D"http://www.drizzle.com/~aboba/RADEXT/radissues2.html#=
Issue 226"><U><FONT color=3D#0066cc>RFC 3576bis and Renumbering</FONT></U><=
/A><BR>
Issue 227: <A href=3D"http://www.drizzle.com/~aboba/RADEXT/radissues2.html#=
Issue 227"><U><FONT color=3D#0066cc>Proxy State</FONT></U></A><BR>
&nbsp;<BR>
In order to resolve these issues, we need answer to the following questions=
 from implementers of&nbsp; RFC 3576:<BR>
&nbsp;<BR>
a.&nbsp; Have you implemented Framed-IP-Address or Framed-IPv6-Prefix/Frame=
d-Interface-Id as a Session Identification attribute? <BR>
b.&nbsp; Have you implemented the proxy state algorithm described below? <B=
R>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp; If there are any Proxy-State Attributes in a Disconnect-=
Request or<BR>&nbsp;&nbsp;&nbsp; CoA-Request received from the server, the =
forwarding proxy or NAS<BR>&nbsp;&nbsp;&nbsp; MUST include those Proxy-Stat=
e Attributes in its response to the<BR>&nbsp;&nbsp;&nbsp; server.<BR><BR>&n=
bsp;&nbsp;&nbsp; A forwarding proxy or NAS MUST NOT modify existing Proxy-S=
tate,<BR>&nbsp;&nbsp;&nbsp; State, or Class Attributes present in the packe=
t.&nbsp; The forwarding<BR>&nbsp;&nbsp;&nbsp; proxy or NAS MUST treat any P=
roxy-State attributes already in the<BR>&nbsp;&nbsp;&nbsp; packet as opaque=
 data.&nbsp; Its operation MUST NOT depend on the<BR>&nbsp;&nbsp;&nbsp; con=
tent of Proxy-State attributes added by previous proxies.&nbsp; The<BR>&nbs=
p;&nbsp;&nbsp; forwarding proxy MUST NOT modify any other Proxy-State Attri=
butes<BR>&nbsp;&nbsp;&nbsp; that were in the packet; it may choose not to f=
orward them, but it<BR>&nbsp;&nbsp;&nbsp; MUST NOT change their contents.&n=
bsp; If the forwarding proxy omits the<BR>&nbsp;&nbsp;&nbsp; Proxy-State At=
tributes in the request, it MUST attach them to the<BR>&nbsp;&nbsp;&nbsp; r=
esponse before sending it.<BR><BR>&nbsp;&nbsp;&nbsp; When the proxy forward=
s a Disconnect or CoA-Request, it MAY add a<BR>&nbsp;&nbsp;&nbsp; Proxy-Sta=
te Attribute, but it MUST NOT add more than one.&nbsp; If a<BR>&nbsp;&nbsp;=
&nbsp; Proxy-State Attribute is added to a packet when forwarding the<BR>&n=
bsp;&nbsp;&nbsp; packet, the Proxy-State Attribute MUST be added after any =
existing<BR>&nbsp;&nbsp;&nbsp; Proxy-State attributes.&nbsp; The forwarding=
 proxy MUST NOT change the<BR>&nbsp;&nbsp;&nbsp; order of any attributes of=
 the same type, including Proxy-State.<BR>&nbsp;&nbsp;&nbsp; Other Attribut=
es can be placed before, after or even between the<BR>&nbsp;&nbsp;&nbsp; Pr=
oxy-State Attributes.<BR><BR>&nbsp;&nbsp;&nbsp; When the proxy receives a r=
esponse to a CoA-Request or Disconnect-<BR>&nbsp;&nbsp;&nbsp; Request, it M=
UST remove its own Proxy-State (the last Proxy- State<BR>&nbsp;&nbsp;&nbsp;=
 in the packet) before forwarding the response.&nbsp; Since Disconnect<BR>&=
nbsp;&nbsp;&nbsp; and CoA responses are authenticated on the entire packet =
contents,<BR>&nbsp;&nbsp;&nbsp; the stripping of the Proxy-State Attribute =
invalidates the<BR>&nbsp;&nbsp;&nbsp; integrity check - so the proxy needs =
to recompute it.<BR><PRE style=3D"MARGIN: 0em">&nbsp;</PRE></body>
</html>=

--_88626fcc-56eb-409e-bda8-4cb77f2a1a0e_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 15 May 2007 14:04:21 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-radext-rfc4590bis (RADIUS Extension for  Digest Authentication) to Proposed Standard 
Reply-To: [email-masked]
Cc: <[email-masked]>
Message-Id: <[email-masked]>
Date: Tue, 15 May 2007 10:03:26 -0400

The IESG has received a request from the RADIUS EXTensions WG (radext) 
to consider the following document:

- 'RADIUS Extension for Digest Authentication '
   <draft-ietf-radext-rfc4590bis-01.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-05-29. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

Note that the document includes a Normative Reference to RFC 3579 which
is an Informational RFC. This down reference was already approved for RFC
4590. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15568&rfc_flag=0

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Mon, 14 May 2007 13:48:32 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-radext-fixes (Common RADIUS  Implementation Issues and Suggested Fixes) to Proposed Standard
Reply-To: [email-masked]
Cc: <[email-masked]>
Message-Id: <[email-masked]>
Date: Mon, 14 May 2007 09:47:19 -0400

The IESG has received a request from the RADIUS EXTensions WG (radext) 
to consider the following document:

- 'Common RADIUS Implementation Issues and Suggested Fixes '
   <draft-ietf-radext-fixes-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-05-28. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15576&rfc_flag=0

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 09 May 2007 20:02:47 +0000
Content-class: urn:content-classes:message
Subject: RE: your support: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt
Date: Wed, 9 May 2007 13:01:28 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Given the proposed attributes help support Mobile IP in a way that is
uniform across SDOs & ensures interoperability,

    "I support the advancement of this document to the IESG with a
     request for publication as an Informational RFC."

Thanks,
Farid

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]]=20
Sent: Wednesday, May 02, 2007 12:56 PM
To: [email-masked]; [email-masked]
Cc: Henrik Levkowetz
Subject: [Mip4] Working Group Last Call
fordraft-ietf-mip4-radius-requirements-02.txt

This message announces a 2 week working group last call
on:

"Mobile IPv4 RADIUS Requirements"
draft-ietf-mip4-radius-requirements-02.txt.=20

The last call will end at 24:00 UTC on Wednesday, May 16th.=20

"Mobile IPv4 RADIUS Requirements" lists a set of goals and
assumptions to lay the groundwork for future RADIUS extensions
in support of Mobile IPv4.

A URL for this internet draft is:

http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements-
02.txt

Please respond to this working group last call:

* If you have no comments on the draft, and support its advancement,
   simply respond with a line containing something like
 =20
    "I support the advancement of this document to the IESG with a
     request for publication as an Informational RFC."

   If you have comments, please use a line similar to the one above,
   and supplement this with your comments.
=20
=20
* If you *don't* support its advancement, respond with a line
  containing something like the following, supplemented by your=20
  comments -
 =20
    "I don't support the advancement of this document to the IESG with
     a request for publication as an Informational RFC, for the
following
     reasons:"
    ...

Please direct all replies to the Mobile IPv4 mailing list,
[email-masked].

-Pete & Henrik

--=20
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 01 May 2007 22:59:47 +0000
content-class: urn:content-classes:message
Subject: FW:  RFC 4849 on RADIUS Filter Rule Attribute
Date: Wed, 2 May 2007 01:58:39 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>

 Congratulations and thanks to the editors, chairs, contributors and all
the WG for the publication of this document.=20

Dan

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Tuesday, May 01, 2007 6:58 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RFC 4849 on RADIUS Filter Rule Attribute

A new Request for Comments is now available in online RFC libraries.

       =20
        RFC 4849

        Title:      RADIUS Filter Rule Attribute=20
        Author:     P. Congdon, M. Sanchez,
                    B. Aboba
        Status:     Standards Track
        Date:       April 2007
        Mailbox:    [email-masked],=20
                    [email-masked],=20
                    [email-masked]
        Pages:      9
        Characters: 18162
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-radext-filter-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4849.txt

While RFC 2865 defines the Filter-Id attribute, it requires that the
Network Access Server (NAS) be pre-populated with the desired filters.
However, in situations where the server operator does not know which
filters have been pre-populated, it is useful to specify filter rules
explicitly.  This document defines the NAS-Filter-Rule attribute within
the Remote Authentication Dial In User Service (RADIUS).  This attribute
is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP)
described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588.
[STANDARDS TRACK]

This document is a product of the RADIUS EXTensions Working Group of the
IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and
suggestions for improvements.Please refer to the current edition of the
Internet Official Protocol Standards (STD 1) for the standardization
state and status of this protocol.  Distribution of this memo is
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be added to or
deleted from the RFC-DIST distribution list should be sent to
[email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an
EMAIL message to [email-masked] with the message body=20

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 01 May 2007 03:59:26 +0000
Date: Mon, 30 Apr 2007 20:58:23 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4849 on RADIUS Filter Rule Attribute
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4849

        Title:      RADIUS Filter Rule Attribute 
        Author:     P. Congdon, M. Sanchez,
                    B. Aboba
        Status:     Standards Track
        Date:       April 2007
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      9
        Characters: 18162
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-radext-filter-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4849.txt

While RFC 2865 defines the Filter-Id attribute,
it requires that the Network Access Server (NAS) be pre-populated with
the desired filters.  However, in situations where the server operator
does not know which filters have been pre-populated, it is useful to
specify filter rules explicitly.  This document defines the
NAS-Filter-Rule attribute within the Remote Authentication Dial In
User Service (RADIUS).  This attribute is based on the Diameter
NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and
the IPFilterRule syntax defined in RFC 3588.  [STANDARDS TRACK]

This document is a product of the RADIUS EXTensions
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>