Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 20:47:37 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Wed, 30 May 2007 16:45:27 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001401c7a2fb$74583fa0$6501a8c0@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: Acei+kxcvr2WCWpETwSdapfudVrskgAAIhZg 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 20:33:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Wed, 30 May 2007 16:33:19 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" Cc: "Bernard Aboba" , See inline....=20 -----Original Message----- From: Alan DeKok [mailto:aland@nitros9.org]=20 Sent: Tuesday, May 29, 2007 4:10 AM To: Avi Lior Cc: Bernard Aboba; radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 20:14:24 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Wed, 30 May 2007 16:12:28 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001301c7a2f6$d8cbfc10$6501a8c0@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: Acei9gQ7wjScEmwBSHeJ08EBtJ7qJwAAKMLg 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 20:07:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Wed, 30 May 2007 16:06:22 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" Cc: "David B. Nelson" , Hi Alan, =20 -----Original Message----- From: Alan DeKok [mailto:aland@nitros9.org]=20 Sent: Tuesday, May 29, 2007 4:39 AM To: Avi Lior Cc: David B. Nelson; radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 18:32:33 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Wed, 30 May 2007 14:31:39 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" Cc: "Bernard Aboba" , "David B. Nelson" , , "Bernard Aboba" See inline...=20 -----Original Message----- From: Alan DeKok [mailto:aland@nitros9.org]=20 Sent: Wednesday, May 30, 2007 3:59 AM To: Avi Lior Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org; 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 13:54:06 +0000 Message-ID: <465D81F2.1020001@nitros9.org> Date: Wed, 30 May 2007 15:53:54 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Issue 226: RFC 3576bis and Renumbering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 13:35:52 +0000 From: "David B. Nelson" To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Wed, 30 May 2007 09:33:23 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000901c7a2bf$1882d870$6501a8c0@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AceivZvQNPNYFAX4SWmVPDebpMtZPQAAHpog 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 13:17:27 +0000 Message-ID: <465D7964.1010206@nitros9.org> Date: Wed, 30 May 2007 15:17:24 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Issue 226: RFC 3576bis and Renumbering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 13:08:07 +0000 Message-ID: <465D7735.5070901@nitros9.org> Date: Wed, 30 May 2007 15:08:05 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Issue 226: RFC 3576bis and Renumbering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 13:00:51 +0000 From: "David B. Nelson" To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Wed, 30 May 2007 08:59:32 -0400 Message-ID: <01bb01c7a2ba$5e16fc90$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AceikYw7yAEm4QulTxa71X4R8D9t6QAIWhBwAAGpkIA= 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 12:32:26 +0000 From: "David B. Nelson" To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Wed, 30 May 2007 08:30:33 -0400 Message-ID: <01ae01c7a2b6$52055fe0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AceikYw7yAEm4QulTxa71X4R8D9t6QAIWhBw 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 30 May 2007 08:00:07 +0000 Message-ID: <465D2EC5.1060300@nitros9.org> Date: Wed, 30 May 2007 09:59:01 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Avi Lior CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org, Bernard Aboba Subject: Re: Issue 226: RFC 3576bis and Renumbering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 May 2007 19:50:49 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-07.txt Message-Id: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-29114646.I-D@ietf.org> 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: <2007-5-29114646.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 May 2007 17:27:13 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A216.A53D383B" Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 29 May 2007 13:26:09 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , "Alan DeKok" Cc: "David B. Nelson" , , "Bernard Aboba" 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:bernard_aboba@hotmail.com]=20 Sent: Saturday, May 26, 2007 12:04 PM To: Alan DeKok; Avi Lior Cc: David B. Nelson; radiusext@ops.ietf.org; Bernard Aboba Subject: RE: Issue 226: RFC 3576bis and Renumbering > Date: Sat, 26 May 2007 15:46:46 +0100 > From: aland@nitros9.org > To: avi@bridgewatersystems.com > CC: dnelson@elbrysnetworks.com; radiusext@ops.ietf.org; bernarda@windows.microsoft.com > Subject: Re: Issue 226: RFC 3576bis and Renumbering >=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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: ------_=_NextPart_001_01C7A216.A53D383B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Bernard,

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



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

[BA] It would be somewhat complicated to define a different = set of=20 session identification attributes for CoA and Disconnect-Requests.  =
[Avi] Correct.
 
[BA] 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.  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.)
[Avi]  
[Avi]  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.  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.
 
[BA] 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.
[Avi] Yes I agree that = it "can" be=20 used.  But Alan seems to make it mandatory. And to mandatory = require that=20 it be sent in the Access-Request packet.  I dont = agree with=20 that.  I think if the deployement requires it to be in the = access=20 request then it can be sent.  The current RFCs are = fine.
 
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). 
[Avi] Yes I agree and even=20 VSAs. 

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

> =
> Alan=20 DeKok.
>
> --
> to unsubscribe send a message to=20 radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a = single=20 line as the message text body.
> archive:=20 <http://psg.com/lists/radiusext/>
------_=_NextPart_001_01C7A216.A53D383B-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 May 2007 08:55:39 +0000 Message-ID: <465BEA79.60004@nitros9.org> Date: Tue, 29 May 2007 10:55:21 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "Glen Zorn (gwz)" CC: Avi Lior , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 May 2007 08:39:41 +0000 Message-ID: <465BE6BB.4070101@nitros9.org> Date: Tue, 29 May 2007 10:39:23 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Avi Lior CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 May 2007 08:33:28 +0000 Message-ID: <465BE550.3060601@nitros9.org> Date: Tue, 29 May 2007 10:33:20 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 May 2007 08:31:03 +0000 Message-ID: <465BDFE1.3020708@nitros9.org> Date: Tue, 29 May 2007 10:10:09 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Avi Lior CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 May 2007 08:24:42 +0000 Message-ID: <465BE30F.90706@nitros9.org> Date: Tue, 29 May 2007 10:23:43 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 29 May 2007 01:03:57 +0000 Message-ID: From: Bernard Aboba To: Subject: RE: Issue: Attribute restriction Date: Mon, 28 May 2007 18:02:55 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: avi@bridgewatersystems.com > To: bernard_aboba@hotmail.com; radiusext@ops.ietf.org >=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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On Behalf Of Bernard Aboba > Sent: Saturday, May 26, 2007 10:27 AM > To: radiusext@ops.ietf.org > Subject: Issue: Attribute restriction > Issue: Attribute Restriction > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 21:24:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 12:57:22 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625040DC359@xmb-sjc-215.amer.cisco.com> Thread-Topic: RFC3576bis and Session State Thread-Index: AcehPfpaJrsx7tctQpWDHwglbxLgogAAxmewAAHO0zAAAMEDsAAEJCYwAAFjqzA= From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1010; t=1180382246; x=1181246246; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20RFC3576bis=20and=20Session=20State |Sender:=20; bh=jJZ6818LgR7zPBT0cZ/JUtnbOYS3xbeNZ9wYsLLg5Gc=; b=r8hjyrAOcERaX+gZjImAeWI/Zr7gyX1odMbdmT09oPp9QBRaylbri4QhxlNOVdJllaLvpFL3 BNpfHjIGiqv89ffGq5p8TXvpi7lLp0H3NIqZB0ap6NVUvgrtgzdDAEUa; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 19:35:30 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 15:24:10 -0400 Message-ID: <004301c7a15d$c549ff60$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcehRFNBOspiSIcfTGuqsU86SSqKfgABL13AAAE9EsAAAP21oAAAnBigAAIASvA= 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 19:22:43 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 15:14:21 -0400 Message-ID: <004201c7a15c$6600f370$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcehPfpaJrsx7tctQpWDHwglbxLgogAAxmewAAHO0zAAAMEDsAAEJCYw 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 18:33:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 11:33:08 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625040DC33D@xmb-sjc-215.amer.cisco.com> Thread-Topic: RFC3576bis and Session State Thread-Index: AcehRFNBOspiSIcfTGuqsU86SSqKfgABL13AAAE9EsAAAP21oAAAnBig From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1949; t=1180377188; x=1181241188; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20RFC3576bis=20and=20Session=20State |Sender:=20; bh=Qp7QEfsm1to0rlycqBx2DIpE8joFI/E0riBgjn4D+i8=; b=MEwWVV6a771owzqlS7v6F+3BjL/aQlrmcG4eoWvtzO1w96IEnezJmnrbFE7TmdVpz1nI3XXi oMsLJv7KTmkR+B/8ML5PXCaEUodDNfDr3hfxctYPjjOCwrtnANxhD79g; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 18:10:14 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 14:06:13 -0400 Message-ID: <004101c7a152$e170ba40$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcehRFNBOspiSIcfTGuqsU86SSqKfgABL13AAAE9EsAAAP21oA== 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 17:39:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 10:39:23 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625040DC333@xmb-sjc-215.amer.cisco.com> Thread-Topic: RFC3576bis and Session State Thread-Index: AcehRFNBOspiSIcfTGuqsU86SSqKfgABL13AAAE9EsA= From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1152; t=1180373964; x=1181237964; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20RFC3576bis=20and=20Session=20State |Sender:=20; bh=xyrNdkvXkh/l53gizA5p2Re0cccOkO35M49KyP69Po4=; b=j7dfh9+WZxn3K/lB39R77qf1kQg7211nQKqjVLcIEpmk4PIGrNX3l8ieTjCaJMR50pZmLxVy Jkegz8VEM1aeQwhg0eSH87echV6P4K16MXv0dI89lOAKdQjXu+zgHOwODIfGectp0pjqv32KIa 4xXNyjGfJJQl8ZaSW9Dg4bCLo=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 17:14:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 10:14:23 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625040DC32E@xmb-sjc-215.amer.cisco.com> Thread-Topic: RFC3576bis and Session State Thread-Index: AcehPfpaJrsx7tctQpWDHwglbxLgogAAxmewAAHO0zAAAMEDsA== From: "Glen Zorn \(gwz\)" To: "David B. Nelson" , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=637; t=1180372461; x=1181236461; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20RFC3576bis=20and=20Session=20State |Sender:=20; bh=RLYTfqjxapznsssKO88opFMKoPX8qLxNl/1pREV6nV8=; b=l8e049M1Ww/mQRzPiuEBRCn7LwiUQlOyUCy0OV3s8yxWq2jjXIejU9EiSYXTew5uNGs8vz8b JiTxTQg18Ro/lpJDm3uMhBHseGWsclp7K2bgch4rV1EEybXEvGDQKfCH; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 17:06:28 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 13:00:19 -0400 Message-ID: <004001c7a149$acde41c0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcehRFNBOspiSIcfTGuqsU86SSqKfgABL13A 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 16:56:04 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 12:54:53 -0400 Message-ID: <003f01c7a148$ea259fc0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcehPfpaJrsx7tctQpWDHwglbxLgogAAxmewAAHO0zA= 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 16:35:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 12:34:48 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" Cc: "David B. Nelson" , See inline....=20 -----Original Message----- From: Alan DeKok [mailto:aland@nitros9.org]=20 Sent: Monday, May 28, 2007 11:37 AM To: Avi Lior Cc: David B. Nelson; radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 16:25:43 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A145.03BB0962" Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 12:25:30 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , "Alan DeKok" Cc: 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Sunday, May 27, 2007 4:10 PM To: Alan DeKok Cc: radiusext@ops.ietf.org 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
See=20 inline....

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org]=20 On Behalf Of Bernard Aboba
Sent: Sunday, May 27, 2007 = 4:10=20 PM
To: Alan DeKok
Cc:=20 radiusext@ops.ietf.org
Subject: RE: RFC3576bis and Session=20 State

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

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

------_=_NextPart_001_01C7A145.03BB0962-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 16:24:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 12:24:27 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" , "Bernard Aboba" Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 16:19:52 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 12:19:40 -0400 Message-ID: From: "Avi Lior" To: "David B. Nelson" , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 16:16:01 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A143.A7B5124A" Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 12:15:47 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , "Alan DeKok" , 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Saturday, May 26, 2007 12:15 PM To: Alan DeKok; radiusext@ops.ietf.org Subject: RE: RFC3576bis and Session State > Date: Sat, 26 May 2007 16:16:31 +0100 > From: aland@nitros9.org > To: bernard_aboba@hotmail.com > 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
I have an = issue with some=20 of the statement being made below:
 
What = session identifiers=20 I include in the COA or DM message should indicate what I want to=20 effect.
 
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...
 
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.
 
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.
 
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)
 
There may = even be some=20 VSA that can be used as well....
 
I dont = think therefore=20 that 3576 should prohibit any of the above.  It really is up to=20 deployements to determine how these are used.
 
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.
 
Statements=20 like:
 
Alan worte: "I can=20 add a sentence to Section saying "A NAS implementing this specification = SHOULD=20 send
an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an=20 Access-Request." "
Which as i = pointed out=20 only works in very simple cases. And in some cases Acct-Session-Id is = totally=20 useless.
 
Or
 
Bernard = wrote:  "Actually, it seems like it might make = it=20 unnecessary to use an IP address as a session identification = attribute."
IMO are not appropriate because = they are=20 useful in only some deployements.

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org]=20 On Behalf Of Bernard Aboba
Sent: Saturday, May 26, 2007 = 12:15=20 PM
To: Alan DeKok; radiusext@ops.ietf.org
Subject: = RE:=20 RFC3576bis and Session State



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

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

"As noted in [RFC2866] Section=20 5.5:

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

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

Where the Acct-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=20 identify the session (e.g. if the same
user has multiple sessions on = the NAS,=20 or the privacy NAI is used).
As a result, one or more of the=20 Acct-Multi-Session-Id,
Called-Station-Id, Calling-Station-Id, = NAS-Port and=20 NAS-Port-Id attributes
MAY be used as additional session=20 identification."

To something like this:

"A NAS = implementing this=20 specification SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id = Attribute=20 within an Access-Request.  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.

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).  As a result, one or more of the = Called-Station-Id,=20 Calling-Station-Id,  NAS-Port and NAS-Port-Id attributes MAY be = used as=20 additional session identification."


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

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

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

>
> Alan DeKok.
------_=_NextPart_001_01C7A143.A7B5124A-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 16:11:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 09:10:09 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625040DC319@xmb-sjc-215.amer.cisco.com> Thread-Topic: RFC3576bis and Session State Thread-Index: AcehPfpaJrsx7tctQpWDHwglbxLgogAAxmew From: "Glen Zorn \(gwz\)" To: "Alan DeKok" , "Avi Lior" Cc: "David B. Nelson" , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2499; t=1180368633; x=1181232633; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20RFC3576bis=20and=20Session=20State |Sender:=20; bh=LSlsuLvaJnq9HYAnsBB5UhWXsU9DzfUPkGPhVkyr0e4=; b=GhzkQs9Qvd41yZmeCXVWovHX88lh4fwVPrly+M3hbwlh1Hyi466U+Oo8B72T+eC/My8NJFNQ KnuscrtblvLEoWRRzjgs1T8gJfoYbDYgzMpE5WwgelZQlz8dGLCM07I4; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 15:54:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 11:54:32 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" , "Glen Zorn (gwz)" Cc: "Bernard Aboba" , Alan, Again I am not opposed to using Accounting-Session-ID. Please see inline....=20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok Sent: Saturday, May 26, 2007 10:39 AM To: Glen Zorn (gwz) Cc: Bernard Aboba; radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 15:36:34 +0000 Message-ID: <465AF704.4050904@nitros9.org> Date: Mon, 28 May 2007 17:36:36 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Avi Lior CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 15:28:52 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A13D.0E0D9836" Subject: RE: Issue: Attribute restriction Date: Mon, 28 May 2007 11:28:40 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Saturday, May 26, 2007 10:27 AM To: radiusext@ops.ietf.org Subject: Issue: Attribute restriction Issue: Attribute Restriction Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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
Bernard,
 
Dont forget = that in=20 RADIUS Location Draft we want to include location information in = this=20 message.

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.  Thus this will avoid the AAA = server from=20 challenging it again to provide location information.
 
How do you = want to deal=20 with that?  Do we let that Draft specify this or do you want to = align the=20 draft.

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org]=20 On Behalf Of Bernard Aboba
Sent: Saturday, May 26, 2007 = 10:27=20 AM
To: radiusext@ops.ietf.org
Subject: Issue: = Attribute=20 restriction

Issue:  Attribute Restriction
Submitter name: Bernard = Aboba
Submitter email address: aboba@internaut.com
Date first = submitted:=20 May 26, 2007
Reference:
Document: RFC3576bis-06
Comment type:=20 Technical
Priority: S
Section: 3.2
Rationale/Explanation of=20 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 attributes 
from [RFC2865], [RFC2868], =
[RFC2869] and [RFC3162] can be included in the 
Access-Request.  In =
fact, RFC 3576bis adds Chargeable-User-Identity to the 
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-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 15:24:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Mon, 28 May 2007 11:24:16 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" , "David B. Nelson" Cc: See inline...=20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok Sent: Saturday, May 26, 2007 10:16 AM To: David B. Nelson Cc: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 14:56:42 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A138.9439A852" Subject: RE: Issue 223: Event-Timestamp and Duplicate Detection Date: Mon, 28 May 2007 10:56:35 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , "Alan DeKok" Cc: 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:bernard_aboba@hotmail.com]=20 Sent: Friday, May 25, 2007 6:59 PM To: Avi Lior; Alan DeKok Cc: radiusext@ops.ietf.org 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
Perhaps.
 
But there = are no formal=20 words in the table.  The first three sentences use terms like = "guide" "may=20 be".
 
It also = uses must not be=20 present in an Accounting-Request.  So why wouldnt the document make = a=20 similar strong statement about those attribute,
 
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.
 
I think = that document is=20 ambiguous in this matter.

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] =
Sent:=20 Friday, May 25, 2007 6:59 PM
To: Avi Lior; Alan = DeKok
Cc:=20 radiusext@ops.ietf.org
Subject: RE: Issue 223: Event-Timestamp = and=20 Duplicate Detection

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

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

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

------_=_NextPart_001_01C7A138.9439A852-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 28 May 2007 14:56:18 +0000 Message-ID: <465AED5D.2020800@nitros9.org> Date: Mon, 28 May 2007 16:55:25 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Issue 227: Proxy State Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 May 2007 20:27:45 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_fcb88119-43bd-4727-a3de-4268a82d8cc3_" From: Bernard Aboba To: Subject: RE: Link to strawman RFC 3576bis -07 document Date: Sun, 27 May 2007 13:27:33 -0700 MIME-Version: 1.0 --_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: bernard_aboba@hotmail.comTo: radiusext@ops.ietf.orgSubject: 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 I've now gone over the draft again, to introduce the term "Dynamic Authoriz= ation Server" where appropriate. 
From: bernard_aboba@hotmail.com
To: radiusext@ops.ietf.org
Subject: L= ink to strawman RFC 3576bis -07 document
Date: 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-rad= ext-rfc3576bis-07.txt

This strawman does not yet include changes to = reflect Issue 227:  Proxy State.
= --_fcb88119-43bd-4727-a3de-4268a82d8cc3_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 May 2007 20:10:10 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_2af9aa07-7e42-41f4-bba1-ed88b65da6cd_" From: Bernard Aboba To: Alan DeKok CC: Subject: RE: RFC3576bis and Session State Date: Sun, 27 May 2007 13:09:58 -0700 MIME-Version: 1.0 --_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: aland@nitros9.org> To: bernard_aboba@hotmail.com> 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 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-Se= ssion-Id
or Acct-Multi-Session-Id of the session it is attempting to tar= get,
unless it also has access to the accounting data for that session.<= BR>  
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
prese= nt in a CoA-Request or Disconnect-Request, it is possible that the
the U= ser-Name or Chargeable-User-Identity attributes will not be
sufficient = to uniquely identify the session (e.g. if the same
user has multiple ses= sions on the NAS, or if the privacy NAI is used).
In this case, session= identification MAY be performed by using one or more of
the Called-Stat= ion-Id, Calling-Station-Id, NAS-Port and
NAS-Port-Id attributes."

> Date: Sun, 27 May 2007 13:52:46 +0100
> From: aland@nitros9= .org
> To: bernard_aboba@hotmail.com
> CC: radiusext@ops.ietf.o= rg
> Subject: Re: RFC3576bis and Session State
>
> Berna= rd Aboba wrote:
> ...
> > To something like this:
> &g= t;
> > "A NAS implementing this specification SHOULD send an Acct= -Session-Id or
> > Acct-Multi-Session-Id Attribute within an Acce= ss-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 A= ttribute is not
> > present in a CoA-Request or Disconnect-Reques= t,
>
> the User-Name or Chargeable-User-Identity attributes ma= y be
> sufficient to uniquely identify the session. However, if the s= ame 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 h= ow does the client determine which
> attributes to send if there's n= o session ID attribute? Maybe recommend:
> CUI or else User-Name (un= less it's anonymous) or Calling-Station-Id, etc.
>
> > I ca= n add a sentence to Section saying "A NAS implementing this
> > s= pecification SHOULD send
> > an Acct-Session-Id or Acct-Multi-Sess= ion-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.
> <= BR>> Alan DeKok.

= --_2af9aa07-7e42-41f4-bba1-ed88b65da6cd_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 May 2007 19:58:59 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_e52d9af2-e476-4082-afb8-8a4b60e3329e_" From: Bernard Aboba To: Alan DeKok CC: Subject: RE: Issue: RPF Check Date: Sun, 27 May 2007 12:58:02 -0700 MIME-Version: 1.0 --_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: aland@nitros9.org> To: bernard_abo= ba@hotmail.com> CC: radiusext@ops.ietf.org> 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 Let me know whether this works for you.
 
I have added a definition of "Dynamic Authorization Server" to the terminol= ogy section:
 
Dynamic Authorization Client (DAC)
     The entity o= riginating Change of Authorization (CoA) Requests or
   &= nbsp; Disconnect-Requests.  While it is possible that the DAC is co-     resident with a RADIUS authentication or account= ing server, this
     need not necessarily be the ca= se.

Dynamic Authorization Server (DAS)
     T= he entity receiving CoA-Request or Disconnect-Request packets.
 &nb= sp;   The DAS may be a NAS or a RADIUS proxy.

Network Acce= ss Server (NAS)
     The device providing access to = the network.
 
Here is the new text of Section 6.1:
 
6.1.  Authorization Issues

   Where a NAS is shared b= y multiple providers, it is undesirable for
   one provider to= be able to send Disconnect-Request or CoA-Requests
   affecti= ng the sessions of another provider.

   A Dynamic Authoriz= ation Server MUST silently discard Disconnect-
   Request or C= oA-Request packets from untrusted sources.  In situations
 &nb= sp; where the Dynamic Authorization Client is co-resident with a RADIUS
=    authentication or accounting server, a proxy MAY perform a "re= verse
   path forwarding" (RPF) check to verify that a Disconn= ect-Request or
   CoA-Request originates from an authorized Dy= namic Authorization
   Client.  In addition, it SHOULD be= possible to explicitly authorize
   additional sources of Dis= connect-Request or CoA-Request packets
   relating to certain = classes of sessions.  For example, a particular
   source= can be explicitly authorized to send CoA-Request packets
   r= elating to users within a set of realms.

   To perform the= RPF check, the Dynamic Authorization Server uses the
   sessi= on identification attributes included in Disconnect-Request or
 &nb= sp; CoA-Request packets, in order to determine the RADIUS server(s) to
&= nbsp;  which an equivalent Access-Request could be routed.  If th= e source
   address of the Disconnect-Request or CoA-Request i= s within this set,
   then the CoA-Request or Disconnect-Reque= st is forwarded; otherwise it
   MUST be silently discarded.
   Typically the Dynamic Authorization Server will extract = the realm
   from the Network Access Identifier [RFC4282] incl= uded within the
   User-Name or Chargeble-User-Identity Attrib= ute, and determine the
   corresponding RADIUS servers in the = realm routing tables.  If the
   Dynamic Authorization Se= rver maintains long-term session state, it
   MAY perform the = authorization check based on the session
   identification att= ributes in the CoA-Request.  The session
   identificatio= n attributes can be used to tie a session to a
   particular p= roxy or set of proxies, as with the NAI realm.

   Where no= proxy is present, the RPF check can only be performed by the
 &nbs= p; NAS if it maintains its own a realm routing table.  If the NAS does=
   not maintain a realm routing table (e.g. it selects forwar= ding
   proxies based on primary/secondary configuration and/o= r liveness
   checks), then an RPF check cannot be performed.<= BR>
   Since authorization to send a Disconnect-Request or CoA= -Request is
   determined based on the source address and the = corresponding shared
   secret, the Dynamic Authorization Serv= er SHOULD configure a different
   shared secret for each Dyna= mic Authorization 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: al= and@nitros9.org
> To: bernard_aboba@hotmail.com
> CC: radiusext= @ops.ietf.org
> Subject: Re: Issue: RPF Check
>
> Bernar= d Aboba wrote:
> > It has been pointed out that the Dynamic Author= ization 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 t= hat this is the case. In cases
> > where the Dynamic Authorizatio= n Client is not co-resident with the
> > RADIUS authentication or= authorization server, the RPF check cannot be
> > applied. I wou= ld 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 perform= ing CoA requests. We should make a
> note of that problem, and poten= tial methods for addressing it. See below.
>
> > Note that = this is not the only place where the distinction between a
> > RA= DIUS server and a Dynamic Authorization Client needs to be made.
> &= gt;
> > 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 Authori= zation
> 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
> > Dynami= c Authorization Client are co-resident.
>
> OK.
>
&g= t; > 6.1. Authorization Issues
> >
> > Where a NAS is= shared by multiple providers, it is undesirable for
> > one provi= der to be able to send Disconnect-Request or CoA-Requests
> > affe= cting the sessions of another provider.
> ...
> > Typically = the proxy will extract the realm from the Network Access
> > Ident= ifier [RFC4282] included within the User-Name Attribute, and
> > d= etermine 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 ad= d "or the CUI", since the NAI may be anonymized?
> Also, the proxyin= g 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 <= BR>> can be used to tie a session to a particular forwarding server or s= et 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 poli= cy-based routing on the RADIUS requests.
> If the NAS selects server= s by live/dead status, or by load-balancing,
> then the RPF checks d= o not need to be performed.
>
> Alan DeKok.

= --_e52d9af2-e476-4082-afb8-8a4b60e3329e_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 May 2007 12:53:36 +0000 Message-ID: <46597F1E.5060906@nitros9.org> Date: Sun, 27 May 2007 13:52:46 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 May 2007 08:40:31 +0000 Message-ID: <465943CB.5030709@nitros9.org> Date: Sun, 27 May 2007 09:39:39 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Issue: RPF Check Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 27 May 2007 02:26:40 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Sat, 26 May 2007 13:53:59 -0400 Message-ID: <002401c79fbe$d6983390$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acefo/fY/S56i3lBQtaj7kMoSiIIYwABMb3gAAB+3cAABF1esA== 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 16:44:19 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_03d1b9fb-10a2-4938-b3c1-b6780d533978_" From: Bernard Aboba To: Subject: Link to strawman RFC 3576bis -07 document Date: Sat, 26 May 2007 09:43:41 -0700 MIME-Version: 1.0 --_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 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-rad= ext-rfc3576bis-07.txt

This strawman does not yet include changes to = reflect Issue 227:  Proxy State.
= --_03d1b9fb-10a2-4938-b3c1-b6780d533978_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 16:15:01 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_2e7b6932-e1b5-445c-af18-fd1c5b203471_" From: Bernard Aboba To: Alan DeKok , Subject: RE: RFC3576bis and Session State Date: Sat, 26 May 2007 09:14:50 -0700 MIME-Version: 1.0 --_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: aland@nitros9.org> To: berna= rd_aboba@hotmail.com> 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

> Date: Sat, 26 May 2007 16:16:31 +0100
> From: aland@nitr= os9.org
> To: bernard_aboba@hotmail.com
> Subject: Re: RFC3576b= is and Session State
>
> Bernard Aboba wrote:
> > &g= t; I suggest we can request that they implement it now, *if* they also
&= gt; > > support CoA or Disconnect request.
> >
> >= ; [BA] Are you suggesting that NASes implementing RFC 3576bis SHOULD send <= br>> > the Acct-Session-Id within an Access-Request?
>
>= Yes. Or, Acct-Multi-Session-Id, which may address Avi's concerns
&= gt; over multiple Acct-Session-Id's for one "session".\

[BA]  H= mm...  Perhaps we need a change in Section 3 from:

"As noted in= [RFC2866] Section 5.5:

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

Since the Acct-Session-= Id is optional in Access-Requests,
if the Dynamic Authorization Client o= nly has access to
attributes sent to or by the RADIUS authentication ser= ver, then it
will not necessarily know the Acct-Session-Id of the sessio= n it is attempting
to target.

Where the Acct-Session-Id Attribute= is not present in
a CoA-Request or Disconnect-Request,
it is possibl= e 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 m= ultiple sessions on the NAS, or the privacy NAI is used).
As a result, o= ne or more of the Acct-Multi-Session-Id,
Called-Station-Id, Calling-Stat= ion-Id, NAS-Port and NAS-Port-Id attributes
MAY be used as additional se= ssion identification."

To something like this:

"A NAS implem= enting this specification SHOULD send an Acct-Session-Id or Acct-Multi-Sess= ion-Id Attribute within an Access-Request.  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= .

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).  As a result, one or more of the= Called-Station-Id, Calling-Station-Id,  NAS-Port and NAS-Port-Id attr= ibutes MAY be used as additional session identification."


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

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

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

[BA] That seems like a bett= er idea.

>
> Alan DeKok.
= --_2e7b6932-e1b5-445c-af18-fd1c5b203471_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 16:04:16 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_7d903fb1-29af-4533-ab1d-0c104977d1ba_" From: Bernard Aboba To: Alan DeKok , Avi Lior CC: "David B. Nelson" , , Bernard Aboba Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Sat, 26 May 2007 09:03:59 -0700 MIME-Version: 1.0 --_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: aland@nitros9.org> To: avi@b= ridgewatersystems.com> CC: dnelson@elbrysnetworks.com; radiusext@ops.ietf.o= rg; bernarda@windows.microsoft.com> 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= ext-request@ops.ietf.org with> the word 'unsubscribe' in a single line as t= he message text body.> archive: = --_7d903fb1-29af-4533-ab1d-0c104977d1ba_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> Date: Sat, 26 May 2007 15:46:46 +0100
> From: aland@nitr= os9.org
> To: avi@bridgewatersystems.com
> CC: dnelson@elbrysne= tworks.com; radiusext@ops.ietf.org; bernarda@windows.microsoft.com
> = Subject: Re: Issue 226: RFC 3576bis and Renumbering
>
> Avi L= ior wrote:
> > Accounting Session ID only identifies an accounting= session Start/Stop
> > and its interims, if any. A given "sessio= n" (IP Session or
> > Access-Session) may contain a number of para= llel 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 ref= ers to.
> It's a circular reference, but not much else is true.
&= gt;
> 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 allo= ws 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 indi= cation to "use
> this new value".
>
> > When it come= s to 3576 and DM or even COA:
> >
> > We need to be able= to terminate or modify the Session WRT to A. That
> > is, sendin= g a DM with an NAI or some other user identification, we
> > termi= nate all of the users IP sessions.
> >
> > We need to be= able to terminate or modify any of the users IP sessions.
> > The= refore 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
&= gt; key *and* as a "new value" in a change request is not.

[BA] It w= ould be somewhat complicated to define a different set of session identific= ation attributes for CoA and Disconnect-Requests.  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.  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.)

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.

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

So it's hard to = imagine a case where the IP address is *required* as a session identifier.&= nbsp;  And there are quite a few situations in which the NAS will be u= nable to identify the session by IP address.   Given this, encour= aging the use of the IP address as a session identifier seems like a bad id= ea.


>
> Alan DeKok.
>
> --
> to= unsubscribe send a message to radiusext-request@ops.ietf.org with
> = the word 'unsubscribe' in a single line as the message text body.
> a= rchive: <http://psg.com/lists/radiusext/>
= --_7d903fb1-29af-4533-ab1d-0c104977d1ba_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 15:36:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC3576bis and Session State Date: Sat, 26 May 2007 08:36:07 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625040DC26D@xmb-sjc-215.amer.cisco.com> Thread-Topic: RFC3576bis and Session State Thread-Index: Acefo/fY/S56i3lBQtaj7kMoSiIIYwABMb3gAAB+3cA= From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1002; t=1180193769; x=1181057769; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20RFC3576bis=20and=20Session=20State |Sender:=20; bh=jrwhrl1+3NkjOFtu1vKxIVuF8obRAwqjfjgrv2j1R2Q=; b=VMRn2iwf7cenupfVJEl+GYifsxZNMWqDXpIIL/4lD4FvunaQ3I89ZcLWKfruFPf5bYvcByi+ KX8SPup/B2DlgepEpn7gHeLP2UeCjFllYFJSU1mnOJVGeixHCZ+KIaNh; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 15:23:15 +0000 From: "David B. Nelson" To: Subject: RE: RFC3576bis and Session State Date: Sat, 26 May 2007 11:22:05 -0400 Message-ID: <001701c79fa9$a09a1390$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acefo/fY/S56i3lBQtaj7kMoSiIIYwABMb3g 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 15:15:29 +0000 From: "David B. Nelson" To: Subject: RE: Issue: Attribute restriction Date: Sat, 26 May 2007 11:14:15 -0400 Message-ID: <001601c79fa8$86836a70$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcefomHwMtftR3mZScGlUKWfMC1kfgABb9JA 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 15:06:05 +0000 Message-ID: <46584CDD.90207@nitros9.org> Date: Sat, 26 May 2007 16:06:05 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Issue: Attribute restriction Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > The proposed resolution is to change this sentence to: I agree. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 15:05:24 +0000 Message-ID: <46584CAB.9080202@nitros9.org> Date: Sat, 26 May 2007 16:05:15 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Issue: Acct-Session-Id clarification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 14:46:54 +0000 Message-ID: <46584856.1020509@nitros9.org> Date: Sat, 26 May 2007 15:46:46 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Avi Lior CC: "David B. Nelson" , radiusext@ops.ietf.org, Bernard Aboba Subject: Re: Issue 226: RFC 3576bis and Renumbering Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 14:39:07 +0000 Message-ID: <46584670.8020901@nitros9.org> Date: Sat, 26 May 2007 15:38:40 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "Glen Zorn (gwz)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 14:27:26 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_6f7839fd-11f4-49f6-bd62-fa9a014e3da1_" From: Bernard Aboba To: Subject: Issue: Attribute restriction Date: Sat, 26 May 2007 07:26:54 -0700 MIME-Version: 1.0 --_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: aboba@internaut.comDa= 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 Issue:  Attribute Restriction
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.c= om
Date first submitted: May 26, 2007
Reference:
Document: RFC357= 6bis-06
Comment type: Technical
Priority: S
Section: 3.2
Ration= ale/Explanation of issue:

Section 3.2 contains the following sentenc= e:
   This Access-Request SHOULD contain the NAS
   identificati=
on attributes from the CoA-Request, as well as the
   session identifica=
tion 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=
 attributes 
from [RFC2865], [RFC2868], [RFC2869] and [RFC3162] can be i=
ncluded in the 
Access-Request.  In fact, RFC 3576bis adds Chargeable-Us=
er-Identity to the 
list of session identification attributes; this is d=
efined 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 t=
he
   session identification attributes from the CoA-Request legal for   inclusion in an Access-Request.
= --_6f7839fd-11f4-49f6-bd62-fa9a014e3da1_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 14:16:37 +0000 Message-ID: <4658413B.6050204@nitros9.org> Date: Sat, 26 May 2007 15:16:27 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: RFC3576bis and Session State Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 14:07:54 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_5e88a630-8c61-486b-8574-33631f4acbe7_" From: Bernard Aboba To: Subject: Issue: Consolidation of "Authorize Only" Text Date: Sat, 26 May 2007 07:07:38 -0700 MIME-Version: 1.0 --_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: aboba@internaut.comDa= 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 Issue:  Consolidation of "Authorize Only" Text
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.c= om
Date first submitted: May 26, 2007
Reference:
Document: RFC357= 6bis-06
Comment type: Editorial
Priority: S
Section: 3.2, 4
Ra= tionale/Explanation of issue:

Currently text relating to "Authorize = Only" usage is included within Section 4 as well as Section 3.1.  Havi= ng normative text in two places makes the document harder to read, and also= can potentially introduce contradictions.    

The propo= sed resolution is as follows:

Change the following paragraph in Sect= ion 4 from:

"  To simplify translation between RADIUS and Diame=
ter, a server
   compliant with this specification MAY include a Service=
-Type
   Attribute with value "Authorize Only" within a CoA-Request.  Su=
ch a
   CoA-Request MUST contain a State Attribute.  A NAS supporting th=
e
   "Authorize Only" Service-Type within a CoA-Request responds with a<=
br>   CoA-NAK containing a Service-Type Attribute with value "Authorize
=
   Only", and an Error-Cause Attribute with value "Request Initiated".
 =
  The NAS will then send an Access-Request containing a Service-Type
   =
Attribute with a value of "Authorize Only", along with a State
   Attrib=
ute.  A Diameter/RADIUS gateway receiving a CoA-Request
   containing a =
Service-Type with value "Authorize Only" translates this
   to a RAR wit=
h 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 "Aut=
horize Only".   If the Result-Code AVP in the RAA has a
   value in the =
success category, then an Error-Cause Attribute with
   value "Request I=
nitiated" is included in the CoA-NAK.   If the
   Result-Code AVP in the=
 RAA has a value indicating a Protocol Error or
   a Transient or Perman=
ent Failure, then an alternate Error-Cause
   Attribute is returned as s=
uggested below."

To:

"  To simplify translation between RADIU=
S and Diameter, Dynamic
   Authorization Clients can include a Service-T=
ype Attribute with value
   "Authorize Only" within a CoA-Request, as de=
scribed in Section 3.2.
   A Diameter/RADIUS gateway receiving a CoA-Req=
uest containing a
   Service-Type with value "Authorize Only" translates=
 this to a RAR
   with Re-Auth-Request-Type AVP with value "AUTHORIZE ON=
LY".  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
   value in the success category, then an Error-Cause Attribute wi=
th
   value "Request Initiated" is included in the CoA-NAK.   If the
=
   Result-Code AVP in the RAA has a value indicating a Protocol Error or   a Transient or Permanent Failure, then an alternate Error-Cause
   A=
ttribute is returned as suggested below."

Change Section 3.2 f= rom:
"3.2.  Authorize Only

   Support for a CoA-Request incl=
uding a Service-Type Attribute with
   value "Authorize Only" is OPTIONA=
L 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-Request including a Service-Type
   Attribute with value "Autho=
rize Only" with a CoA-NAK; a CoA-ACK MUST
   NOT be sent.  If the NAS do=
es not support a Service-Type value of
   "Authorize Only" then it MUST =
respond with a CoA-NAK; an Error-Cause
   value of 405 (Unsupported Serv=
ice) SHOULD be included.

   A CoA-Request containing a Service-Type =
Attribute with value
   "Authorize Only" MUST in addition contain only N=
AS 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 At=
tribute)
   SHOULD be included.

   If a CoA-Request packet includ=
ing a Service-Type value of "Authorize
   Only" is successfully processe=
d, the NAS MUST respond with a CoA-NAK
   containing a Service-Type Attr=
ibute with value "Authorize Only", and
   an Error-Cause Attribute with =
value 507 (Request Initiated).  The NAS
   then MUST send an Access-Requ=
est to the RADIUS server including a
   Service-Type Attribute with valu=
e "Authorize Only".  This Access-
   Request SHOULD contain the NAS iden=
tification attributes from the
   CoA-Request, as well as the session id=
entification attributes from
   the CoA-Request legal for inclusion in a=
n Access-Request as specified
   in [RFC2865], [RFC2868], [RFC2869] and =
[RFC3162].  As noted in
   [RFC2869] Section 5.19, a Message-Authenticat=
or attribute SHOULD be
   included in an Access-Request that does not co=
ntain a User-Password,
   CHAP-Password, ARAP-Password or EAP-Message At=
tribute.  The RADIUS
   server then will respond to the Access-Request w=
ith an Access-Accept
   to (re-)authorize the session or an Access-Rejec=
t 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 an=
d Dynamic
   Authorization Client.  A Service-Type Attribute MUST NOT be=
 included
   within a Disconnect-Request.

   A NAS MUST respond t=
o a CoA-Request including a Service-Type
   Attribute with value "Author=
ize Only" with a CoA-NAK; a CoA-ACK MUST
   NOT be sent.  If the NAS doe=
s not support a Service-Type value of
   "Authorize Only" then it MUST r=
espond with a CoA-NAK; an Error-Cause
   value of 405 (Unsupported Servi=
ce) SHOULD be included.

   A CoA-Request containing a Service-Type A=
ttribute with value
   "Authorize Only" MUST in addition contain only NA=
S or session
   identification attributes, as well as a State Attribute.=
  If other
   attributes are included in such a CoA-Request, a CoA-NAK M=
UST be
   sent; an Error-Cause Attribute with value 401 (Unsupported Att=
ribute)
   SHOULD be included.

   If a CoA-Request packet includi=
ng a Service-Type value of "Authorize
   Only" is successfully processed=
, the NAS MUST respond with a CoA-NAK
   containing a Service-Type Attri=
bute with value "Authorize Only", and
   an Error-Cause Attribute with v=
alue 507 (Request Initiated).  The NAS
   then MUST send an Access-Reque=
st to the RADIUS server including a
   Service-Type Attribute with value=
 "Authorize Only", along with a
   State Attribute.  This Access-Request=
 SHOULD contain the NAS
   identification attributes from the CoA-Reques=
t, as well as the
   session identification attributes from the CoA-Requ=
est 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 Acc=
ess-
   Request that does not contain a User-Password, CHAP-Password, AR=
AP-
   Password or EAP-Message Attribute.  The RADIUS server
   then =
will respond to the Access-Request with an Access-Accept to
   (re-)auth=
orize the session or an Access-Reject to refuse to
   (re-)authorize it.=
"


= --_5e88a630-8c61-486b-8574-33631f4acbe7_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 13:45:28 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_8aca63d3-9a22-42d9-9861-de27090414f3_" From: Bernard Aboba To: Subject: Issue: Acct-Session-Id clarification Date: Sat, 26 May 2007 06:45:14 -0700 MIME-Version: 1.0 --_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: aboba@internaut.comDa= 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 Issue:  Acct-Session-Id clarification
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.c= om
Date first submitted: May 24, 2007
Reference:
Document: RFC357= 6bis-06
Comment type: Technical
Priority: S
Section: 3
Rational= e/Explanation of issue:

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.  This point seems worth addressing explicitly= . 

The proposed resolution is to insert the following text in = Section 3:
  As noted in [RFC2866] Section 5.5:

      An Acc=
ounting-Request packet MUST have an Acct-Session-Id.  An
      Access-Re=
quest packet MAY have an Acct-Session-Id; if it does,
      then the NAS=
 MUST use the same Acct-Session-Id in the Accounting-
      Request pack=
ets for that session.

   Since the Acct-Session-Id is optional in Ac=
cess-Requests, if the
   Dynamic Authorization Client only has access to=
 attributes sent to or
   by the RADIUS authentication server, then it w=
ill not necessarily
   know the Acct-Session-Id of the session it is att=
empting to target.

= --_8aca63d3-9a22-42d9-9861-de27090414f3_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 26 May 2007 13:27:32 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_57282573-2553-4b52-b6e7-3f2fc37bed35_" From: Bernard Aboba To: Subject: Issue: RPF Check Date: Sat, 26 May 2007 06:26:31 -0700 MIME-Version: 1.0 --_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: aboba@internaut.comDa= 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 Issue:  RPF Check
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.c= om
Date first submitted: May 24, 2007
Reference:
Document: RFC357= 6bis-06
Comment type: Technical
Priority: S
Section: Various
Ra= tionale/Explanation of issue:

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.   However, Section 6.1 seems to assume that this is the case.=   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.  I would therefore question whether it is appropriate to = recommend use of the RPF check by default.

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.  

The proposed resol= ution is as follows:

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.  Use the term "NAS" cons= istently when referring to the recipient of a CoA or Disconnect-Request pac= ket.

2. Add the following terms to the terminology section:

= Dynamic Authorization Client (DAC)
     The entity o= riginating Change of Authorization (CoA) or Disconnect-
  &nbs= p;  Requests.  While it is possible that the DAC is co-resident w= ith a
     RADIUS authentication or accounting serve= r, this need not
     necessarily be the case.
Network Access Server (NAS)
     The device provid= ing access to the network.  Sometimes also known
   =   as the Dynamic Authorization Server (DAS) or RADIUS client.

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. 
6.1.  Authorization Issues<=
br>
   Where a NAS is shared by multiple providers, it is undesirable fo=
r
   one provider to be able to send Disconnect-Request or CoA-Requests<=
br>   affecting the sessions of another provider.

   A NAS or proxy =
MUST silently discard Disconnect-Request or CoA-
   Request packets from=
 untrusted sources.  In situations where the
   Dynamic Authorization Cl=
ient is co-resident with a RADIUS
   authentication or accounting server=
, a proxy MAY perform a "reverse
   path forwarding" (RPF) check to veri=
fy that a Disconnect-Request or
   CoA-Request originates from an author=
ized Dynamic Authorization
   Client.  In addition, it SHOULD be possibl=
e to explicitly authorize
   additional sources of Disconnect-Request or=
 CoA-Request packets
   relating to certain classes of sessions.  For ex=
ample, a particular
   source can be explicitly authorized to send CoA-R=
equest packets
   relating to users within a set of realms.

   To=
 perform the RPF check, the proxy uses the session identification
   att=
ributes included in Disconnect-Request or CoA-Request packets, in
   ord=
er to determine the RADIUS server(s) to which an equivalent
   Access-Re=
quest could be routed.  If the source address of the
   Disconnect-Reque=
st or CoA-Request is within this set, then the CoA or
   Disconnect-Requ=
est is forwarded; otherwise it MUST be silently
   discarded.

   =
Typically the proxy will extract the realm from the Network Access
   Id=
entifier [RFC4282] included within the User-Name Attribute, and
   deter=
mine the corresponding RADIUS servers in the proxy routing
   tables.  T=
he RADIUS servers for that realm are then compared against
   the source=
 address of the packet.  Where no proxy is present, the RPF
   check wil=
l need to be performed by the NAS itself.

   Since authorization to =
send a Disconnect-Request or CoA-Request is
   determined based on the s=
ource address and the corresponding shared
   secret, the NASes or proxi=
es SHOULD configure a different shared
   secret for each Dynamic Author=
ization Client.

= --_57282573-2553-4b52-b6e7-3f2fc37bed35_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 23:19:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79F23.1E6AA7A5" Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Fri, 25 May 2007 16:19:16 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625040DC1DC@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue 226: RFC 3576bis and Renumbering Thread-Index: AcefHx6LEGAbX6owQVCt4nrrAHcXywAAzOhg From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , "Alan DeKok" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3215; t=1180135164; x=1180999164; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Issue=20226=3A=20=20RFC=203576bis=20and=20Renumbering |Sender:=20; bh=VqSnMs3hgTky4RLIs2T4ywuQO2F3LlNVXGpOeImQYkI=; b=grZInej96eF4SoE4umKWj60pjv0EZ2xnkpRU+N9dP9mZafC7M/f0PrseYww/WP0ZbwVSUhDA q7MWhXHODhpzsOCUwTTZj3asVBiYPcUhH3DtBGDiTT7DsgoRiSVoO9Lg; Authentication-Results: sj-dkim-5; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); 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
> Only if it supports RADIUS accounting, which I believe you = stated is=20 not
> mandatory.

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

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).  
At some=20 point isn't it want to get rid of that session state?  = The RADIUS=20 server never is notified that the session has ended (accounting=20 stops (which themselves may be insufficient for tracking user = sessions as=20 opposed to service sessions) only go to the accounting=20 server.
------_=_NextPart_001_01C79F23.1E6AA7A5-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 22:58:51 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_0676054e-79f8-4410-a012-a669e6c99223_" From: Bernard Aboba To: Avi Lior , Alan DeKok CC: Subject: RE: Issue 223: Event-Timestamp and Duplicate Detection Date: Fri, 25 May 2007 15:58:39 -0700 MIME-Version: 1.0 --_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 > No. If it was prohibited in an Access-Request, Accept, Reject etc... I= t
> would have specifically stated that.

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

Request  Acce= pt  Reject  Challenge   #    Attribute0-1      0       0=        0      &= nbsp;    70   ARAP-Password [Note 1]
0 &nb= sp;      0-1     0  =      0-1        = ; 71   ARAP-Features
0      &nbs= p; 0-1     0       0 = ;          72   ARAP= -Zone-Access
0-1      0    =    0       0-1   &nb= sp;     73   ARAP-Security
0+  &= nbsp;    0       0  =      0+        =   74   ARAP-Security-Data
0     =    0       0-1   &nb= sp; 0           75 &= nbsp; Password-Retry
0        0 =       0       0-1&nb= sp;        76   Prompt
0-1&= nbsp;     0       0 =       0       &= nbsp;   77   Connect-Info
0    &= nbsp;   0+      0    = ;   0          = 78   Configuration-Token
0+     &nbs= p; 0+      0+      0+&nbs= p;         79   EAP-Messa= ge [Note 1]
0-1      0-1    = ; 0-1     0-1       =   80   Message-Authenticator [Note 1]
0   =      0-1     0   &nb= sp;   0-1         84 = ;  ARAP-Challenge-Response
0      &nb= sp; 0-1     0       0&nbs= p;          85   Acc= t-Interim-Interval
0-1      0   =     0       0   = ;        87   NAS-Port-Id
0=         0-1     0&nb= sp;      0      &nbs= p;    88   Framed-Pool
Request  Accept&nbs= p; Reject  Challenge   #    Attribute
 
The first paragraph's first three sentences seem to imply that the att= ributes named can *only* be present in an Acccounting-Request.  Otherw= ise why wouldn't that paragraph have listed all the packets that these attr= ibutes could be included in?

= --_0676054e-79f8-4410-a012-a669e6c99223_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 22:50:42 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_cac1fce4-725a-48d0-80d7-db45e25e26bc_" From: Bernard Aboba To: "Glen Zorn (gwz)" , Alan DeKok CC: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Fri, 25 May 2007 15:50:36 -0700 MIME-Version: 1.0 --_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
> 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 c= an still send this attibute even if it doesn't support RADIUS accounting. <= BR>  
> presumably by letting the RADIUS server grovel through thousands of> accounting records (if they exist). Of course, knowing the location a= nd
> format of these records doesn't constitute an "undefined but inc= estuous
> relationship".

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_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 22:47:10 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_acfcda97-eee1-47fb-96b1-3624124bbc8e_" From: Bernard Aboba To: Alan DeKok , "Glen Zorn (gwz)" CC: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Fri, 25 May 2007 15:46:28 -0700 MIME-Version: 1.0 --_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 > 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 authenticatio= n
> 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 s= erver.
>
> Once the Acct-Session-Id is available to the authen= tication server, it
> can be used to tie authentication sessions to a= ccounting 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 sess= ion... 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 Acc= t-Session-Id; if it does,
      then the NAS MU= ST use the same Acct-Session-Id in the Accounting-
   &nb= sp;  Request packets for that session.
 
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 m= ay not necessarily be available.
 
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_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 17:17:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC 3576bis and Session State Date: Fri, 25 May 2007 10:14:37 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250407CFF3@xmb-sjc-215.amer.cisco.com> Thread-Topic: RFC 3576bis and Session State Thread-Index: Aceeq31GdvCifwWlTWyrwsdxr/WLvwALQd2gAAG+rFAAANk/8A== From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1153; t=1180113283; x=1180977283; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20RFC=203576bis=20and=20Session=20State |Sender:=20; bh=Sui4F2GTBh48PCTgF+YAChrHf7YTty5zMjDYRw4AoTE=; b=a9lmeRZ7Qx61wUwu0F04G5X/D6ZKHipJWbGzMSpf5UtYIRzS4xvsDCF0gjN+CbMwVep3fAms 0WdD+Np+1zLqh4FdajyqU0xIUaSxs7RCKMBlKpmZGM2Q39k241oQD20q; Authentication-Results: sj-dkim-7; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 15:59:22 +0000 From: "David B. Nelson" To: "'Avi Lior'" , Cc: "'Bernard Aboba'" Subject: RE: RFC 3576bis and Session State Date: Fri, 25 May 2007 11:57:08 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004601c79ee5$591a8c80$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acee5KTrw8FqzTWqRmeHPac2vVGoYAAAENIQ 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 15:55:51 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 223: Event-Timestamp and Duplicate Detection Date: Fri, 25 May 2007 11:55:16 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" , "Bernard Aboba" Cc: > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 15:52:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Fri, 25 May 2007 11:51:55 -0400 Message-ID: From: "Avi Lior" To: "David B. Nelson" , Cc: "Bernard Aboba" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 15:38:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Fri, 25 May 2007 11:37:56 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" , "Glen Zorn (gwz)" Cc: "Bernard Aboba" , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 15:27:22 +0000 From: "David B. Nelson" To: Subject: RFC 3576bis and Session State Date: Fri, 25 May 2007 11:24:59 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004201c79ee0$db4d7d20$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Aceeq31GdvCifwWlTWyrwsdxr/WLvwALQd2gAAG+rFA= 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 15:27:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: new Service-Type Date: Fri, 25 May 2007 11:26:37 -0400 Message-ID: From: "Avi Lior" To: "David B. Nelson" , =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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 14:59:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Fri, 25 May 2007 07:58:20 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250407CF32@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue 226: RFC 3576bis and Renumbering Thread-Index: Aceeq31GdvCifwWlTWyrwsdxr/WLvwALQd2g From: "Glen Zorn \(gwz\)" To: "Alan DeKok" Cc: "Bernard Aboba" , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2814; t=1180105114; x=1180969114; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Issue=20226=3A=20=20RFC=203576bis=20and=20Renumbering |Sender:=20; bh=2+9PvCe9mW5bUHdK7dgM3hefFq/Z0/Oem//i3v3UZr8=; b=M8dw3dlr/boLz2JHBeYlAcNjhRelEehkC46+4M9ZVw5wQpZ0QKbhclIQDitIUTA/2MkeKcgd 5qzT75OU6B7gc/hv64LRzYlA7qHThg3qPxoN/rVjTKnjM4a3ycqFVZyV; Authentication-Results: sj-dkim-5; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); Alan DeKok 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 14:20:41 +0000 From: "David B. Nelson" To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Fri, 25 May 2007 10:18:32 -0400 Organization: Elbrys Networks, Inc. Message-ID: <003e01c79ed7$934d9180$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AceerL8JXm0GNlRNRE6Urkp1J1hjUgAKjTDA 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 14:15:59 +0000 From: "David B. Nelson" To: Subject: RE: new Service-Type Date: Fri, 25 May 2007 10:13:08 -0400 Organization: Elbrys Networks, Inc. Message-ID: <003d01c79ed6$d1d22a70$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acee0e3mlmDhOMwTTD6542yX+BWJFgAA9LOg 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 13:30:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: new Service-Type Date: Fri, 25 May 2007 09:30:06 -0400 Message-ID: From: "Avi Lior" To: "Victor Gamov" Cc: 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Victor Gamov Sent: Tuesday, April 10, 2007 4:24 AM To: Bernard Aboba Cc: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 25 May 2007 09:03:37 +0000 Message-ID: <4656A640.6040202@nitros9.org> Date: Fri, 25 May 2007 11:02:56 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "Glen Zorn (gwz)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Issue 226: RFC 3576bis and Renumbering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 24 May 2007 21:04:51 +0000 From: "David B. Nelson" To: Subject: RE: I-D ACTION:draft-ietf-radext-rfc3576bis-06.txt Date: Thu, 24 May 2007 17:02:34 -0400 Organization: Elbrys Networks, Inc. Message-ID: <003601c79e46$da3abb90$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AceePXlhmXEei/fCQUeYt7ZwCLZA1gACKbDg 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 24 May 2007 19:51:02 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-06.txt Message-Id: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-24114444.I-D@ietf.org> 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: <2007-5-24114444.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 24 May 2007 00:33:16 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_36f8c6cf-d339-4319-8ee2-29f43acd6f7f_" From: Bernard Aboba To: Subject: Issue: Cleanup of Section 3 Date: Wed, 23 May 2007 17:32:59 -0700 MIME-Version: 1.0 --_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: aboba@internaut.comDa= 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 Issue:  Cleanup of Section 2.3, 3
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.c= om
Date first submitted: May 23, 2007
Reference:
Document: RFC357= 6bis-05
Comment type: Technical
Priority: S
Section: 2
Rational= e/Explanation of issue:
 
In looking over Section 2.3 and 3, there is a lot of text in Section 2= .3 Attributes heading relating to Proxy-State which probably belo= ngs in Section 3.  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.
 
The proposed fix is to change the text of Section 2.3 Attributes heading&nb= sp;from:
 
"Attributes

      In Disconnect and CoA-Req= uest packets, all Attributes are treated
      = as mandatory.  A NAS MUST respond to a CoA-Request containing one
&= nbsp;     or more unsupported Attributes or Attribute v= alues with a CoA-NAK;
      a Disconnect-Reques= t containing one or more unsupported Attributes
    =   or Attribute values MUST be answered with a Disconnect-NAK.  St= ate
      changes resulting from a CoA-Request = MUST be atomic: if the
      Request is success= ful, a CoA-ACK is sent, and all requested
     = authorization changes MUST be made.  If the CoA-Request is
 &= nbsp;    unsuccessful, a CoA-NAK MUST be sent, and the reque= sted
      authorization changes MUST NOT be ma= de.  Similarly, a state change
      MUST = NOT occur as a result of an unsuccessful Disconnect-Request;
  = ;    here a Disconnect-NAK MUST be sent.

  =     Within this specification attributes may be used for
=       identification, authorization or other purpo= ses.  RADIUS Attribue
      specifications= created after publication of this document SHOULD
   &nb= sp;  state whether an Attribute can be included in CoA or Disconnect      messages and if so, which messages it may = be included in and
      whether it serves as a= n identification or authorization attribute.

    = ;  Even if a NAS implements an attribute for use with RADIUS
 =      authentication and accounting, it is possible that= it will not
      support inclusion of that at= tribute within Disconnect-Request or
      CoA-= Request packets, given the difference in attribute semantics.
 &nbs= p;    This is true even for attributes specified as allowabl= e within
      Access-Accept packets (such as t= hose defined within [RFC2865],
      [RFC2868],= [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675],
  &nbs= p;   [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 response, possibly
    &n= bsp; containing an Error-Cause attribute with value Unsupported
 &n= bsp;    Attribute (401).

    &nbs= p; If there are any Proxy-State Attributes in a Disconnect-Request or
&n= bsp;     CoA-Request received from the server, the forw= arding proxy or NAS
      MUST include those Pr= oxy-State Attributes in its response to the
    &nbs= p; server.

      A forwarding proxy or NAS = MUST NOT modify existing Proxy-State,
      Sta= te, or Class Attributes present in the packet.  The forwarding
&nbs= p;     proxy or NAS MUST treat any Proxy-State attribut= es already in the
      packet as opaque data.&= nbsp; Its operation MUST NOT depend on the
     = ; content of Proxy-State attributes added by previous proxies.  The      forwarding proxy MUST NOT modify any other = Proxy-State Attributes
      that were in the p= acket; 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 reques= t, it MUST attach them to the
      response be= fore sending it.

      When the proxy forwa= rds a Disconnect or CoA-Request, it MAY add a
    &n= bsp; 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-St= ate Attribute MUST be added after any existing
    &= nbsp; Proxy-State attributes.  The forwarding proxy MUST NOT change th= e
      order of any attributes of the same typ= e, including Proxy-State.
      Other Attribute= s can be placed before, after or even between the
   &nbs= p;  Proxy-State Attributes.

      When= the proxy receives a response to a CoA-Request or Disconnect-
 &nb= sp;    Request, it MUST remove its own Proxy-State (the last= Proxy- State
      in the packet) before forwa= rding the response.  Since Disconnect
     = ; and CoA responses are authenticated on the entire packet contents,
&nb= sp;     the stripping of the Proxy-State Attribute inva= lidates the
      integrity check - so the prox= y needs to recompute it."
 
To:
 
"Attributes

      In Disconnect and CoA-Req= uest packets, all Attributes are treated
      = as mandatory.  If one or more authorization changes specified in a
=       CoA-Request cannot be carried out, the NAS M= UST send a CoA-NAK.  A
      NAS MUST resp= ond to a CoA-Request containing one or more
    &nbs= p; unsupported Attributes or Attribute values with a CoA-NAK; an
 &= nbsp;    Error-Cause Attribute with value 401 (Unsupported A= ttribute) or
      407 (Invalid Attribute Value= ) MAY be included.  A NAS MUST respond
    &nbs= p; to a Disconnect-Request containing one or more unsupported
 &nbs= p;    Attributes or Attribute values with a Disconnect-NAK; = an Error-
      Cause Attribute with value 401 = (Unsupported Attribute) or 407
      (Invalid A= ttribute Value) MAY be included.

      Stat= e changes resulting from a CoA-Request MUST be atomic: if the
 &nbs= p;    Request is successful, a CoA-ACK MUST be sent in reply= , and all
      requested authorization changes= MUST be made.  If the CoA-Request
      i= s unsuccessful, a CoA-NAK MUST be sent in reply, and the
  &nb= sp;   requested authorization changes MUST NOT be made.  Sim= ilarly, a
      state change MUST NOT occur as = a result of an unsuccessful
      Disconnect-Re= quest; a Disconnect-NAK MUST be sent in reply.

   &nb= sp;  Within this specification attributes can be used for
 &nb= sp;    identification, authorization or other purposes. = ; RADIUS Attribute
      specifications created= after publication of this document SHOULD
     = ; state whether an attribute can be included in CoA or Disconnect
 =      messages and if so, which messages it can be inclu= ded in and
      whether it serves as an identi= fication or authorization attribute.

      = Even if a NAS implements an attribute for use with RADIUS
  &n= bsp;   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 packets (such as those def= ined within [RFC2865],
      [RFC2868], [RFC286= 9], [RFC3162], [RFC3579], [RFC4372], [RFC4675],
    =   [RFC4818] and [RFC4849])."
 
Section 3, 3.1 and 3.2 are changed from:
 
"3.  Attributes

   In Disconnect-Request and CoA-Requ= est packets, certain attributes are
   used to uniquely identi= fy 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 f= or a
   Disconnect-Request or CoA-Request to be successful; ot= her session
   identification attributes SHOULD match.  W= here a mismatch of session
   identification attributes is det= ected, a Disconnect-NAK or CoA-NAK
   SHOULD  be sent.
   The ability to use NAS or session identification attribut= es to map to
   unique/multiple sessions is beyond the scope o= f this document.
   Identification attributes include NAS and = session identification
   attributes, as described below.
<= BR>     NAS identification attributes

 &nbs= p;   Attribute        &nb= sp;    #    Reference  Description
&n= bsp;    ---------       &= nbsp;    ---   ---------  -----------
&nbs= p;    NAS-IP-Address      &nbs= p; 4    [RFC2865]  The IPv4 address of the NAS.
&nbs= p;    NAS-Identifier       32&= nbsp;   [RFC2865]  String identifying the NAS.
 &nbs= p;   NAS-IPv6-Address     95   = ; [RFC3162]  The IPv6 address of the NAS.

   &nb= sp; Session identification attributes

     Attri= bute            = ;  #   Reference  Description
   &nbs= p; ---------          &nb= sp;  ---  ---------  -----------
    = User-Name           = ;   1   [RFC2865]  The name of the user
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    associated with the session.
   &nbs= p; NAS-Port          &nbs= p;    5   [RFC2865]  The port on which the            &n= bsp;            = ;            &n= bsp;     session is terminated.

  &nbs= p;  Attribute         &nb= sp;    #   Reference  Description
 &n= bsp;   ---------        &= nbsp;    ---  ---------  -----------
 &nbs= p;   Called-Station-Id     30   [RF= C2865]  The link address to which
     &nb= sp;            =             &nb= sp;            the s= ession is connected.
     Calling-Station-Id &n= bsp;  31   [RFC2865]  The link address from which
&n= bsp;            = ;            &n= bsp;            = ;     the session is connected.
   &n= bsp; Acct-Session-Id       44   [RF= C2866]  The identifier uniquely
      = ;            &n= bsp;            = ;            identif= ying the session
         &= nbsp;           &nbs= p;            &= nbsp;        on the NAS.
  =    Acct-Multi-Session-Id 50   [RFC2866]  The ident= ifier uniquely
         &nb= sp;            =             &nb= sp;        identifying related sessions.=
     NAS-Port-Id      = ;     87   [RFC2869]  String identifying= the port
          &n= bsp;            = ;            &n= bsp;       where the session is.
 &nb= sp;   Chargeable-User-      89 &nbs= p; [RFC4372]  The CUI associated with the
     = Identity           &= nbsp;           &nbs= p;      session.  Needed where a
 &nb= sp;            =             &nb= sp;            =     privacy NAI is used, because
    =             &nb= sp;            =             &nb= sp; the User-Name may not be
       &= nbsp;           &nbs= p;            &= nbsp;          unique (e.g. "a= nonymous").

   To address security concerns described in S= ection 6.1, either the
   User-Name or Chargeable-User-Identit= y 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, incl= usion of an Acct-Session-Id
   Attribute in a Disconnect-Reque= st or CoA-Request can assist with
   Diameter/RADIUS translati= on, since Diameter RAR and ASR commands
   include a Session-I= d AVP.  An Acct-Session-Id attribute SHOULD be
   include= d in Disconnect-Request and CoA-Request packets.

   Where = the Acct-Session-Id or Acct-Multi-Session-Id attributes are not
 &n= bsp; 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 th= e same user
   has multiple sessions on the NAS, or the privac= y NAI is used).  As a
   result, the Called-Station-Id, C= alling-Station-Id, NAS-Port and NAS-
   Port-Id attributes MAY= be used as additional session identification.

   To addre= ss security concerns described in Section 6.2, one or more of
 &nbs= p; the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present
&= nbsp;  in Disconnect-Request and CoA-Request packets; the NAS-Identifi= er
   Attribute MAY be present.

   If one or = more authorization changes specified in a CoA-Request
   canno= t be carried out, or if one or more attributes or attribute-
  = ; values is unsupported, a CoA-NAK MUST be sent.  Similarly, if there<= BR>   are one or more unsupported attributes or attribute values = in a
   Disconnect-Request, a Disconnect-NAK MUST be sent.
=    A Disconnect-Request MUST contain only NAS and session identif= ication
   attributes (see Section 3).  If other attribut= es are included in a
   Disconnect-Request, implementations MU= ST send a Disconnect-NAK; an
   Error-Cause Attribute with val= ue "Unsupported Attribute" MAY be
   included.

3.1.&nbs= p; Authorize Only

   Support for a CoA-Request including a= Service-Type Attribute with
   value "Authorize Only" is OPTI= ONAL on the NAS and RADIUS server.  A
   Service-Type Att= ribute 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 suppo= rt a Service-Type value of
   "Authorize Only" then it MUST re= spond with a CoA-NAK; an Error-Cause
   value of 405 (Unsuppor= ted Service) SHOULD be included.

   A CoA-Request containi= ng a Service-Type Attribute with value
   "Authorize Only" MUS= T in addition contain only NAS or session
   identification at= tributes, as well as a State Attribute.  If other
   attr= ibutes 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 packe= t including a Service-Type value of "Authorize
   Only" is suc= cessfully processed, the NAS MUST respond with a CoA-NAK
   co= ntaining 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 serv= er including a
   Service-Type Attribute with value "Authorize= Only".  This Access-
   Request SHOULD contain the NAS i= dentification attributes from the
   CoA-Request, as well as t= he session identification attributes from
   the CoA-Request l= egal for inclusion in an Access-Request as specified
   in [RF= C2865], [RFC2868], [RFC2869] and [RFC3162].  As noted in
 &nbs= p; [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be
&= nbsp;  included in an Access-Request that does not contain a User-Pass= word,
   CHAP-Password, ARAP-Password or EAP-Message Attribute= .  The RADIUS
   server then will respond to the Access-R= equest with an Access-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 pack= et and MUST be sent unmodified from the
   NAS to the RADIUS s= erver 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.  If futur= e extensions allow
      other kinds of authent= ication information to be conveyed, the
      a= ttribute for that can be used in an Access-Request instead of
 &nbs= p;    User-Password or CHAP-Password.

   In= order to satisfy the requirements of [RFC2865] Section 5.44, an
 &= nbsp; Access-Request with Service-Type=3D"Authorize-Only" MUST contain a   State attribute.

   In order to provide a St= ate attribute to the NAS, a server sending a
   CoA-Request wi= th a Service-Type value of "Authorize-Only" MUST
   include a = State Attribute, and the NAS MUST send the State Attribute
   = unmodified to the RADIUS server in the resulting Access-Request, if
&nbs= p;  any.  A NAS receiving a CoA-Request containing a Service-Type= value
   of "Authorize-Only" but lacking a State attribute MU= ST send a CoA-NAK
   and SHOULD include an Error-Cause attribu= te with value 402 (Missing
   Attribute).

   = The State Attribute is also available to be sent by the RADIUS server
&n= bsp;  to the NAS in a CoA-Request that also includes a Termination-Act= ion
   Attribute with the value of RADIUS-Request.  If th= e client performs
   the Termination-Action by sending a new A= ccess-Request upon
   termination of the current session, it M= UST include the State
   Attribute unchanged in that Access-Re= quest.  In either usage, the
   client MUST NOT interpret= the Attribute locally.  A CoA-Request
   packet must hav= e only zero or one State Attribute.  Usage of the
   Stat= e Attribute is implementation dependent."
 
 
To:
 
"3.  Attributes

   In Disconnect-Request and CoA-Requ= est packets, certain attributes are
   used to uniquely identi= fy 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 f= or a
   Disconnect-Request or CoA-Request to be successful; ot= her session
   identification attributes SHOULD match.  W= here a mismatch of session
   identification attributes is det= ected, a Disconnect-NAK or CoA-NAK
   SHOULD  be sent.
   The ability to use NAS or session identification attribut= es to map to
   unique/multiple sessions is beyond the scope o= f this document.
   Identification attributes include NAS and = session identification
   attributes, as described below.
<= BR>     NAS identification attributes

 &nbs= p;   Attribute        &nb= sp;    #    Reference  Description
&n= bsp;    ---------       &= nbsp;    ---   ---------  -----------
&nbs= p;    NAS-IP-Address      &nbs= p; 4    [RFC2865]  The IPv4 address of the NAS.
&nbs= p;    NAS-Identifier       32&= nbsp;   [RFC2865]  String identifying the NAS.
 &nbs= p;   NAS-IPv6-Address     95   = ; [RFC3162]  The IPv6 address of the NAS.

   &nb= sp; Session identification attributes

     Attri= bute            = ;  #   Reference  Description
   &nbs= p; ---------          &nb= sp;  ---  ---------  -----------
    = User-Name           = ;   1   [RFC2865]  The name of the user
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    associated with the session.
   &nbs= p; NAS-Port          &nbs= p;    5   [RFC2865]  The port on which the            &n= bsp;            = ;            &n= bsp;     session is terminated.
   &n= bsp; Called-Station-Id     30   [RFC2865]&nbs= p; The link address to which
       &= nbsp;           &nbs= p;            &= nbsp;          the session is = connected.
     Calling-Station-Id   = 31   [RFC2865]  The link address from which
  =             &nb= sp;            =             &nb= sp;   the session is connected.
     Acct-= Session-Id       44   [RFC2866]&nbs= p; The identifier uniquely
       &nb= sp;            =             &nb= sp;          identifying the s= ession
           = ;            &n= bsp;            = ;       on the NAS.
   &nbs= p; Acct-Multi-Session-Id 50   [RFC2866]  The identifier uniq= uely
           &= nbsp;           &nbs= p;            &= nbsp;      identifying related sessions.
 =     NAS-Port-Id       &nb= sp;   87   [RFC2869]  String identifying the port<= BR>            =             &nb= sp;            =       where the session is.
   &= nbsp; Chargeable-User-      89   [RFC437= 2]  The CUI associated with the
     Identity&n= bsp;            = ;            &n= bsp;    session.  Needed where a
   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  privacy NAI is used, because
     &nbs= p;            &= nbsp;           &nbs= p;            the Us= er-Name may not be
         = ;            &n= bsp;            = ;         unique (e.g. "anonymous")= .

   To address security concerns described in Section 6.1= , either the
   User-Name or Chargeable-User-Identity attribut= e SHOULD be present in
   Disconnect-Request and CoA-Request p= ackets.

   Where a Diameter client utilizes the same Sessi= on-Id for both
   authorization and accounting, inclusion of a= n 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.&nbs= p; An Acct-Session-Id attribute SHOULD be
   included in Disco= nnect-Request and CoA-Request packets.

   Where the Acct-S= ession-Id Attribute is not present in a CoA-Request
   or Disc= onnect-Request, it is possible that the User-Name or
   Charge= able-User-Identity attributes will not be sufficient to
   uni= quely identify the session (e.g. if the same user has multiple
 &nb= sp; 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-Id, NAS-Port and NAS-Port-Id attributes MA= Y be used as
   additional session identification.

&nbs= p;  To address security concerns described in Section 6.2, one or more= of
   the NAS-IP-Address or NAS-IPv6-Address Attributes SHOUL= D be present
   in Disconnect-Request and CoA-Request packets;= the NAS-Identifier
   Attribute MAY be present.

 =   A Disconnect-Request MUST contain only NAS and session identificatio= n
   attributes.  If other attributes are included in a D= isconnect-
   Request, implementations MUST send a Disconnect-= NAK; an Error-Cause
   Attribute with value "Unsupported Attri= bute" MAY be included."
 
3.1.  Proxy State

   If there are any Proxy-State att= ributes in a Disconnect-Request or
   CoA-Request received fro= m the server, the forwarding proxy or NAS
   MUST include thos= e Proxy-State attributes in its response to the
   server.
=
   A forwarding proxy or NAS MUST NOT modify existing Proxy-S= tate,
   State, or Class attributes present in the packet.&nbs= p; The forwarding
   proxy or NAS MUST treat any Proxy-State a= ttributes already in the
   packet as opaque data.  Its o= peration MUST NOT depend on the content
   of Proxy-State attr= ibutes added by previous proxies.  The forwarding
   prox= y MUST NOT modify any other Proxy-State attributes that were in
 &n= bsp; the packet; it may choose not to forward them, but it MUST NOT change<= BR>   their contents.  If the forwarding proxy omits the Pro= xy-State
   attributes in the request, it MUST attach them to = the response before
   sending it.

   When th= e proxy forwards a Disconnect or CoA-Request, it MAY add a
   = Proxy-State Attribute, but it MUST NOT add more than one.  If a
&nb= sp;  Proxy-State Attribute is added to a packet when forwarding the   packet, the Proxy-State Attribute MUST be added after any exi= sting
   Proxy-State attributes.  The forwarding proxy MU= ST NOT change the
   order of any attributes of the same type,= including Proxy-State.
   Other attributes can be placed befo= re, after or even between the
   Proxy-State attributes.
   When the proxy receives a response to a CoA-Request or Disco= nnect-
   Request, it MUST remove its own Proxy-State (the las= t Proxy- State in
   the packet) Attribute before forwarding t= he response.  Since
   Disconnect and CoA responses are a= uthenticated on the entire packet
   contents, the stripping o= f the Proxy-State Attribute invalidates the
   integrity check= - so the proxy needs to recompute it.
 
3.2.  Authorize Only

   Support for a CoA-Request inc= luding a Service-Type Attribute with
   value "Authorize Only"= is OPTIONAL on the NAS and RADIUS server.  A
   Service-= Type Attribute MUST NOT be included within a Disconnect-
   Re= quest.

   A NAS MUST respond to a CoA-Request including a = Service-Type
   Attribute with value "Authorize Only" with a C= oA-NAK; a CoA-ACK MUST
   NOT be sent.  If the NAS does n= ot 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 Attribute with value
   "Authorize O= nly" MUST in addition contain only NAS or session
   identific= ation attributes, as well as a State Attribute.  If other
 &nb= sp; attributes are included in such a CoA-Request, a CoA-NAK MUST be
&nb= sp;  sent; an Error-Cause Attribute with value 401 (Unsupported Attrib= ute)
   SHOULD be included.

   If a CoA-Reque= st packet including a Service-Type value of "Authorize
   Only= " is successfully processed, the NAS MUST respond with a CoA-NAK
 &= nbsp; containing a Service-Type Attribute with value "Authorize Only", and<= BR>   an Error-Cause Attribute with value 507 (Request Initiated)= .  The NAS
   then MUST send an Access-Request to the RAD= IUS server including a
   Service-Type Attribute with value "A= uthorize Only".  This Access-
   Request SHOULD contain t= he NAS identification attributes from the
   CoA-Request, as w= ell as the session identification attributes from
   the CoA-R= equest legal for inclusion in an Access-Request as specified
  = ; in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].  As noted in
&n= bsp;  [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD= be
   included in an Access-Request that does not contain a U= ser-Password,
   CHAP-Password, ARAP-Password or EAP-Message A= ttribute.  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.=

3.3.  State

   The State Attribute is availab= le to be sent by the RADIUS server to
   the NAS in a CoA-Requ= est packet and MUST be sent unmodified from the
   NAS to the = RADIUS server in a subsequent ACK or NAK packet.

   [RFC28= 65] Section 5.44 states:

      An Access-Re= quest MUST contain either a User-Password or a CHAP-
   &= nbsp;  Password or State.  An Access-Request MUST NOT contain bot= h a
      User-Password and a CHAP-Password.&nb= sp; If future extensions allow
     other kinds of a= uthentication information to be conveyed, the
    &n= bsp; attribute for that can be used in an Access-Request instead of
&nbs= p;     User-Password or CHAP-Password.

 &nb= sp; In order to satisfy the requirements of [RFC2865] Section 5.44, an
&= nbsp;  Access-Request with Service-Type=3D"Authorize-Only" MUST contai= n a
   State attribute.

   In order to provid= e a State attribute to the NAS, a server sending a
   CoA-Requ= est with a Service-Type value of "Authorize-Only" MUST
   incl= ude a State Attribute, and the NAS MUST send the State Attribute
 &= nbsp; unmodified to the RADIUS server in the resulting Access-Request, if   any.  A NAS receiving a CoA-Request containing a Servic= e-Type value
   of "Authorize-Only" but lacking a State attrib= ute MUST send a CoA-NAK
   and SHOULD include an Error-Cause a= ttribute with value 402 (Missing
   Attribute).

 &= nbsp; The State Attribute is also available to be sent by the RADIUS server=
   to the NAS in a CoA-Request that also includes a Terminati= on-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 Acc= ess-Request.  In either usage, the
   client MUST NOT int= erpret the Attribute locally.  A CoA-Request
   packet mu= st have only zero or one State Attribute.  Usage of the
  = ; State Attribute is implementation dependent."
= --_36f8c6cf-d339-4319-8ee2-29f43acd6f7f_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 24 May 2007 00:22:25 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_f486038a-c510-4004-a71f-d628c9a73d34_" From: Bernard Aboba To: Subject: Re: Issue 227: Proxy State Date: Wed, 23 May 2007 17:22:12 -0700 MIME-Version: 1.0 --_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 To: Bernard Aboba 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 To: Bernard Aboba 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)" To: Bernard Aboba 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 Alan DeKok said:
 
"> [BA] This suggests that paragraphs 3 and 4 in the text below are not<= BR>> correct. Any suggestions on how we can fix it?

  Before= I do that, it would appear that my recommendation here is
opposite to w= hat RFC 3576 says.  Are we OK with changing the
recommendation in -= bis?

  That is, do current implementations behave as per RFC 35= 76?  If so, I
would prefer to maintain inter-operability.  The= text can then be left
as-is.

  If not, then the implementat= ions do not use Proxy-State, and I would
prefer to replace the paragraph= s with other text explaining why
Proxy-State is not used.  The text= in RFC 3576 permits implementations
to receive Proxy-State, but to not = forward it.  Maybe the
implementations have chosen that method.
=
  My preference is to have one recommended method of operation, ra= ther
than 2-3.

  I'd like to get clarity on those questions = before submitting suggested
text."
 
Some responses from RFC 3576 implementers are enclosed below  Any= thoughts on how we should proceed?
 
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:
 
3.1.  Proxy State

   If there are any Proxy-State att= ributes in a Disconnect-Request or
   CoA-Request received fro= m the server, the forwarding proxy or NAS
   MUST include thos= e Proxy-State attributes in its response to the
   server.
=
   A forwarding proxy or NAS MUST NOT modify existing Proxy-S= tate,
   State, or Class attributes present in the packet.&nbs= p; The forwarding
   proxy or NAS MUST treat any Proxy-State a= ttributes already in the
   packet as opaque data.  Its o= peration MUST NOT depend on the content
   of Proxy-State attr= ibutes added by previous proxies.  The forwarding
   prox= y MUST NOT modify any other Proxy-State attributes that were in
 &n= bsp; the packet; it may choose not to forward them, but it MUST NOT change<= BR>   their contents.  If the forwarding proxy omits the Pro= xy-State
   attributes in the request, it MUST attach them to = the response before
   sending it.

   When th= e proxy forwards a Disconnect or CoA-Request, it MAY add a
   = Proxy-State Attribute, but it MUST NOT add more than one.  If a
&nb= sp;  Proxy-State Attribute is added to a packet when forwarding the   packet, the Proxy-State Attribute MUST be added after any exi= sting
   Proxy-State attributes.  The forwarding proxy MU= ST NOT change the
   order of any attributes of the same type,= including Proxy-State.
   Other attributes can be placed befo= re, after or even between the
   Proxy-State attributes.
   When the proxy receives a response to a CoA-Request or Disco= nnect-
   Request, it MUST remove its own Proxy-State (the las= t Proxy- State in
   the packet) Attribute before forwarding t= he response.  Since
   Disconnect and CoA responses are a= uthenticated on the entire packet
   contents, the stripping o= f the Proxy-State Attribute invalidates the
   integrity check= - 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: Wed, 16 May 2007 13:37:41 -0700
From: James Blaisdell <james@mocana.com>
To: Bernard Aboba = <aboba@internaut.com>
S= ubject: Re: RFC 3576bis Open Issues
 
Hello Bernard,
I don't believe either of these items are an issue for us.  It's been = a while, since we implemented RFC-3576 CoA support.  Issue #227 does n= ot 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 notifications, building varbinds, other sundry tasks --- the actual m= essage processing is left up to the application.
 
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= server that supported this capability when we released this feature last y= ear.

At 12:42 PM -0700 5/16/07, Bernard Aboba wrote:
>In the IETF RADE= XT WG,  we have two open issues on RFC 3576bis:
>
>Issue 2= 26: RFC 3576bis and Renumbering
>Issue 227: Proxy State
>
&g= t;Details on the open issues are
>available at:
>http://www.dri= zzle.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 o= r
>Framed-IPv6-Prefix/Framed-Interface-Id as a Session Identification=
>attribute (as opposed to a parameter that can be changed in a
&g= t;CoA-Request)?
>b.  Have you implemented the proxy state algori= thm described below (as
>opposed to an alternative approach)?
>=
>Any 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
>
>  &n= bsp;  If there are any Proxy-State Attributes in a Disconnect-Request = or
>     CoA-Request received from the server, th= e forwarding proxy or NAS
>     MUST include thos= e Proxy-State Attributes in its response to the
>   &n= bsp; server.
>
>     A forwarding proxy or = NAS MUST NOT modify existing Proxy-State,
>     S= tate, or Class Attributes present in the packet.  The forwarding
&g= t;     proxy or NAS MUST treat any Proxy-State attribut= es already in the
>     packet as opaque data.&nb= sp; Its operation MUST NOT depend on the
>     co= ntent of Proxy-State attributes added by previous proxies.  The
>= ;     forwarding proxy MUST NOT modify any other Proxy-= State Attributes
>     that were in the packet; i= t may choose not to forward them, but it
>     MU= ST NOT change their contents.  If the forwarding proxy omits the
&g= t;     Proxy-State Attributes in the request, it MUST a= ttach them to the
>     response before sending i= t.
>
>     When the proxy forwards a Discon= nect or CoA-Request, it MAY add a
>     Proxy-Sta= te Attribute, but it MUST NOT add more than one.  If a
> &n= bsp;   Proxy-State Attribute is added to a packet when forwarding= the
>     packet, the Proxy-State Attribute MUST= be added after any existing
>     Proxy-State at= tributes.  The forwarding proxy MUST NOT change the
>  = ;   order of any attributes of the same type, including Proxy-Sta= te.
>     Other Attributes can be placed before, = after or even between the
>     Proxy-State Attri= butes.
>
>     When the proxy receives a re= sponse to a CoA-Request or Disconnect-
>     Requ= est, it MUST remove its own Proxy-State (the last Proxy- State
> = ;    in the packet) before forwarding the response.  Si= nce Disconnect
>     and CoA responses are authen= ticated on the entire packet contents,
>     the = stripping of the Proxy-State Attribute invalidates the
>  &= nbsp;  integrity check - 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 -0400
From: Michael Lecuyer <mjl@theorem.com>
To: Bernard Aboba &l= t;aboba@internaut.com>
Sub= ject: Re: RFC 3576bis Open Issues
 
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.
 
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 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.
 
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.  
The Server uses the originally defined session identifier attributes found = in RFC 3576:
 
User-Name
NAS-Port
Framed-IP-Address
Called-Station-Id
Calling-= Station-Id
Acct-Session-Id
Acct-Multi-Session-Id
NAS-Port-Type
= NAS-Port-Id
Originating-Line-Info
Framed-Interface-Id
Framed-IPv6-= Prefix
 
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.
 
=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 -0700
From: "Murtaza Chiba (mchiba)" <= ;mchiba@cisco.com>
To: Bernar= d Aboba <aboba@internaut.com&= gt;
Subject: RE: RFC 3576bis Open Issues
 
Hi Bernard,
 
The answers are the question a) is configurable and b) is not implemented.<= BR>  
Regards,
Murtaza



= --_f486038a-c510-4004-a71f-d628c9a73d34_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 24 May 2007 00:11:37 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_116ae3dd-96c1-4f59-805d-380fbdf1233d_" From: Bernard Aboba To: Subject: RE: Issue: Error-Cause Attribute in Disconnect-ACK? Date: Wed, 23 May 2007 17:11:28 -0700 MIME-Version: 1.0 --_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 . 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: bernard_aboba@hotmail.comTo: radiusext@ops.ietf.orgSubject: 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: bernard_aboba@hotmail.com> To: radius= ext@ops.ietf.org> 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= boba@internaut.com> 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= st@ops.ietf.org with> the word 'unsubscribe' in a single line as the messag= e text body.> archive: = --_116ae3dd-96c1-4f59-805d-380fbdf1233d_ Content-Type: text/html; 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 taki= ng that into account.
 
3.5.  Error-Cause

   Description

  &= nbsp;   It is possible that the NAS cannot honor Disconnect-Reque= st or
      CoA-Request packets for some reason= .  The Error-Cause Attribute
      provide= s more detail on the cause of the problem.  It MAY be
  &= nbsp;   included within Disconnect-NAK and CoA-NAK packets.
      A summary of the Error-Cause Attribute for= mat is shown below.  The
      fields are = transmitted from left to right.

      = 0            &= nbsp;      1      &n= bsp;            2&nb= sp;            =       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
 &nbs= p;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      |     Typ= e      |    Length   = ;  |           =   Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     &nbs= p;           Value (cont)=          |
   &nb= sp;  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      101 for Error-Cause

   Len= gth

      6

   Value
      The Value field is four octets, containing= an integer specifying
      the cause of the e= rror. Values 0-199 and 300-399 are reserved.
    &nb= sp; Values 200-299 represent successful completion, so that these
 =      values may only be sent within Disconnect-ACK or C= oA-ACK packets
      and MUST NOT be sent withi= n a Disconnect-NAK or CoA-NAK.  Values
    &nbs= p; 400-499 represent fatal errors committed by the RADIUS server, so
&nb= sp;     that they MAY be sent within CoA-NAK or Disconn= ect-NAK packets,
      and MUST NOT be sent wit= hin CoA-ACK or Disconnect-ACK packets.
      Va= lues 500-599 represent fatal errors occurring on a NAS or RADIUS
 &= nbsp;    proxy, so that they MAY be sent within CoA-NAK and = Disconnect-NAK
      packets, and MUST NOT be s= ent within CoA-ACK or Disconnect-ACK
      pack= ets.  Error-Cause values SHOULD be logged by the RADIUS
  = ;    server.  Error-Code values (expressed in decimal) = include:

       #   &nb= sp; Value
      ---    -----
=       201    Residual Session Conte= xt Removed
      202    Invalid = EAP Packet (Ignored)
      401   = ; Unsupported Attribute
      402  &n= bsp; Missing Attribute
      403  &nb= sp; NAS Identification Mismatch
      404 =    Invalid Request
      405 &nb= sp;  Unsupported Service
      406 &n= bsp;  Unsupported Extension
      407 = ;   Invalid Attribute Value
      501=     Administratively Prohibited
    &= nbsp; 502    Request Not Routable (Proxy)
  &nb= sp;   503    Session Context Not Found
 &n= bsp;    504    Session Context Not Removable<= BR>      505    Other Proxy Process= ing Error
      506    Resources= Unavailable
      507    Reques= t Initiated

      "Residual Session Context= Removed" is sent in response to a
      Discon= nect-Request if the user session is no longer active, but
  &n= bsp;   residual session context was found and successfully remove= d.  This
      value is only sent within a= Disconnect-ACK and MUST NOT be sent
      with= in a CoA-ACK, Disconnect-NAK or CoA-NAK.

    &nb= sp; "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT
&n= bsp;     be sent by implementations of this specificati= on.

      "Unsupported Attribute" is a fata= l error sent if a Request
      contains an att= ribute (such as a Vendor-Specific or EAP-Message
    = ;  Attribute) that is not supported.

    &n= bsp; "Missing Attribute" is a fatal error sent if critical attributes
&n= bsp;     (such as NAS or session identification attribu= tes) are missing
      from a Request.

&= nbsp;     "NAS Identification Mismatch" is a fatal erro= r sent if one or more
      NAS identification = attributes (see Section 3) do not match the
    &nbs= p; identity of the NAS receiving the Request.

   &nbs= p;  "Invalid Request" is a fatal error sent if some other aspect of      the Request is invalid, such as if one or m= ore attributes (such as
      EAP- Message Attr= ibute(s)) are not formatted properly.

     = "Unsupported Service" is a fatal error sent if a Service-Type
 &nb= sp;    Attribute included with the Request is sent with an i= nvalid or
      unsupported value.  This e= rror cannot be sent in response to a
      Disc= onnect-Request.

      "Unsupported Extensio= n" is a fatal error sent due to lack of
      s= upport for an extension such as Disconnect and/or CoA packets.
 &nb= sp;    This will typically be sent by a proxy receiving an I= CMP port
      unreachable message after attemp= ting to forward a Request to the
      NAS.
=
      "Unsupported Attribute Value" is a fatal= error sent if a Request
      contains an attr= ibute with an unsupported value.

      "Adm= inistratively Prohibited" is a fatal error sent if the NAS is
 &nbs= p;    configured to prohibit honoring of Request packets for= the
      specified session.

 &nbs= p;    "Request Not Routable" is a fatal error which MAY be s= ent by a
      RADIUS proxy and MUST NOT be sen= t by a NAS.  It indicates that the
      R= ADIUS proxy was unable to determine how to route the Request to
 &n= bsp;    the NAS.  For example, this can occur if the re= quired entries are
      not present in the pro= xy's realm routing table.

      "Session Co= ntext Not Found" is a fatal error sent if the session
   =    context identified in the Request does not exist on the NAS.
      "Session Context Not Removable" is a f= atal error sent in response
      to a Disconne= ct-Request if the NAS was able to locate the session
   &= nbsp;  context, but could not remove it for some reason.  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 Re= quest that could not be processed by a proxy, for reasons
  &n= bsp;   other than routing.

      = "Resources Unavailable" is a fatal error sent when a Request could
 = ;     not be honored due to lack of available NAS resou= rces (memory,
      non- volatile storage, etc.= ).

      "Request Initiated" is a fatal err= or sent in response to a CoA-
      Request inc= luding a Service-Type Attribute with a value of
    =   "Authorize Only".  It indicates that the CoA-Request has not be= en
      honored, but that a RADIUS Access-Requ= est including a Service-Type
      Attribute wi= th value "Authorize Only" is being sent to the RADIUS
   =    server.

4.  Diameter Considerations

 &= nbsp; Due to differences in handling change-of-authorization requests in   RADIUS and Diameter, it may be difficult or impossible for a<= BR>   Diameter/RADIUS gateway to successfully translate a Diamete= r Re-Auth-
   Request (RAR) to a CoA-Request and vice versa.&n= bsp; For example, since a
   CoA-Request only initiates an aut= horization change but does not
   initiate re-authentication, = a RAR command containing a Re-Auth-
   Request-Type AVP with v= alue "AUTHORIZE_AUTHENTICATE" cannot be
   directly translated= to a CoA-Request.  A Diameter/RADIUS gateway
   receivin= g a CoA-Request containing authorization changes will need to
 &nbs= p; translate this into two Diameter exchange.  First, the
 &nb= sp; Diameter/RADIUS gateway will issue a RAR command including a Session-   Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE = ONLY".
   Then the Diameter/RADIUS gateway will respond to the= ensuing access
   request with a response including the autho= rization attributes
   gleaned from the CoA-Request.  For= the translation to be possible,
   the CoA-Request MUST inclu= de a Acct-Session-Id Attribute.  If the

   Diameter c= lient uses the same Session-Id for both authorization and
   a= ccounting, then the Diameter/RADIUS gateway can copy the contents of
&nb= sp;  the Acct-Session-Id Attribute into the Session-Id AVP;  othe= rwise, it
   will need to map the Acct-Session-Id value to an = equivalent Session-
   Id for use within a RAR command.
   To simplify translation between RADIUS and Diameter, a server=
   compliant with this specification MAY include a Service-Ty= pe
   Attribute with value "Authorize Only" within a CoA-Reque= st.  Such a
   CoA-Request MUST contain a State Attribute= .  A NAS supporting the
   "Authorize Only" Service-Type = within a CoA-Request responds with a
   CoA-NAK containing a S= ervice-Type Attribute with value "Authorize
   Only", and an E= rror-Cause Attribute with value "Request Initiated".
   The NA= S will then send an Access-Request containing a Service-Type
  = ; Attribute with a value of "Authorize Only", along with a State
 &= nbsp; Attribute.  A Diameter/RADIUS gateway receiving a CoA-Request   containing a Service-Type with value "Authorize Only" transla= tes 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
   value in th= e success category, then an Error-Cause Attribute with
   valu= e "Request Initiated" is included in the CoA-NAK.   If the
&nb= sp;  Result-Code AVP in the RAA has a value indicating a Protocol Erro= r or
   a Transient or Permanent Failure, then an alternate Er= ror-Cause
   Attribute is returned as suggested below.

=    Within Diameter, a server can request that a session be aborte= d by
   sending an Abort-Session-Request (ASR), identifying th= e session to be
   terminated using Session-ID and User-Name A= VPs.  The ASR command is
   translated to a Disconnect-Re= quest containing an Acct-Session-Id and
   User-Name attribute= .  If the Diameter client utilizes the same
   Session-Id= in both authorization and accounting, then the value of
   th= e Session-ID AVP may be placed in the Acct-Session-Id attribute;
 &= nbsp; otherwise the value of the Session-ID AVP will need to be mapped to   an appropriate Acct-Session-Id value.   For a Disc= onnect-Request to
   be translatable to an ASR, an Acct-Sessio= n-Id attribute MUST be
   present.  If the Diameter clien= t utilizes the same Session-Id in both
   authorization and ac= counting, then the value of the Acct-Session-Id
   may be plac= ed into the Session-ID AVP within the ASR;  otherwise the
 &nb= sp; value of the Acct-Session-Id will need to be mapped to an appropriate   Session-ID value.

   An Abort-Session-Answe= r (ASA) command is sent in response to an ASR
   in order to i= ndicate the disposition of the request.  A
   Diameter/RA= DIUS gateway receiving a Disconnect-ACK translates this to
   = an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS".  A
&nb= sp;  Disconnect-NAK received from the server is translated to an ASA   command with a Result-Code AVP which depends on the value of= the
   Error-Cause Attribute.  Suggested translations be= tween Error-Cause
   Attribute values and Result-Code AVP valu= es are included below:

    #    Error-= Cause Attribute Value   Result-Code AVP
   --- =   ---------------------------  ------------------------
 =   201   Residual Session Context     DIA= METER_SUCCESS
         Removed   202   Invalid EAP Packet    &n= bsp;      DIAMETER_LIMITED_SUCCESS
  =        (Ignored)
   401 &nb= sp; Unsupported Attribute        DIAMETE= R_AVP_UNSUPPORTED
   402   Missing Attribute &n= bsp;          DIAMETER_MISSING= _AVP
   403   NAS Identification   &n= bsp;       DIAMETER_REALM_NOT_SERVED
 = ;        Mismatch
   404&nb= sp;  Invalid Request        &n= bsp;     DIAMETER_UNABLE_TO_COMPLY
   405&= nbsp;  Unsupported Service       &n= bsp;  DIAMETER_COMMAND_UNSUPPORTED
   406   Uns= upported Extension        DIAMETER_APPLI= CATION_UNSUPPORTED
   407   Invalid Attribute Value&= nbsp;     DIAMETER_INVALID_AVP_VALUE
   50= 1   Administratively       &nb= sp;     DIAMETER_AUTHORIZATION_REJECTED
  =        Prohibited
   502 &n= bsp; Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER
  = ; 503   Session Context Not Found    DIAMETER_UNKN= OWN_SESSION_ID
   504   Session Context Not &nb= sp;        DIAMETER_AUTHORIZATION_REJECT= ED
         Removable
 &= nbsp; 505   Other Proxy Processing     &= nbsp; DIAMETER_UNABLE_TO_COMPLY
      &nbs= p;  Error
   506   Resources Unavailable &= nbsp;      DIAMETER_RESOURCES_EXCEEDED
 &n= bsp; 507   Request Initiated      &= nbsp;     DIAMETER_SUCCESS

   Since bo= th the ASR/ASA and Disconnect-Request/Disconnect-
   NAK/Disco= nnect-ACK exchanges involve just a request and response,
   in= clusion of an "Authorize Only" Service-Type within a Disconnect-
 &= nbsp; Request is not needed to assist in Diameter/RADIUS translation, and   may make translation more difficult.  As a result, the = Service-Type
   Attribute MUST NOT be used within a Disconnect= -Request.

5.  IANA Considerations

   This docu= ment uses the RADIUS [RFC2865] namespace, see
   <http://ww= w.iana.org/assignments/radius-types>.  In addition to the
 =   allocations already made in [RFC3576], this specification requests   allocation of an additional value of the Error-Cause Attribu= te (101):

    #    Value
 &nbs= p; ---   -----
   407   Invalid Attribute = Value



From: bernard_aboba@hotmail.com
To: radiusext@ops.ietf.org
Subject: R= E: Issue: Error-Cause Attribute in Disconnect-ACK?
Date: Tue, 22 May 200= 7 12:57:11 -0700

I also noticed another oddity in usage of the Error-Cause Attribute.
&n= bsp;
It is stated that a CoA-NAK MUST always be sent in response to= a CoA-Request including a Service-Type Attribute with value "Authoriz= e Only".  If the CoA-Request can be processed, then sending an Error-C= ause Attribute with value 507 (Request Initiated) is required.  Howeve= r, if the CoA-Request cannot be processed, sending an Error-Cause attribute= is optional.  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?   


> From: bernard_aboba@hotmail.com
> To: radiuse= xt@ops.ietf.org
> Subject: Issue: Error-Cause Attribute in Disconnect= -ACK?
> Date: Tue, 22 May 2007 10:31:40 -0700
>
>
&g= t; Issue: Error-Cause Attribute in Disconnect-ACK?
> Submitter name: = Bernard Aboba
> Submitter email address: aboba@internaut.com
> = Date first submitted: May 22, 2007
> Reference:
> Document: RF= C3576bis-05
> Comment type: Technical
> Priority: S
> Sec= tion: 3.4
> Rationale/Explanation of issue:
>
> In the p= rocess of editing the attribute table to address Issue 226, I noticed an od= dity.
>
> 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
> inclu= ded within Disconnect-ACK, Disconnect-NAK and CoA-NAK
> messages.
= >
> Why would an Error-Cause Attribute be included in a Disconnec= t-ACK? It is not allowed in a CoA-ACK, for example.
> --
> to = unsubscribe send a message to radiusext-request@ops.ietf.org with
> t= he word 'unsubscribe' in a single line as the message text body.
> ar= chive: <http://psg.com/lists/radiusext/>

= --_116ae3dd-96c1-4f59-805d-380fbdf1233d_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 24 May 2007 00:09:16 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_620ce6a7-56f2-442e-8219-cf050028ab68_" From: Bernard Aboba To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Wed, 23 May 2007 17:08:23 -0700 MIME-Version: 1.0 --_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 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:  
3.  Attributes

   In Disconnect-Request and CoA-Reque= st packets, certain attributes are
   used to uniquely identif= y the NAS as well as a user session on the
   NAS.  All N= AS identification attributes included in a Request packet
   M= UST match in order for a Disconnect-Request or CoA-Request to be
 &= nbsp; 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 fo= r a
   Disconnect-Request or CoA-Request to be successful; oth= er session
   identification attributes SHOULD match.  Wh= ere a mismatch of session
   identification attributes is dete= cted, a Disconnect-NAK or CoA-NAK
   SHOULD  be sent.
=
   The ability to use NAS or session identification attribute= s to map to
   unique/multiple sessions is beyond the scope of= this document.
   Identification attributes include NAS and s= ession identification
   attributes, as described below.
     NAS identification attributes

  = ;   Attribute        &nbs= p;    #    Reference  Description
&nb= sp;    ---------       &n= bsp;    ---   ---------  -----------
 = ;    NAS-IP-Address       = ; 4    [RFC2865]  The IPv4 address of the NAS.
 = ;    NAS-Identifier       32&n= bsp;   [RFC2865]  String identifying the NAS.
  = ;   NAS-IPv6-Address     95   = [RFC3162]  The IPv6 address of the NAS.

   &nbs= p; Session identification attributes

     Attrib= ute            =   #   Reference  Description
    = ; ---------          &nbs= p;  ---  ---------  -----------
     = User-Name           =    1   [RFC2865]  The name of the user
 &n= bsp;            = ;            &n= bsp;            = ;    associated with the session.
    = ; NAS-Port           = ;    5   [RFC2865]  The port on which the
=             &nb= sp;            =             &nb= sp;     session is terminated.
   &nb= sp; Called-Station-Id     30   [RFC2865] = ; The link address to which
       &n= bsp;            = ;            &n= bsp;          the session is c= onnected.
     Calling-Station-Id    = 31   [RFC2865]  The link address from which
  &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   the session is connected.
     Acct-S= ession-Id       44   [RFC2866] = ; The identifier uniquely
       &nbs= p;            &= nbsp;           &nbs= p;          identifying the se= ssion
           =             &nb= sp;            =        on the NAS.
    = ; Acct-Multi-Session-Id 50   [RFC2866]  The identifier uniqu= ely
           &n= bsp;            = ;            &n= bsp;      identifying related sessions.
 &= nbsp;   NAS-Port-Id       &nbs= p;   87   [RFC2869]  String identifying the port            &= nbsp;           &nbs= p;            &= nbsp;     where the session is.
   &n= bsp; Chargeable-User-      89   [RFC4372= ]  The CUI associated with the
     Identity&nb= sp;            =             &nb= sp;    session.  Needed where a
   &n= bsp;            = ;            &n= bsp;            = ;  privacy NAI is used, because
      = ;            &n= bsp;            = ;            the Use= r-Name may not be
         =             &nb= sp;            =          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 pa= ckets.

   Where a Diameter client utilizes the same Sessio= n-Id for both
   authorization and accounting, inclusion of an= Acct-Session-Id
   Attribute in a Disconnect-Request or CoA-R= equest can assist with
   Diameter/RADIUS translation, since D= iameter RAR and ASR commands
   include a Session-Id AVP. = ; An Acct-Session-Id attribute SHOULD be
   included in Discon= nect-Request and CoA-Request packets.

   Where the Acct-Se= ssion-Id Attribute is not present in a CoA-Request
   or Disco= nnect-Request, it is possible that the User-Name or
   Chargea= ble-User-Identity attributes will not be sufficient to
   uniq= uely identify the session (e.g. if the same user has multiple
 &nbs= p; 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, C= alling-
   Station-Id, NAS-Port and NAS-Port-Id attributes MAY= be used as
   additional session identification.

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

 &= nbsp; A Disconnect-Request MUST contain only NAS and session identification=
   attributes.  If other attributes are included in a Di= sconnect-
   Request, implementations MUST send a Disconnect-N= AK; an Error-Cause
   Attribute with value "Unsupported Attrib= ute" MAY be included.
 
3.2.  Authorize Only

   Support for a CoA-Request inc= luding a Service-Type Attribute with
   value "Authorize Only"= is OPTIONAL on the NAS and RADIUS server.  A
   Service-= Type Attribute MUST NOT be included within a Disconnect-
   Re= quest.

   A NAS MUST respond to a CoA-Request including a = Service-Type
   Attribute with value "Authorize Only" with a C= oA-NAK; a CoA-ACK MUST
   NOT be sent.  If the NAS does n= ot 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 Attribute with value
   "Authorize O= nly" MUST in addition contain only NAS or session
   identific= ation attributes, as well as a State Attribute.  If other
 &nb= sp; attributes are included in such a CoA-Request, a CoA-NAK MUST be
&nb= sp;  sent; an Error-Cause Attribute with value 401 (Unsupported Attrib= ute)
   SHOULD be included.

   If a CoA-Reque= st packet including a Service-Type value of "Authorize
   Only= " is successfully processed, the NAS MUST respond with a CoA-NAK
 &= nbsp; containing a Service-Type Attribute with value "Authorize Only", and<= BR>   an Error-Cause Attribute with value 507 (Request Initiated)= .  The NAS
   then MUST send an Access-Request to the RAD= IUS server including a
   Service-Type Attribute with value "A= uthorize Only".  This Access-
   Request SHOULD contain t= he NAS identification attributes from the
   CoA-Request, as w= ell as the session identification attributes from
   the CoA-R= equest legal for inclusion in an Access-Request as specified
  = ; in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].  As noted in
&n= bsp;  [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD= be
   included in an Access-Request that does not contain a U= ser-Password,
   CHAP-Password, ARAP-Password or EAP-Message A= ttribute.  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.=

3.3.  State

   The State Attribute is availab= le to be sent by the RADIUS server to
   the NAS in a CoA-Requ= est packet and MUST be sent unmodified from the
   NAS to the = RADIUS server in a subsequent ACK or NAK packet.

   [RFC28= 65] Section 5.44 states:

      An Access-Re= quest MUST contain either a User-Password or a CHAP-
   &= nbsp;  Password or State.  An Access-Request MUST NOT contain bot= h a
      User-Password and a CHAP-Password.&nb= sp; If future extensions allow
      other kind= s of authentication information to be conveyed, the
   &n= bsp;  attribute for that can be used in an Access-Request instead of      User-Password or CHAP-Password.

&nb= sp;  In order to satisfy the requirements of [RFC2865] Section 5.44, a= n
   Access-Request with Service-Type=3D"Authorize-Only" MUST = contain a
   State attribute.

   In order to = provide a State attribute to the NAS, a server sending a
   Co= A-Request with a Service-Type value of "Authorize-Only" MUST
  = ; include a State Attribute, and the NAS MUST send the State Attribute
&= nbsp;  unmodified 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 include an Error-C= ause attribute with value 402 (Missing
   Attribute).

&= nbsp;  The State Attribute is also available to be sent by the RADIUS = server
   to the NAS in a CoA-Request that also includes a Ter= mination-Action
   Attribute with the value of RADIUS-Request.=   If the client performs
   the Termination-Action by sen= ding a new Access-Request upon
   termination of the current s= ession, it MUST include the State
   Attribute unchanged in th= at Access-Request.  In either usage, the
   client MUST N= OT interpret the Attribute locally.  A CoA-Request
   pac= ket must have only zero or one State Attribute.  Usage of the
 = ;  State Attribute is implementation dependent.
 
3.6.  Table of Attributes

   The following table prov= ides a guide to which attributes may be found
   in which pack= ets, and in what quantity.

   Change-of-Authorization Mess= ages

   Request   ACK    &nb= sp; NAK   #   Attribute
   0-1  =      0        0 = ;    1   User-Name [Note 1]
   0-1&nb= sp;      0      &nbs= p; 0     4   NAS-IP-Address [Note 1]
 = ;  0-1       0    &n= bsp;   0     5   NAS-Port [Note 1]<= BR>   0-1       0   =      0-1   6   Service-Type
&nbs= p;  0-1       0    &= nbsp;   0     7   Framed-Protocol [= Note 3]
   0-1       0 &nbs= p;      0     8   Fr= amed-IP-Address [Note 6]
   0-1     &= nbsp; 0        0    = 9   Framed-IP-Netmask [Note 6]
   0-1  &n= bsp;    0        0 &= nbsp;  10   Framed-Routing [Note 3]
   0+ =        0      &= nbsp; 0    11   Filter-ID [Note 3]
  = 0-1       0     &nb= sp;  0    12   Framed-MTU [Note 3]
 &= nbsp; 0+        0    = ;    0    13   Framed-Compression [= Note 3]
   0+        0 = ;       0    14   Lo= gin-IP-Host [Note 3]
   0-1      = ; 0        0    15 &= nbsp; Login-Service [Note 3]
   0-1    &nb= sp;  0        0    1= 6   Login-TCP-Port [Note 3]
   0+   &= nbsp;    0        0 =    18   Reply-Message [Note 2]
   0-1 = ;      0       = 0    19   Callback-Number [Note 3]
  = ; 0-1       0     &n= bsp;  0    20   Callback-Id [Note 3]
 = ;  0+        0   &nb= sp;    0    22   Framed-Route [Note= 3]
   0-1       0  &n= bsp;     0    23   Framed-IPX-= Network [Note 6]
   0-1       0-= 1      0-1  24   State
 &nb= sp; 0+        0    &= nbsp;   0    25   Class [Note 3]
&nbs= p;  0+        0   &n= bsp;    0    26   Vendor-Specific [= Note 3]
   0-1       0 &nbs= p;      0    27   Session= -Timeout [Note 3]
   0-1       0=         0    28 &nbs= p; Idle-Timeout [Note 3]
   0-1     &= nbsp; 0        0    29&nb= sp;  Termination-Action [Note 3]
   0-1   =     0        0  = ;  30   Called-Station-Id [Note 1]
   0-1 =       0        = 0    31   Calling-Station-Id [Note 1]
 &nb= sp; 0-1       0     =    0    32   NAS-Identifier [Note 1]
=    Request   ACK      NAK = ;  #   Attribute

   Request   ACK=       NAK   #   Attribute
&= nbsp;  0+        0+  &nbs= p;    0+   33   Proxy-State
 &nb= sp; 0-1       0     =    0    34   Login-LAT-Service [Note 3]<= BR>   0-1       0   =      0    35   Login-LAT-Node = [Note 3]
   0-1       0 &nb= sp;      0    36   Login-= LAT-Group [Note 3]
   0-1       = 0        0    37 &nb= sp; Framed-AppleTalk-Link [Note 3]
   0+   &nbs= p;    0        0 &nb= sp;  38   Framed-AppleTalk-Network [Note 3]
   = 0-1       0     &nbs= p;  0    39   Framed-AppleTalk-Zone [Note 3]<= BR>   0-1       0   =      0    44   Acct-Session-Id= [Note 1]
   0-1       0 &n= bsp;      0    50   Acct-= Multi-Session-Id [Note 1]
   0-1     =   0-1      0-1  55   Event-Tim= estamp
   0+        0 =        0    56   Egr= ess-VLANID [Note 3]
   0-1      = 0        0    57 &n= bsp; Ingress-Filters [Note 3]
   0+    &nb= sp;   0        0  &n= bsp; 58   Egress-VLAN-Name [Note 3]
   0-1 &nbs= p;     0        0&nb= sp;   59   User-Priority-Table [Note 3]
  = 0-1       0     &nb= sp;  0    61   NAS-Port-Type [Note 3]
&nbs= p;  0-1       0    &= nbsp;   0    62   Port-Limit [Note 3]   0-1       0   &n= bsp;    0    63   Login-LAT-Port [N= ote 3]
   0+        0 =        0    64   Tun= nel-Type [Note 5]
   0+      &nb= sp; 0        0    65 = ;  Tunnel-Medium-Type [Note 5]
   0+   &nb= sp;    0        0 &n= bsp;  66   Tunnel-Client-Endpoint [Note 5]
   0= +        0     =    0    67   Tunnel-Server-Endpoint [Not= e 5]
   0+        0 &n= bsp;      0    69   Tunne= l-Password [Note 5]
   0-1      = 0        0    71 &n= bsp; ARAP-Features [Note 3]
   0-1    &nbs= p;  0        0    72=    ARAP-Zone-Access [Note 3]
   0+   =      0        0 = ;   78   Configuration-Token [Note 3]
   0= +        0-1    &nbs= p; 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]
&nb= sp;  0+        0   &= nbsp;    0    82   Tunnel-Assignmen= t-ID [Note 5]
   0+        = 0        0    83 &nb= sp; Tunnel-Preference [Note 5]
   0-1    &= nbsp;  0        0   = 85   Acct-Interim-Interval [Note 3]
   0-1 &nb= sp;     0        0&n= bsp;   87   NAS-Port-Id [Note 1]
   0-1&nb= sp;      0      &nbs= p; 0    88   Framed-Pool [Note 6]
   = 0-1       0     &nbs= p;  0    89   Chargeable-User-Identity [Note = 1]
   0+        0 &nbs= p;      0    90   Tunnel-= Client-Auth-ID [Note 5]
   0+     &nb= sp;  0        0    9= 1   Tunnel-Server-Auth-ID [Note 5]
   0-1  = ;     0        0&nbs= p;   92   NAS-Filter-Rule [Note 3]
   0&nb= sp;        0    &nbs= p;   0    94   Originating-Line-Info
=    0-1       0   &nb= sp;    0    95   NAS-IPv6-Address [= Note 1]
   0-1       0 &nbs= p;      0    96   Framed-= Interface-Id [Note 6]
   0+      = ;  0        0    97&= nbsp;  Framed-IPv6-Prefix [Note 6]
   0+   = ;     0        0&nbs= p;   98   Login-IPv6-Host [Note 3]
   0+&n= bsp;       0     &nb= sp;  0    99   Framed-IPv6-Route [Note 3]
=    0-1       0   &nb= sp;    0   100   Framed-IPv6-Pool [Note = 6]
   0         0 = ;       0+  101   Error-Cause<= BR>   0+        0  &= nbsp;     0   123   Delegated-IPv6-= Prefix [Note 6]
   Request   ACK   &n= bsp;  NAK   #   Attribute

   Disc= onnect Messages

   Request   ACK  &nbs= p;   NAK   #   Attribute
   0-1&= nbsp;      0      &n= bsp; 0     1   User-Name [Note 1]
 &n= bsp; 0-1       0     = ;   0     4   NAS-IP-Address [Note = 1]
   0-1       0  &nb= sp;     0     5   NAS-Por= t [Note 1]
   0        = ; 0        0     6&n= bsp;  Service-Type
   0     &nbs= p;   0        0  &nb= sp;  8   Framed-IP-Address [Note 6]
   0+ =        0      &= nbsp; 0    18   Reply-Message [Note 2]
 &n= bsp; 0         0   &= nbsp;    0    24   State
 &= nbsp; 0+        0    = ;    0    25   Class [Note 4]
&n= bsp;  0+        0   =      0    26   Vendor-Specific=
   0-1       0   = ;     0    30   Called-Station= -Id [Note 1]
   0-1       0 = ;       0    31   Ca= lling-Station-Id [Note 1]
   0-1     =   0        0    32&n= bsp;  NAS-Identifier [Note 1]
   0+   &nbs= p;    0+       0+   = 33   Proxy-State
   0-1     = ;  0        0    44&= nbsp;  Acct-Session-Id [Note 1]
   0-1   &= nbsp;   0-1      0    49&= nbsp;  Acct-Terminate-Cause
   0-1    = ;   0        0  &nbs= p; 50   Acct-Multi-Session-Id [Note 1]
   0-1 &= nbsp;     0-1      0-1  5= 5   Event-Timestamp
   0    &nbs= p;    0        0 &nb= sp;  61   NAS-Port-Type
   0+   =      0-1      0  &nb= sp; 79   EAP-Message [Note 2]
   0-1  &nbs= p;    0-1      0-1  80 &n= bsp; Message-Authenticator
   0-1     = ;  0        0    87&= nbsp;  NAS-Port-Id [Note 1]
   0-1    = ;   0        0  &nbs= p; 89   Chargeable-User-Identity [Note 1]
   0-1&nbs= p;      0       = ; 0    95   NAS-IPv6-Address [Note 1]
 &nb= sp; 0         0   &n= bsp;    0    96   Framed-Interface-= Id [Note 6]
   0       &nbs= p; 0        0    97 =   Framed-IPv6-Prefix [Note 6]
   0    = ;     0        0&nbs= p;  100   Framed-IPv6-Pool [Note 6]
   0 &= nbsp;       0     &n= bsp;  0+  101   Error-Cause
   Request&nbs= p;  ACK      NAK   #   At= tribute

   The following table defines the meaning of the = above table entries.

0     This attribute MUST N= OT be present in packet.
0+    Zero or more instances of = this attribute MAY be present in packet.
0-1   Zero or one ins= tance of this attribute MAY be present in packet.
1   &nb= sp; 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 att= ributes MUST NOT be used for
   purposes other than identifica= tion (e.g. within CoA-Request packets
   to request authorizat= ion changes).

   [Note 2] The Reply-Message Attribute is u= sed to present a displayable
   message to the user.  The= message is only displayed as a result of a
   successful Disc= onnect-Request or CoA-Request (where a Disconnect-ACK
   or Co= A-ACK is subsequently sent).  Where EAP is used for
   au= thentication, an EAP-Message/Notification-Request Attribute is sent
&nbs= p;  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
&nb= sp;  attributes is omitted from a CoA-Request, the NAS assumes that th= e
   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 su= bsequently sent), the Class Attribute SHOULD be
   sent unmodi= fied by the client to the accounting server in the
   Accounti= ng Stop packet.  If the Disconnect-Request is unsuccessful,
 &= nbsp; then the Class Attribute is not processed.

   [Note = 5] When included within a CoA-Request, these attributes
   rep= resent an authorization change request.  Where tunnel attribute(s)
=    are included within a successful CoA-Request, all existing tun= nel
   attributes are removed and replaced by the new attribut= e(s).

   [Note 6] Where included within a CoA-Request, the= se attributes
   represent a renumbering request.  Since = these attributes are not used
   for session identification, t= hey MUST NOT be included within a
   Disconnect-Request. = Note that renumbering may not be possible in all
   situation= s.  For example, in order to change an IP address on receipt
 =   of a changed  Framed-IP-Address address, IPCP re-negotiation co= uld be
   required, which is not supported by all PPP implemen= tations.
 
Appendix A - Changes from RFC 3576

   This Appendix lists = the major changes between [RFC3576] and this
   document. = ; Minor changes, including style, grammar, spelling, and
   ed= itorial changes are not mentioned here.

   o Added require= ment for duplicate detection on the RADIUS client
   (Section = 2.3).

   o Added Chargeable-User-Identity as a session ide= ntification
   attribute.  Removed Framed-IP-Address, Fra= med-IPv6-Prefix, Framed-
   Interface-Id and NAS-Port-Type att= ributes as session identification
   attributes (Section 3).
   o Added details relating to handling of the Proxy-State = Attribute
   (Section 3.1).

   o Added statem= ent that support for "Authorize Only" Service-Type is
   optio= nal (Section 3.2).

   o Added requirements for inclusion o= f the State Attribute in CoA-
   Request packets with a Servic= e-Type of "Authorize Only" (Section
   3.3).

 &nbs= p; o Added clarification on the calculation of the Message-Authenticator   Attribute (Section 3.4).

   o An additional = Error-Cause Attribute value (407) is allocated for
   Invalid = Attribute Value (Sections 3.5, 4).

   o Updated CoA-Reques= t Attribute Table to include Filter-Rule,
   Delegated-IPv6-Pr= efix, Egress-VLANID, Ingress-Filters, Egress-VLAN-
   Name and= User-Priority attributes (Section 3.6).

   o Added the Ch= argeable-User-Identity Attribute to both the CoA-
   Request a= nd Disconnect-Request Attribute table (Section 3.6).

   o = Added note on the use of the CoA-Request for 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 Diameter Considerations (Section 4).

 =   o Changed the text to indicate that the Event-Timestamp Attribute   should not be recalculated on retransmission.  The impli= cations for
   replay and duplicate detection are discussed (S= ection 6.4).


= --_620ce6a7-56f2-442e-8219-cf050028ab68_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 23 May 2007 19:51:13 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-05.txt Message-Id: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-23143933.I-D@ietf.org> 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: <2007-5-23143933.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 22:00:53 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_8078362c-927b-4f13-8362-7639f3c405d6_" From: Bernard Aboba To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 22 May 2007 15:00:29 -0700 MIME-Version: 1.0 --_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 Here is the proposed new text of Sectio= ns 3, 3.1, 3.2 and 3.5 as well as Appendix A:
 
"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-Re= quest or CoA-Request to be
   successful; otherwise a Disconne= ct-NAK or CoA-NAK SHOULD be sent.
   For session identificatio= n 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
   identificat= ion attributes SHOULD match.  Where a mismatch of session
 &nb= sp; identification attributes is detected, a Disconnect-NAK or CoA-NAK
&= nbsp;  SHOULD  be sent.

   The ability to use NA= S or session identification attributes to map to
   unique/mul= tiple sessions is beyond the scope of this document.
   Identi= fication attributes include NAS and session identification
   = attributes, as described below.

     NAS identif= ication attributes

     Attribute  &nb= sp;          #  &nbs= p; Reference  Description
     --------- &= nbsp;          ---  = ---------  -----------
     NAS-IP-Address&nbs= p;       4    [RFC2865]  = The IPv4 address of the NAS.
     NAS-Identifier&nbs= p;      32    [RFC2865]  Strin= g identifying the NAS.
     NAS-IPv6-Address &n= bsp;   95    [RFC3162]  The IPv6 address of t= he NAS.

     Session identification attributes
     Attribute      = ;        #   Reference  D= escription
     ---------    &nb= sp;        ---  ---------  ---= --------
     User-Name     = ;         1   [RFC2865]&n= bsp; The name of the user
       &nbs= p;            &= nbsp;           &nbs= p;          associated with th= e session.
     NAS-Port    &nbs= p;          5   [RFC= 2865]  The port on which the
      &n= bsp;            = ;            &n= bsp;           session is= terminated.

     Attribute   &nb= sp;          #   Ref= erence  Description
     ---------  &= nbsp;          ---  -----= ----  -----------
     Called-Station-Id &= nbsp;   30   [RFC2865]  The link address to which<= BR>            =             &nb= sp;            =       the session is connected.
  &nb= sp;  Calling-Station-Id    31   [RFC2865]&nbs= p; The link address from which
       = ;            &n= bsp;            = ;           the session i= s connected.
     Acct-Session-Id   &= nbsp;   44   [RFC2866]  The identifier uniquely            &n= bsp;            = ;            &n= bsp;     identifying the session
   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  on the NAS.
     Acct-Multi-Session-Id 50&n= bsp;  [RFC2866]  The identifier uniquely
   &nb= sp;            =             &nb= sp;            =   identifying related sessions.
     NAS-Port-I= d           87  = ; [RFC2869]  String identifying the port
    &n= bsp;            = ;            &n= bsp;            = ; where the session is.
     Chargeable-User- &= nbsp;    89   [RFC4372]  The CUI associated w= ith the
     Identity     &= nbsp;           &nbs= p;            sessio= n.  Needed where a
        =             &nb= sp;            =           privacy NAI is used,= because
          &nb= sp;            =             &nb= sp;       the User-Name may not be
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    unique (e.g. "anonymous").

   To addr= ess security concerns described in Section 6.1, either the
   = User-Name or Chargeable-User-Identity attribute SHOULD be present in
&nb= sp;  Disconnect-Request and CoA-Request packets.

   W= here a Diameter client utilizes the same Session-Id for both
  = ; authorization and accounting, inclusion of an Acct-Session-Id
 &n= bsp; Attribute in a Disconnect-Request or CoA-Request can assist with
&n= bsp;  Diameter/RADIUS translation, since Diameter RAR and ASR commands=
   include a Session-Id AVP.  An Acct-Session-Id attribu= te SHOULD be
   included in Disconnect-Request and CoA-Request= packets.

   Where the Acct-Session-Id or Acct-Multi-Sessi= on-Id attributes are not
   present in a CoA-Request or Discon= nect-Request, it is possible that
   the User-Name or Chargeab= le-User-Identity attributes will not be
   sufficient to uniqu= ely identify the session (e.g. if the same user
   has multipl= e sessions on the NAS, or the privacy NAI is used).  As a
 &nb= sp; result, the Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-   Port-Id attributes MAY be used as additional session identifi= cation.

   To address security concerns described in Secti= on 6.2, one or more of
   the NAS-IP-Address or NAS-IPv6-Addre= ss Attributes SHOULD be present
   in Disconnect-Request and C= oA-Request packets; the NAS-Identifier
   Attribute MAY be pre= sent.

   If one or more authorization changes specified in= a CoA-Request
   cannot be carried out, or if one or more att= ributes or attribute-
   values is unsupported, a CoA-NAK MUST= be sent.  Similarly, if there
   are one or more unsuppo= rted 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
   Di= sconnect-Request, implementations MUST send a Disconnect-NAK; an
 &= nbsp; Error-Cause Attribute with value "Unsupported Attribute" MAY be
&n= bsp;  included.

3.1.  Authorize Only

   S= upport for a CoA-Request including a Service-Type Attribute with
 &= nbsp; value "Authorize Only" is OPTIONAL on the NAS and RADIUS server. = ; A
   Service-Type Attribute MUST NOT be included within a Di= sconnect-
   Request.

   A NAS MUST respond t= o a CoA-Request including a Service-Type
   Attribute with val= ue "Authorize Only" with a CoA-NAK; a CoA-ACK MUST
   NOT be s= ent.  If the NAS does not support a Service-Type value of
 &nb= sp; "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<= BR>   "Authorize Only" MUST in addition contain only NAS or sessi= on
   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 v= alue 401 (Unsupported Attribute)
   SHOULD be included.
   If a CoA-Request packet including a Service-Type value of "Au= thorize
   Only" is successfully processed, the NAS MUST respo= nd with a CoA-NAK
   containing a Service-Type Attribute with = value "Authorize Only", and
   an Error-Cause Attribute with v= alue 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-
 &nb= sp; Request SHOULD contain the NAS identification attributes from the
&n= bsp;  CoA-Request, as well as the session identification attributes fr= om
   the CoA-Request legal for inclusion in an Access-Request= as specified
   in [RFC2865], [RFC2868], [RFC2869] and [RFC31= 62].  As noted in
   [RFC2869] Section 5.19, a Message-Au= thenticator attribute SHOULD be
   included in an Access-Reque= st that does not contain a User-Password,
   CHAP-Password, AR= AP-Password or EAP-Message Attribute.  The RADIUS
   serv= er then will respond to the Access-Request with an Access-Accept
 &= nbsp; to (re-)authorize the session or an Access-Reject to refuse to
&nb= sp;  (re-)authorize it.

3.2.  State

   Th= e 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:

   &= nbsp;  An Access-Request MUST contain either a User-Password or a CHAP= -
      Password or State.  An Access-Requ= est 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 Acc= ess-Request instead of
      User-Password or C= HAP-Password.

   In order to satisfy the requirements of [= RFC2865] Section 5.44, an
   Access-Request with Service-Type= =3D"Authorize-Only" MUST contain a
   State attribute.

=    In order to provide a State attribute to the NAS, a server sen= ding a
   CoA-Request with a Service-Type value of "Authorize-= Only" MUST
   include a State Attribute, 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-Request containing a Service-Type value
   of "Authorize-O= nly" but lacking a State attribute MUST send a CoA-NAK
   and = SHOULD include an Error-Cause attribute with value 402 (Missing
 &n= bsp; Attribute).

   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
   ter= mination of the current session, it MUST include the State
   = Attribute unchanged in that Access-Request.  In either usage, the
&= nbsp;  client MUST NOT interpret the Attribute locally.  A CoA-Re= quest
   packet must have only zero or one State Attribute.&nb= sp; Usage of the
   State Attribute is implementation dependen= t.
3.5.  Table of Attributes

&= nbsp;  The following table provides a guide to which attributes may be= found
   in which packets, and in what quantity.

 = ;  Change-of-Authorization Messages

   Request &= nbsp; ACK      NAK   #   Attri= bute
   0-1       0  &= nbsp;     0     1   User-= Name [Note 1]
   0-1       0&nbs= p;       0     4 &nb= sp; NAS-IP-Address [Note 1]
   0-1    &nbs= p;  0        0   &nb= sp; 5   NAS-Port [Note 1]
   0-1   &n= bsp;   0        0-1  = ; 6   Service-Type
   0-1    &nb= sp;  0        0   &n= bsp; 7   Framed-Protocol [Note 3]
   0-1  =      0        0 = ;    8   Framed-IP-Address [Note 6]
  = ; 0-1       0     &n= bsp;  0     9   Framed-IP-Netmask [Note = 6]
   0-1       0  &nb= sp;     0    10   Framed-Routi= ng [Note 3]
   0+        0&= nbsp;       0    11  = ; Filter-ID [Note 3]
   0-1      = ; 0        0    12 &= nbsp; Framed-MTU [Note 3]
   0+     &= nbsp;  0        0   = 13   Framed-Compression [Note 3]
   0+  &= nbsp;     0        0=     14   Login-IP-Host [Note 3]
   0-= 1       0      =   0    15   Login-Service [Note 3]
 &= nbsp; 0-1       0    &nbs= p;   0    16   Login-TCP-Port [Note 3]   0+        0  &n= bsp;     0    18   Reply-Messa= ge [Note 2]
   0-1       0 =        0    19   Cal= lback-Number [Note 3]
   0-1     &nbs= p; 0        0    20 =   Callback-Id [Note 3]
   0+     = ;   0        0  &nbs= p; 22   Framed-Route [Note 3]
   0-1  &nbs= p;    0        0 &nb= sp;  23   Framed-IPX-Network [Note 6]
   0-1&nb= sp;      0-1      0-1&nbs= p; 24   State
   0+     &nb= sp;  0        0    2= 5   Class [Note 3]
   0+    &nbs= p;   0        0  &nb= sp; 26   Vendor-Specific [Note 3]
   0-1  =      0        0 = ;   27   Session-Timeout [Note 3]
   0-1&n= bsp;      0      &nb= sp; 0    28   Idle-Timeout [Note 3]
  = ; 0-1       0     &n= bsp;  0    29   Termination-Action [Note 3]   0-1       0   &= nbsp;    0    30   Called-Station-I= d [Note 1]
   0-1       0 &= nbsp;      0    31   Call= ing-Station-Id [Note 1]
   0-1     &n= bsp; 0        0    32&nbs= p;  NAS-Identifier [Note 1]
   Request   ACK&nb= sp;     NAK   #   Attribute

=
   Request   ACK      NAK&= nbsp;  #   Attribute
   0+   &nb= sp;    0+       0+  = 33   Proxy-State
   0-1    &nbs= p;  0        0    34=    Login-LAT-Service [Note 3]
   0-1  &nbs= p;    0        0 &nb= sp;  35   Login-LAT-Node [Note 3]
   0-1 &= nbsp;     0        0=     36   Login-LAT-Group [Note 3]
   = 0-1       0     &nbs= p;  0    37   Framed-AppleTalk-Link [Note 3]<= BR>   0+        0  &= nbsp;     0    38   Framed-App= leTalk-Network [Note 3]
   0-1     &n= bsp; 0        0    39&nbs= p;  Framed-AppleTalk-Zone [Note 3]
   0-1  &nbs= p;    0        0 &nb= sp;  44   Acct-Session-Id [Note 1]
   0-1 =       0        = 0    50   Acct-Multi-Session-Id [Note 1]
 =   0-1       0-1    &= nbsp; 0-1  55   Event-Timestamp
   0+ &nbs= p;      0       = ; 0    56   Egress-VLANID [Note 3]
  = 0-1       0     &nb= sp;  0    57   Ingress-Filters [Note 3]
&n= bsp;  0+        0   =      0    58   Egress-VLAN-Nam= e [Note 3]
   0-1       0 &= nbsp;      0    59   User= -Priority-Table [Note 3]
   0-1     &= nbsp; 0        0    61&nb= sp;  NAS-Port-Type [Note 3]
   0-1    = ;   0        0  &nbs= p; 62   Port-Limit [Note 3]
   0-1   =     0        0  = ;  63   Login-LAT-Port [Note 3]
   0+ &nbs= p;      0       = ; 0    64   Tunnel-Type [Note 5]
   0= +        0     =    0    65   Tunnel-Medium-Type [Note 5]=
   0+        0  =       0    66   Tunnel-Cl= ient-Endpoint [Note 5]
   0+     &nbs= p;  0        0    67=    Tunnel-Server-Endpoint [Note 5]
   0+  =       0        = 0    69   Tunnel-Password [Note 5]
  = 0-1       0     &nb= sp;  0    71   ARAP-Features [Note 3]
&nbs= p;  0-1       0    &= nbsp;   0    72   ARAP-Zone-Access [Note= 3]
   0+        0 &nb= sp;      0    78   Config= uration-Token [Note 3]
   0+     &nbs= p;  0-1      0    79 &nbs= p; EAP-Message [Note 2]
   0-1     &n= bsp; 0-1      0-1  80   Message-Aut= henticator
   0+        0&n= bsp;       0    81  = Tunnel-Private-Group-ID [Note 5]
   0+    = ;    0        0 &nbs= p;  82   Tunnel-Assignment-ID [Note 5]
   0+&nb= sp;       0     &nbs= p;  0    83   Tunnel-Preference [Note 5]
&= nbsp;  0-1       0   &nbs= p;    0    85   Acct-Interim-Interv= al [Note 3]
   0-1       0 =        0    87   NAS= -Port-Id [Note 1]
   0-1       0=         0    88 &nbs= p; Framed-Pool [Note 6]
   0-1     &n= bsp; 0        0    89&nbs= p;  Chargeable-User-Identity [Note 1]
   0+  &n= bsp;     0        0&= nbsp;   90   Tunnel-Client-Auth-ID [Note 5]
 &n= bsp; 0+        0    =     0    91   Tunnel-Server-Auth-ID= [Note 5]
   0-1       0 &n= bsp;      0    92   NAS-F= ilter-Rule [Note 3]
   0      &n= bsp;  0        0    = 94   Originating-Line-Info
   0-1   &= nbsp;   0        0  =   95   NAS-IPv6-Address [Note 1]
   0-1 &n= bsp;     0        0&= nbsp;   96   Framed-Interface-Id [Note 6]
 &nbs= p; 0+        0    &n= bsp;   0    97   Framed-IPv6-Prefix [Not= e 6]
   0+        0 &n= bsp;      0    98   Login= -IPv6-Host [Note 3]
   0+      &= nbsp; 0        0    99&nb= sp;  Framed-IPv6-Route [Note 3]
   0-1   &= nbsp;   0        0  = 100   Framed-IPv6-Pool [Note 6]
   0  &nb= sp;      0      &nbs= p; 0+  101   Error-Cause
   0+   = ;     0        0&nbs= p;  123   Delegated-IPv6-Prefix [Note 6]
   Req= uest   ACK      NAK   # &= nbsp; Attribute

   Disconnect Messages

  = Request   ACK      NAK   #&nb= sp;  Attribute
   0-1      = 0        0     1&nb= sp;  User-Name [Note 1]
   0-1    &nb= sp;  0        0   &n= bsp; 4   NAS-IP-Address [Note 1]
   0-1  &= nbsp;    0        0 =     5   NAS-Port [Note 1]
   0 &= nbsp;       0     &n= bsp;  0     6   Service-Type
 &n= bsp; 0         0   &= nbsp;    0     8   Framed-IP-A= ddress [Note 6]
   0+       = ; 0        0    18 &= nbsp; Reply-Message [Note 2]
   0     = ;    0        0 &nbs= p;  24   State
   0+    &nb= sp;   0        0  &n= bsp; 25   Class [Note 4]
   0+   &nbs= p;    0        0 &nb= sp;  26   Vendor-Specific
   0-1  &nb= sp;    0        0 &n= bsp;  30   Called-Station-Id [Note 1]
   0-1&nb= sp;      0      &nbs= p; 0    31   Calling-Station-Id [Note 1]
 =   0-1       0    &nb= sp;   0    32   NAS-Identifier [Note 1]<= BR>   0+        0+  =      0+   33   Proxy-State
 = ;  0-1       0    &n= bsp;   0    44   Acct-Session-Id [Note 1= ]
   0-1       0-1  &n= bsp;   0    49   Acct-Terminate-Cause   0-1       0   &n= bsp;    0    50   Acct-Multi-Sessio= n-Id [Note 1]
   0-1       0-1&n= bsp;     0-1  55   Event-Timestamp
&n= bsp;  0         0  &= nbsp;     0    61   NAS-Port-T= ype
   0+        0-1 &= nbsp;    0    79   EAP-Message [Not= e 2]
   0-1       0-1  = ;    0-1  80   Message-Authenticator
 = ;  0-1       0    &n= bsp;   0    87   NAS-Port-Id [Note 1]   0-1       0   &n= bsp;    0    89   Chargeable-User-I= dentity [Note 1]
   0-1       0&= nbsp;       0    95  = ; NAS-IPv6-Address [Note 1]
   0     =     0        0  = ;  96   Framed-Interface-Id [Note 6]
   0 =         0     &= nbsp;  0    97   Framed-IPv6-Prefix [Note 6]<= BR>   0         0 &n= bsp;      0   100   Framed-IPv= 6-Pool [Note 6]
   0       =   0        0+  101  = Error-Cause
   Request   ACK    = ;  NAK   #   Attribute

   The fol= lowing 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 pa= cket.
0-1   Zero or one instance of this attribute MAY be pres= ent in packet.
1     Exactly one instance of this at= tribute MUST be present in packet.

   [Note 1] Where NAS o= r session identification attributes are included
   in Disconn= ect-Request or CoA-Request packets, they are used for
   ident= ification purposes only.  These attributes MUST NOT be used for
&nb= sp;  purposes other than identification (e.g. within CoA-Request packe= ts
   to request authorization changes).

   [= Note 2] The Reply-Message Attribute is used to present a displayable
&nb= sp;  message to the user.  The message is only displayed as a res= ult of a
   successful Disconnect-Request or CoA-Request (wher= e a Disconnect-ACK
   or CoA-ACK is subsequently sent).  = Where EAP is used for
   authentication, an EAP-Message/Notifi= cation-Request Attribute is sent
   instead, and Disconnect-AC= K or CoA-ACK packets contain an EAP-
   Message/Notification-R= esponse Attribute.

   [Note 3] When included within a CoA-= Request, these attributes
   represent an authorization change= request.  When one of these
   attributes is omitted fro= m a CoA-Request, the NAS assumes that the
   attribute value i= s to remain unchanged.  Attributes included in a
   CoA-R= equest replace all existing value(s) of the same attribute(s).

 = ;  [Note 4] When included within a successful Disconnect-Request (wher= e
   a Disconnect-ACK is subsequently sent), the Class Attribu= te SHOULD be
   sent unmodified by the client to the accountin= g server in the
   Accounting Stop packet.  If the Discon= nect-Request is unsuccessful,
   then the Class Attribute is n= ot processed.

   [Note 5] When included within a CoA-Reque= st, these attributes
   represent an authorization change requ= est.  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] = Where included within a CoA-Request, these attributes
   repre= sent a renumbering request.  Since these attributes are not used
&n= bsp;  for session identification, they MUST NOT be included within a   Disconnect-Request.  Note that renumbering may not be p= ossible in all
   situations.  For example, in order to c= hange an IP address on receipt
   of a changed  Framed-IP= -Address address, IPCP re-negotiation could be
   required, wh= ich is not supported by all PPP implementations.
 
Appendix A - Changes from RFC 3576
 
=     This Appendix lists the major changes between [RFC3576] = and this
    document.  Minor changes, including sty= le, grammar, spelling, and
    editorial changes are not = mentioned here.
 
    o Added details relating to= handling of the Proxy-State Attribute.
    Added require= ment for duplicate detection on the RADIUS client
    (Se= ction 2.3).
 
    o Added Chargeable-User-Identit= y as a session identification
    attribute.  Remove= d Framed-IP-Address, Framed-IPv6-Prefix, Framed-
    Inte= rface-Id and NAS-Port-Type attributes as session identification
 &n= bsp;  attributes (Section 3).
 
    o Added = requirements for inclusion of the State Attribute in CoA-
  &n= bsp; Request packets with a Service-Type of "Authorize Only" (Section
&n= bsp;   3.2).
 
    o Added clarificatio= n on the calculation of the Message-Authenticator
    Att= ribute (Section 3.3).
 
    o Added statement tha= t support for "Authorize Only" Service-Type is
    option= al (Section 3.5).
 
    o Updated CoA-Request Att= ribute Table to include Filter-Rule,
    Delegated-IPv6-P= refix, Egress-VLANID, Ingress-Filters, Egress-VLAN-
    N= ame and User-Priority attributes (Section 3.5).
 
  &n= bsp; o Added the Chargeable-User-Identity Attribute to both the CoA-
&nb= sp;   Request and Disconnect-Request Attribute table (Section 3.5= ).
 
    o Added note on the use of the CoA-Reque= st for renumbering (Section
    3.5).
 
 =    o Use of Service-Type and Error-Cause attributes within a Disc= onnect-
    Request is prohibited (Sections 3.5).
&nbs= p;
    o Added Diameter Considerations (Section 4).
&n= bsp;
    o Changed the text to indicate that the Event-Ti= mestamp Attribute
    should not be recalculated on retra= nsmission.  The implications for
    replay and dupl= icate detection are discussed (Section 6.4)."
= --_8078362c-927b-4f13-8362-7639f3c405d6_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 21:37:09 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_7900dde4-cd6f-47aa-a163-f31f7d523d97_" From: Bernard Aboba To: "David B. Nelson" , Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 22 May 2007 14:36:32 -0700 MIME-Version: 1.0 --_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 > I've never implemented RFC 3576, so please excuse me if I ask silly> questions. If the RADIUS Server / Dynamic Access Client receives a Co= A-NAK,
> in response to a CoA-Request, it means that Service-Type of = "Authorize-Only"
> is not supported by the RADIUS Client / Dynamic Ac= cess Server, whether not
> the Error-Cause attribute is present?
<= 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.   A CoA-ACK is never sent in response.
 
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= .  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.

> Are there other cases when Error-Cause is absent and it means some= thing
> else?
 
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/Disco= nnect-NAK always indicates a failure.
 
 
= --_7900dde4-cd6f-47aa-a163-f31f7d523d97_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 20:27:50 +0000 From: "David B. Nelson" To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 22 May 2007 16:25:38 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00b801c79caf$5c1924b0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AcecraXmXEnmCuLmQ96AmpOJadewbwAAJYrA 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 20:13:34 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_b57c3125-28d5-40eb-bcf0-70767f7b63bc_" From: Bernard Aboba To: "David B. Nelson" , Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 22 May 2007 13:13:12 -0700 MIME-Version: 1.0 --_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= ard_aboba@hotmail.comTo: dnelson@elbrysnetworks.com; radiusext@ops.ietf.org= 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 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,= inclusion of an Error-Cause Attribute is upgraded to a SHOULD in case of a= n error.  Here is the updated text:

3.1.  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-
   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
&= nbsp;  NOT be sent.  If the NAS does not support a Service-Type v= alue of
   "Authorize Only" then it MUST respond with a CoA-NA= K; an Error-Cause
   value of 405 (Unsupported Service) SHOULD= be included.

   A CoA-Request containing a Service-Type A= ttribute with value
   "Authorize Only" MUST in addition conta= in only NAS or session
   identification attributes, as well a= s a State Attribute.  If other
   attributes are included= in such a CoA-Request, a CoA-NAK MUST be
   sent; an Error-Ca= use Attribute with value 401 (Unsupported Attribute)
   SHOULD= be included.

   If a CoA-Request packet including a Servi= ce-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-Ca= use Attribute with value 507 (Request Initiated).  The NAS
 &n= bsp; then MUST send an Access-Request to the RADIUS server including a
&= nbsp;  Service-Type Attribute with value "Authorize Only".  This = Access-
   Request SHOULD contain the NAS identification attri= butes from the
   CoA-Request, as well as the session identifi= cation attributes from
   the CoA-Request legal for inclusion = in an Access-Request as specified
   in [RFC2865], [RFC2868], = [RFC2869] and [RFC3162].  As noted in
   [RFC2869] Sectio= n 5.19, a Message-Authenticator attribute SHOULD be
   include= d in an Access-Request that does not contain a User-Password,
 &nbs= p; CHAP-Password, ARAP-Password or EAP-Message Attribute.  The RADIUS<= br>   server then will respond to the Access-Request with an Acce= ss-Accept
   to (re-)authorize the session or an Access-Reject= to refuse to
   (re-)authorize it.

Fro= m: bernard_aboba@hotmail.com
To: dnelson@elbrysnetworks.com; radiusext@o= ps.ietf.org
Subject: RE: Issue 226: RFC 3576bis and Renumbering
Date= : Tue, 22 May 2007 12:43:24 -0700

> It strikes me that the large number and substantial nature of these no= tes
> suggests that they be incorporated elsewhere in the normative t= ext of the
> document, rather as footnotes to the Table of Attributes= . I think it would
> substantially enhance readability of the documen= t. 
 
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:
 
3.1.  Authorize Only

   Support for a CoA-Request inc= luding a Service-Type Attribute with
   value "Authorize Only"= is OPTIONAL on the NAS and RADIUS server.  A
   Service-= Type Attribute MUST NOT be included within a Disconnect-
   Re= quest.

   A NAS MUST respond to a CoA-Request including a = Service-Type
   Attribute with value "Authorize Only" with a C= oA-NAK; a CoA-ACK MUST
   NOT be sent.  If the NAS does n= ot 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 Attribute with value
   "Authorize O= nly" MUST in addition contain only NAS or session
   identific= ation attributes, as well as a State Attribute.  If other
 &nb= sp; attributes are included in such a CoA-Request, a CoA-NAK MUST be
&nb= sp;  sent; an Error-Cause Attribute with value 401 (Unsupported Attrib= ute)
   SHOULD be included.

   A NAS supporti= ng a Service-Type value of "Authorize Only" within a
   CoA-Re= quest packet MUST respond with a CoA-NAK containing a Service-
 &nb= sp; 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 including a Service-= Type
   Attribute with value "Authorize Only".  This Acce= ss-Request SHOULD
   contain the NAS identification attributes= from the CoA-Request, as
   well as the session identificatio= n attributes from the CoA-Request
   legal for inclusion in an= Access-Request as specified in [RFC2865],
   [RFC2868], [RFC2= 869] and [RFC3162].  As noted in [RFC2869] Section
   5.1= 9, a Message-Authenticator attribute SHOULD be included in an
 &nbs= p; Access-Request that does not contain a User-Password, CHAP-Password,
=    ARAP-Password or EAP-Message Attribute.  The RADIUS serve= r should
   send back an Access-Accept to (re-)authorize the s= ession or an
   Access-Reject to refuse to (re-)authorize it.<= br>
3.2.  State

   The State Attribute is availabl= e to be sent by the RADIUS server to
   the NAS in a CoA-Reque= st packet and MUST be sent unmodified from the
   NAS to the R= ADIUS server in a subsequent CoA-ACK or CoA-NAK packet.

  = [RFC2865] Section 5.44 states:

      An Ac= cess-Request MUST contain either a User-Password or a CHAP-
  =     Password or State.  An Access-Request MUST NOT cont= ain both a
      User-Password and a CHAP-Passw= ord.  If future extensions allow
      oth= er kinds of authentication information to be conveyed, the
  &= nbsp;   attribute for that can be used in an Access-Request inste= ad of
      User-Password or CHAP-Password.
=
   In order to satisfy the requirements of [RFC2865] Section = 5.44, an
   Access-Request with Service-Type=3D"Authorize-Only= " MUST contain a
   State attribute.

   In or= der to provide a State attribute to the NAS, a server sending a
 &n= bsp; CoA-Request with a Service-Type value of "Authorize-Only" MUST
&nbs= p;  include a State Attribute, and the NAS MUST send the State Attribu= te
   unmodified to the RADIUS server in the resulting Access-= Request, if
   any.  A NAS receiving a CoA-Request contai= ning a Service-Type value
   of "Authorize-Only" but lacking a= State attribute 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 include= s a Termination-Action
   Attribute with the value of RADIUS-R= equest.  If the client performs
   the Termination-Action= by sending a new Access-Request upon
   termination of the cu= rrent session, it MUST include the State
   Attribute unchange= d in that Access-Request.  In either usage, the
   client= MUST NOT interpret the Attribute locally.  A CoA-Request
 &nb= sp; packet must have only zero or one State Attribute.  Usage of the   State Attribute is implementation dependent.

= --_b57c3125-28d5-40eb-bcf0-70767f7b63bc_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 19:57:31 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_753c6a07-f3ba-4255-8dcd-514d3bffed85_" From: Bernard Aboba To: Subject: RE: Issue: Error-Cause Attribute in Disconnect-ACK? Date: Tue, 22 May 2007 12:57:11 -0700 MIME-Version: 1.0 --_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: bernard_aboba@hotmail.com> To: radiusext@ops.ietf.org> 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: aboba@internaut.com> 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 radiusext-request@ops.ietf.org with> the word= 'unsubscribe' in a single line as the message text body.> archive: = --_753c6a07-f3ba-4255-8dcd-514d3bffed85_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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-R= equest including a Service-Type Attribute with value "Authorize Only".=   If the CoA-Request can be processed, then sending an Error-Cause Att= ribute with value 507 (Request Initiated) is required.  However, if th= e CoA-Request cannot be processed, sending an Error-Cause attribute is opti= onal.  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?  
 


> From: bernard_aboba@hotmail.com
> To: radiusext@ops.ietf= .org
> Subject: Issue: Error-Cause Attribute in Disconnect-ACK?
&g= t; Date: Tue, 22 May 2007 10:31:40 -0700
>
>
> Issue: E= rror-Cause Attribute in Disconnect-ACK?
> Submitter name: Bernard Abo= ba
> Submitter email address: aboba@internaut.com
> Date first = submitted: May 22, 2007
> Reference:
> Document: RFC3576bis-05=
> Comment type: Technical
> Priority: S
> Section: 3.4> Rationale/Explanation of issue:
>
> In the process of e= diting the attribute table to address Issue 226, I noticed an oddity.
&= gt;
> RFC 3576 Section 3.1 states the following:
>
> It= is possible that the NAS cannot honor Disconnect-Request or
> CoA-Re= quest 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.
>
&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.
> --
> to unsubscribe= send a message to radiusext-request@ops.ietf.org with
> the word 'un= subscribe' in a single line as the message text body.
> archive: <= http://psg.com/lists/radiusext/>

= --_753c6a07-f3ba-4255-8dcd-514d3bffed85_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 19:44:01 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_37557d2c-6f82-4fe1-8c8a-ec622610f7b4_" From: Bernard Aboba To: "David B. Nelson" , Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 22 May 2007 12:43:24 -0700 MIME-Version: 1.0 --_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
> It strikes me that the large number and substantial nature of these no= tes
> suggests that they be incorporated elsewhere in the normative t= ext of the
> document, rather as footnotes to the Table of Attributes= . I think it would
> substantially enhance readability of the documen= t. 
 
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:
 
3.1.  Authorize Only

   Support for a CoA-Request inc= luding a Service-Type Attribute with
   value "Authorize Only"= is OPTIONAL on the NAS and RADIUS server.  A
   Service-= Type Attribute MUST NOT be included within a Disconnect-
   Re= quest.

   A NAS MUST respond to a CoA-Request including a = Service-Type
   Attribute with value "Authorize Only" with a C= oA-NAK; a CoA-ACK MUST
   NOT be sent.  If the NAS does n= ot 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 Attribute with value
   "Authorize O= nly" MUST in addition contain only NAS or session
   identific= ation attributes, as well as a State Attribute.  If other
 &nb= sp; attributes are included in such a CoA-Request, a CoA-NAK MUST be
&nb= sp;  sent; an Error-Cause Attribute with value 401 (Unsupported Attrib= ute)
   SHOULD be included.

   A NAS supporti= ng a Service-Type value of "Authorize Only" within a
   CoA-Re= quest packet MUST respond with a CoA-NAK containing a Service-
 &nb= sp; 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 including a Service-= Type
   Attribute with value "Authorize Only".  This Acce= ss-Request SHOULD
   contain the NAS identification attributes= from the CoA-Request, as
   well as the session identificatio= n attributes from the CoA-Request
   legal for inclusion in an= Access-Request as specified in [RFC2865],
   [RFC2868], [RFC2= 869] and [RFC3162].  As noted in [RFC2869] Section
   5.1= 9, a Message-Authenticator attribute SHOULD be included in an
 &nbs= p; Access-Request that does not contain a User-Password, CHAP-Password,
=    ARAP-Password or EAP-Message Attribute.  The RADIUS serve= r should
   send back an Access-Accept to (re-)authorize the s= ession or an
   Access-Reject to refuse to (re-)authorize it.<= BR>
3.2.  State

   The State Attribute is availabl= e to be sent by the RADIUS server to
   the NAS in a CoA-Reque= st packet and MUST be sent unmodified from the
   NAS to the R= ADIUS server in a subsequent CoA-ACK or CoA-NAK packet.

  = [RFC2865] Section 5.44 states:

      An Ac= cess-Request MUST contain either a User-Password or a CHAP-
  =     Password or State.  An Access-Request MUST NOT cont= ain both a
      User-Password and a CHAP-Passw= ord.  If future extensions allow
      oth= er kinds of authentication information to be conveyed, the
  &= nbsp;   attribute for that can be used in an Access-Request inste= ad of
      User-Password or CHAP-Password.
=
   In order to satisfy the requirements of [RFC2865] Section = 5.44, an
   Access-Request with Service-Type=3D"Authorize-Only= " MUST contain a
   State attribute.

   In or= der to provide a State attribute to the NAS, a server sending a
 &n= bsp; CoA-Request with a Service-Type value of "Authorize-Only" MUST
&nbs= p;  include a State Attribute, and the NAS MUST send the State Attribu= te
   unmodified to the RADIUS server in the resulting Access-= Request, if
   any.  A NAS receiving a CoA-Request contai= ning a Service-Type value
   of "Authorize-Only" but lacking a= State attribute 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 include= s a Termination-Action
   Attribute with the value of RADIUS-R= equest.  If the client performs
   the Termination-Action= by sending a new Access-Request upon
   termination of the cu= rrent session, it MUST include the State
   Attribute unchange= d in that Access-Request.  In either usage, the
   client= MUST NOT interpret the Attribute locally.  A CoA-Request
 &nb= sp; packet must have only zero or one State Attribute.  Usage of the   State Attribute is implementation dependent.

= --_37557d2c-6f82-4fe1-8c8a-ec622610f7b4_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 18:55:12 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_2536ed29-6ee9-422d-bc0e-b6afeba1fc08_" From: Bernard Aboba To: "David B. Nelson" , Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 22 May 2007 11:54:43 -0700 MIME-Version: 1.0 --_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 > s/so that the User-Name may not be/because the User-Name may not be/
Got it.
 
> > Where the Acct-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 suf= ficient to
> > uniquely identify the session (e.g. if the same use= r has multiple
> > sessions on the NAS). As a result, the Called-S= tation-Id, Calling-
> > Station-Id, NAS-Port, NAS-Port-Id and Acct= -Multi-Session-Id
> > attributes MAY be used for session identific= ation in addition.
>
> s/MAY be used for session identificatio= n in addition./MAY be used as
> additional session identification./  
Here is a rewritten paragraph:
 
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 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). 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.
 
> > [Note 6] Support f= or the Service-Type of "Authorize Only" is OPTIONAL
> > on the NAS= and RADIUS server. A NAS supporting the "Authorize Only"
> > Serv= ice-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 Acce= ss-
> > Request SHOULD contain the NAS attributes from the CoA-Req= uest, as
> > well as the session attributes from the CoA-Request l= egal for
> > inclusion in an Access-Request as specified in [RFC28= 65], [RFC2868], 
> > [RFC2869] and [RFC3162]. As noted in [RF= C2869] 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 Attrib= ute. The RADIUS server should send
> > back an Access-Accept to (r= e-)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 "Unsuppor= ted 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
&g= t; > in a CoA-Request then a State Attribute MUST be present, and MUST b= e
> > sent unmodified from the NAS to the RADIUS server in the res= ulting
> > Access-Request sent to the RADIUS server, if any. The S= tate
> > Attribute is also available to be sent by the RADIUS serv= er to the
> > NAS in a CoA-Request that also includes a Terminatio= n-Action
> > Attribute with the value of RADIUS-Request. If the cl= ient performs
> > the Termination-Action by sending a new Access-R= equest upon
> > termination of the current session, it MUST includ= e the State
> > Attribute unchanged in that Access-Request. In eit= her usage, the
> > client MUST NOT interpret the Attribute locally= . A CoA-Request
> > packet must have only zero or one State Attrib= ute. Usage of the
> > State Attribute is implementation dependent.=
> >
> > [Note 8] Where included within a CoA-Request, t= hese attributes
> > represent a renumbering request. Since these a= ttributes are not used
> > for session identification, they MUST N= OT be included within a
> > Disconnect-Request. Note that renumber= ing may not be possible in all
> > situations. For example, in ord= er to change an IP address on receipt
> > of a changed Framed-IP-A= ddress address, IPCP re-negotiation could be
> > required, which i= s not supported by all PPP implementations.
>
> It strikes me = that the large number and substantial nature of these notes
> suggest= s that they be incorporated elsewhere in the normative text of the
> = document, rather as footnotes to the Table of Attributes. I think it would<= BR>> substantially enhance readability of the document.
 
I will move Notes 6 and 7 into the main text.
= --_2536ed29-6ee9-422d-bc0e-b6afeba1fc08_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 17:45:18 +0000 From: "David B. Nelson" To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 22 May 2007 13:43:32 -0400 Organization: Elbrys Networks, Inc. Message-ID: <009901c79c98$b6f107c0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcecljRP7Zb6Tl0UTJueaLXiC1unPAAAOQEw 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 17:31:53 +0000 Message-ID: From: Bernard Aboba To: Subject: Issue: Error-Cause Attribute in Disconnect-ACK? Date: Tue, 22 May 2007 10:31:40 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Issue: Error-Cause Attribute in Disconnect-ACK? Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 17:21:36 +0000 Message-ID: From: Bernard Aboba To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Tue, 22 May 2007 10:21:19 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 17:12:15 +0000 Message-ID: From: Bernard Aboba To: Subject: FW: draft-ietf-radext-fixes-03 LC comments Date: Tue, 22 May 2007 10:12:01 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 =20 > > -----Original Message----- > > From: Alfred H=CEnes [mailto:ah@tr-sys.de] > > Sent: Sunday, May 20, 2007 2:54 PM > > To: d.b.nelson@comcast.net; aland@freeradius.org > > 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: ah@TR-Sys.de | > > +------------------------+--------------------------------------------+ >=20 >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 17:00:37 +0000 Message-ID: From: Bernard Aboba To: Subject: FW: Gen-art review of draft-ietf-radext-rfc4590bis-01.txt Date: Tue, 22 May 2007 09:59:48 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 ---------------------------------------- > Date: Tue, 22 May 2007 13:57:19 +0300 > From: Gonzalo.Camarillo@ericsson.com > To: baruch@kayote.com; dscreat@dscreat.com; david@kayote.com; dwilli@cisc= o.com; beckw@t-systems.com > CC: Bernard_Aboba@hotmail.com; d.b.nelson@comcast.net; gen-art@ietf.org; = dromasca@avaya.com; rbonica@juniper.net > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 05:08:34 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_db874d93-09b7-43b6-a903-0721a420ef40_" From: Bernard Aboba To: "Glen Zorn (gwz)" , CC: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Mon, 21 May 2007 22:08:23 -0700 MIME-Version: 1.0 --_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 Glen Zorn said:
So, basically= , what you are=20 saying seems to be that
  1. deploying RADIUS accounting is mandatory=20 AND
  2. an undefined but incestuous relationship between se= parate RADIUS=20 and RADIUS Accounting servers is also mandatory OR
  3. the RADIUS and RADIUS Accounting servers must be on= e and the=20 same
None of those seem like very good ideas t= o me.
T= his makes sense to me.

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.  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.  = 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-Re= quest or Disconnect-Request based on an Accounting-Request.  In this c= ase, the Acct-Session-Id attribute would be used to identify the session.&n= bsp;

The question is this:  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?  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). 



= --_db874d93-09b7-43b6-a903-0721a420ef40_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 22 May 2007 04:57:06 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_0da860cc-de1b-4532-9cdc-035846bfa268_" From: Bernard Aboba To: Subject: RFC 4590 IETF Last Call Comments Date: Mon, 21 May 2007 21:56:06 -0700 MIME-Version: 1.0 --_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 '> 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 From: Frank Ellermann
Date: Friday, May 18, 2007
Subject: Re: Last Ca= ll: draft-ietf-radext-rfc4590bis (RADIUS Extension for Digest Authenticatio= n) to Proposed Standard

The IESG wrote:

> The IESG has rec= eived a request from the RADIUS EXTensions WG (radext)
> to consider = the following document:

> - 'RADIUS Extension for Digest Authenti= cation '
>    <draft-ietf-radext-rfc4590bis-01.txt&= gt; as a Proposed Standard

Hi, this draft might be also interesting = for the 2831bis (SASL) and
2617bis (HTTP-AUTH) folks.  From a quick= read I found that the I-D
picked the "keep backslash as is" approach be= tween client and proxy,
trimming \\ and \" only at the RADIUS server.
The other DIGEST-MD5 parameters are as always confusing, I don't seeanything related to SASLprep in the draft (it's based on 2617).  It<= br>mentions 2069 backwards compatibility based on the absence of "QoP",
= I'm not sure if that's correct for "md5-sess" without "QoP".

The dra= ft 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 this
is a fatal = error for qop=3Dauth, isn't it ?  RFC 2617 says that it MUST
be sen= t for a non-empty qop.

The password for the 4590 examples isn't show= n, therefore I'm unable
to check them, even after adjusting the code to = treat qop=3Dauth without
CNONCE as 2069 fallback.  Should I treat C= NONCE as empty and make up
an NC 00000001 ?

Without SASLprep the = draft IMO needs some "I18N considerations" about
non-ASCII user names an= d passwords as mandated by BCP 18 (RFC 2277).

Frank
= --_0da860cc-de1b-4532-9cdc-035846bfa268_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 21 May 2007 23:42:52 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_7e72876c-bf21-4d1f-b0ec-bdb873b4b013_" From: Bernard Aboba To: "David B. Nelson" , Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Mon, 21 May 2007 16:42:33 -0700 MIME-Version: 1.0 --_7e72876c-bf21-4d1f-b0ec-bdb873b4b013_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: dnelson@elbrysnetworks.com> To: radiusext@ops.ietf.org> 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

> From: dnelson@elbrysnetworks.com
> To: radiusext@ops.iet= f.org
> Subject: RE: Issue 226: RFC 3576bis and Renumbering
> D= ate: Mon, 21 May 2007 14:57:52 -0400
>
> Bernard Aboba writes.= ..
> > So my inclination would be to cull the list to the followin= g:
> > 
> >   Attribute   &= nbsp;          #  &n= bsp; Reference  Description
> >   --------- &n= bsp;           --- &= nbsp; ---------  -----------
> >   User-Name &= nbsp;            1&n= bsp;   [RFC2865]  The name of the user
> > &nb= sp;            =             &nb= sp;            =    associated with the session.
> >   Acct-Ses= sion-Id       44    [RFC2866]&= nbsp; The identifier uniquely
> >     &nb= sp;            =             &nb= sp;           identifying= the session
> >        &n= bsp;            = ;            &n= bsp;        on the NAS.
>
>= Are you recommending that the others listed in RFC 3576 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_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 21 May 2007 23:25:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79BFF.37D7DE9A" Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Mon, 21 May 2007 16:24:44 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504009F5E@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue 226: RFC 3576bis and Renumbering Thread-Index: Acebuwg9QmpyMwKsQ0aRQdGR6sEYuQAQknTQ From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4458; t=1179789886; x=1180653886; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Issue=20226=3A=20=20RFC=203576bis=20and=20Renumbering |Sender:=20; bh=ECZQHnhhpoyFLcJcmvbJ5vtozJYUFekfE+/0fEm3/zA=; b=SuXa/PgD09VIIfsmfVspC9+gttbqOW5M8ii1jkPmFIZdaT0EJIr1yG3pZxkvSugYsuEXAmgT o0T2Yewd7gvIC2847fCb4ACGQqpB+YDeWdeu2upoaImYxQ7qzvbQdItC; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); 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
> I think we'd be better off just making=20 Acct-Session-Id a MUST, and
> ignoring the other = attributes.

Making=20 Acct-Session-Id a MUST would ensure Diameter compatibility. =
User-Name=20 probably needs to be at least a MAY for the same reason.  
 
There are just a few problems with this idea (in = the absence=20 of RADIUS accounting).  The first & most obvious is that = "sessions" do=20 not exist in RADIUS.  This is because the RADIUS server has no idea = when=20 (or if) the session ends or, more subtly, if it actually begins.  = All the=20 RADIUS server  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.  So, basically, what you = are=20 saying seems to be that
  1. deploying RADIUS accounting is mandatory=20 AND
  2. an undefined but incestuous relationship between = separate RADIUS=20 and RADIUS Accounting servers is also mandatory = OR
  3. the RADIUS and RADIUS Accounting servers must be one = and the=20 same
None of those seem like very good ideas to me.  Not = to=20 belabor the point, but all these problems have been thought through = and=20 solutions designed in http://www.ietf.org/internet-drafts/draft-zorn-radius-logoff-09.txt.  
 
 ... 
------_=_NextPart_001_01C79BFF.37D7DE9A-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 21 May 2007 18:59:56 +0000 From: "David B. Nelson" To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Mon, 21 May 2007 14:57:52 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004701c79bd9$ef1e7e30$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Thread-Index: Acebu9p6sVZEyalXRlC8k2+nZNkt9gAHcnVA QmVybmFyZCBBYm9iYSB3cml0ZXMuLi4NCj4gU28gbXkgaW5jbGluYXRpb24gd291bGQgYmUgdG8g Y3VsbCB0aGUgbGlzdCB0byB0aGUgZm9sbG93aW5nOg0KPqANCj6goCBBdHRyaWJ1dGWgoKCgoKCg oKCgoKCgICOgoKAgUmVmZXJlbmNloCBEZXNjcmlwdGlvbg0KPqCgIC0tLS0tLS0tLaCgoKCgoKCg oKCgoCAtLS2goCAtLS0tLS0tLS2gIC0tLS0tLS0tLS0tDQo+oKAgVXNlci1OYW1loKCgoKCgoKCg oKCgoCAxoKCgIFtSRkMyODY1XaAgVGhlIG5hbWUgb2YgdGhlIHVzZXINCj6goKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBhc3NvY2lhdGVkIHdpdGggdGhlIHNlc3Npb24u DQo+oKAgQWNjdC1TZXNzaW9uLUlkoKCgoKCgIDQ0oKCgIFtSRkMyODY2XaAgVGhlIGlkZW50aWZp ZXIgdW5pcXVlbHkNCj6goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBp ZGVudGlmeWluZyB0aGUgc2Vzc2lvbg0KPqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgIG9uIHRoZSBOQVMuDQoNCkFyZSB5b3UgcmVjb21tZW5kaW5nIHRoYXQgdGhlIG90 aGVycyBsaXN0ZWQgaW4gUkZDIDM1NzYgYmUgZGVwcmVjYXRlZD8NCg0K -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 21 May 2007 15:16:36 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_33d3d403-7142-437c-8559-ff3e8a63a8f7_" From: Bernard Aboba To: CC: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Mon, 21 May 2007 08:15:38 -0700 MIME-Version: 1.0 --_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 > 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.
User-Name probably needs to be at least a MAY for the same reason.  
I would agree that the other attributes are of dubious utility.
 
For example, where the IP address isn't assigned by the NAS
(e.g. L2 access device)  neither the RADIUS server nor the NAS
may know the IP address associated with the session.  In this case it doesn't make sense to send a CoA-Request with IP address session
identification attributes. 
 
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
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. 
 
However, in -04 this has to be done in two steps since Framed-IPv6-Prefix and Framed-Interface-Id are reserved for session identification.
 
So it makes sense to remove the IP address session identification attribute= s
and allowing Framed-IPv6-Prefix to be included in a CoA-Request.
 
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.
 
So my inclination would be to cull the list to the following:
 
   Attribute         = ;     #    Reference  Description   ---------        &nb= sp;    ---   ---------  -----------
 =   User-Name          = ;    1    [RFC2865]  The name of the use= r
           &nbs= p;            &= nbsp;           &nbs= p;     associated with the session.
   Acc= t-Session-Id       44    [RFC2= 866]  The identifier uniquely
      &= nbsp;           &nbs= p;            &= nbsp;          identifying the= session
          &nb= sp;            =             &nb= sp;      on the NAS.
= --_33d3d403-7142-437c-8559-ff3e8a63a8f7_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 21 May 2007 03:29:25 +0000 Message-ID: From: Bernard Aboba To: Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Sun, 20 May 2007 20:28:36 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 20 May 2007 21:29:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 226: RFC 3576bis and Renumbering Date: Sun, 20 May 2007 14:28:50 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625040099E4@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue 226: RFC 3576bis and Renumbering Thread-Index: Acea3g12uvy+1EY4QLykpngGSdxmnwARyoQQ From: "Glen Zorn \(gwz\)" To: "Alan DeKok" , "Bernard Aboba" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1852; t=1179696532; x=1180560532; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Issue=20226=3A=20=20RFC=203576bis=20and=20Renumbering |Sender:=20; bh=SbAzRGdRRdo+koVRIJjFvU+Nx974sOZ6xf3TERfCqBw=; b=DGl5+u3w9zisVFd0YtSnody9h3MlXGkknh17wtmY/Cu0vilYOJujBWifRwolIjweOC/1nfvB 1ifpDlSB3ofrmFMPxKG8CGqyXBcXn9o/ZwDloKbZZmPptwRrPtZphLkW; Authentication-Results: sj-dkim-5; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 20 May 2007 12:54:37 +0000 Message-ID: <465044C8.7090401@nitros9.org> Date: Sun, 20 May 2007 14:53:28 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Issue 226: RFC 3576bis and Renumbering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 20 May 2007 06:13:53 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_f045cd0f-0cbd-4209-a48c-094e7e4a7e83_" From: Bernard Aboba To: Subject: Re: Issue 226: RFC 3576bis and Renumbering Date: Sat, 19 May 2007 23:12:42 -0700 MIME-Version: 1.0 --_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 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 i= dentification attributes.

RFC 3576bis-04 advocates use of the Servi= ce-Type value of "Authorize-Only" in order to enable renumbering. 
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.

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

Comments?
= --_f045cd0f-0cbd-4209-a48c-094e7e4a7e83_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 15 May 2007 22:46:38 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_88626fcc-56eb-409e-bda8-4cb77f2a1a0e_" From: Bernard Aboba To: Subject: RFC 3576bis Open Issues Date: Tue, 15 May 2007 15:45:56 -0700 MIME-Version: 1.0 --_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 Currently, we have two open issues on RFC 3576bis:
 
Issue 226: RFC 3576bis and Renumbering<= /A>
Issue 227: Proxy State
 
In order to resolve these issues, we need answer to the following questions= from implementers of  RFC 3576:
 
a.  Have you implemented Framed-IP-Address or Framed-IPv6-Prefix/Frame= d-Interface-Id as a Session Identification attribute?
b.  Have you implemented the proxy state algorithm described below?  
    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-Stat= e Attributes in its response to the
    server.

&n= bsp;   A forwarding proxy or NAS MUST NOT modify existing Proxy-S= tate,
    State, or Class Attributes present in the packe= t.  The forwarding
    proxy or NAS MUST treat any P= roxy-State attributes already in the
    packet as opaque= data.  Its operation MUST NOT depend on the
    con= tent of Proxy-State attributes added by previous proxies.  The
&nbs= p;   forwarding proxy MUST NOT modify any other Proxy-State Attri= butes
    that were in the packet; it may choose not to f= orward them, but it
    MUST NOT change their contents.&n= bsp; If the forwarding proxy omits the
    Proxy-State At= tributes in the request, it MUST attach them to the
    r= esponse before sending it.

    When the proxy forward= s a Disconnect or CoA-Request, it MAY add a
    Proxy-Sta= te Attribute, but it MUST NOT add more than one.  If a
  =   Proxy-State Attribute is added to a packet when forwarding the
&n= bsp;   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.
    Other Attribut= es can be placed before, after or even between the
    Pr= oxy-State Attributes.

    When the proxy receives a r= esponse to a CoA-Request or Disconnect-
    Request, it M= UST remove its own Proxy-State (the last Proxy- State
   = in the packet) before forwarding the response.  Since Disconnect
&= nbsp;   and CoA responses are authenticated on the entire packet = contents,
    the stripping of the Proxy-State Attribute = invalidates the
    integrity check - so the proxy needs = to recompute it.
 
= --_88626fcc-56eb-409e-bda8-4cb77f2a1a0e_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 15 May 2007 14:04:21 +0000 To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-radext-rfc4590bis (RADIUS Extension for Digest Authentication) to Proposed Standard Reply-To: ietf@ietf.org Cc: Message-Id: 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 ' 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 ietf@ietf.org mailing lists by 2007-05-29. Exceptionally, comments may be sent to iesg@ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 14 May 2007 13:48:32 +0000 To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-radext-fixes (Common RADIUS Implementation Issues and Suggested Fixes) to Proposed Standard Reply-To: ietf@ietf.org Cc: Message-Id: 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 ' 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 ietf@ietf.org mailing lists by 2007-05-28. Exceptionally, comments may be sent to iesg@ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 09 May 2007 20:02:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 Message-ID: <34B734D4F6C5BE4FB378F15FCD763A6103183CDF@orsmsx418.amr.corp.intel.com> Thread-Topic: your support: [Mip4] Working Group Last Call fordraft-ietf-mip4-radius-requirements-02.txt Thread-Index: AceM8+qZ6xjwEQu1TuCXEa1eFUhoKQFZsQ+wAAZRF5A= From: "Adrangi, Farid" To: , 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:pete.mccann@motorola.com]=20 Sent: Wednesday, May 02, 2007 12:56 PM To: mip4@ietf.org; radiusext@ops.ietf.org 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, mip4@ietf.org. -Pete & Henrik --=20 Mip4 mailing list: Mip4@ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 01 May 2007 22:59:47 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: RFC 4849 on RADIUS Filter Rule Attribute Date: Wed, 2 May 2007 01:58:39 +0300 Message-ID: Thread-Topic: RFC 4849 on RADIUS Filter Rule Attribute Thread-Index: AceLpSi2l7WrefSaSg+0yal9pLOYzQAnt+XQ From: "Romascanu, Dan \(Dan\)" To: Congratulations and thanks to the editors, chairs, contributors and all the WG for the publication of this document.=20 Dan =20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Tuesday, May 01, 2007 6:58 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org; radiusext@ops.ietf.org 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: paul.congdon@hp.com,=20 mauricio.sanchez@hp.com,=20 bernarda@microsoft.com 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 IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG 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 RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 01 May 2007 03:59:26 +0000 Date: Mon, 30 Apr 2007 20:58:23 -0700 Message-Id: <200705010358.l413wNec029184@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4849 on RADIUS Filter Rule Attribute From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org 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: paul.congdon@hp.com, mauricio.sanchez@hp.com, bernarda@microsoft.com 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 IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG 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 RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: